INTERNET ENGINEERING STEERING GROUP (IESG) Narrative minutes for the 2024-08-08 IESG Teleconference These are not an official record of the meeting. Narrative Scribe: Jenny Bui, Secretariat 1. Administrivia 1.1 Roll call ATTENDEES --------------------------------- Amanda Baber (ICANN) / IANA Liaison Jenny Bui (AMS) / IETF Secretariat Deb Cooley (Department of Homeland Security, Cybersecurity and Infrastructure Security Agency) / Security Area Jim Guichard (Futurewei Technologies) / Routing Area Mahesh Jethanandani (Arrcus) / Operations and Management Area Erik Kline (Aalyria Technologies) / Internet Area Murray Kucherawy (Meta) / Applications and Real-Time Area Warren Kumari (Google) / Operations and Management Area Karen Moore (AMS) / RFC Editor Liaison Cindy Morgan (AMS) / IETF Secretariat Tommy Pauly (Apple) / IAB Chair Zaheduzzaman (Zahed) Sarker (Nokia) / Web and Internet Transport Area Orie Steele (Transmute) / Applications and Real-Time Area Gunter Van de Velde (Nokia) / Routing Area Éric Vyncke (Cisco) / Internet Area REGRETS --------------------------------- Jay Daley / IETF Executive Director Roman Danyliw (CERT/SEI) / IETF Chair, General Area Liz Flynn (AMS) / IETF Secretariat Sandy Ginoza (AMS) / RFC Editor Liaison Francesca Palombini (Ericsson) / Web and Internet Transport Area David Schinazi (Google) / IAB Liaison John Scudder (Juniper) / Routing Area Sabrina Tanamal (ICANN) / IANA Liaison Paul Wouters (Aiven) / Security Area OBSERVERS --------------------------------- Martin Duke Jeffry Handal Greg Wood Kaliya Young 1.2 Bash the agenda Cindy: Does anyone want or have any changes to today's agenda? 1.3 Approval of the minutes of past telechats Cindy: Does anyone have an objection to approving the minutes from the July 11 meeting? Are there any objections approving the narrative minutes from the July 11 meeting? We'll get those posted onto the Datatracker. 1.4 List of remaining action items from last telechat OUTSTANDING TASKS Last updated: August 5, 2024 * DESIGNATED EXPERTS NEEDED o Éric Vyncke to find designated experts for RFC 9575 (DRIP Entity Tag (DET) Authentication Formats and Protocols for Broadcast Remote Identification (RID)) [IANA #1367328] Cindy: There is a management item on this later on the agenda so we'll provisionally mark this one as done until we get to that management item where hopefully we can fully mark it as done. o Éric Vyncke to find designated experts for RFC 9606 (DNS Resolver Information") [IANA #1367528]. Cindy: There's also a management item of that so we will hopefully be able to mark that done when we get to that management item. o Francesca Palombini to find designated experts for RFC 9595 (YANG Schema Item iDentifier (YANG SID)) [IANA #1369452]. Cindy: This was just added on Monday so there's an item later on the agenda to formally assigned that action item to Francesca. o Paul Wouters to find designated experts for RFC 9580 (OpenPGP) [IANA #1369457]. Cindy: This was also just added on Monday, and there's a management item to formally assign this action item to Paul. Eric: To see this one as a management item, there are so many registries to be created, about 20 of them. * OPEN ACTION ITEMS o Roman Danyliw and Warren Kumari to 1) draft a revision of RFC 4858, 2) draft a revised IESG Statement on Document Shepherds (original statement October 2010), and 3) update the WG Chairs wiki to point to the new IESG Statement. Cindy: Warren, any update? Warren: In progress. o Paul Wouters to write a proposal for handling IANA review mailing lists. Cindy: We'll mark this as in progress since Paul isn't here to report on that. o All IESG to review Non-WG List Review spreadsheet and note which lists may be ready for closure and any needed AD Actions. Cindy: I don't think we need to discuss this one, it's just a reminder. o Orie Steele, Francesca Palombini, Murray Kucherawy, Mahesh Jethanandani, Warren Kumari to write draft of IESG statement addressing issue of credit in documents & the importance of capturing and addressing all comments as a necessary part of the consensus process, mostly pointing at existing advice. Warren: I think that's also in progress, but even less so than the previous one. No, I lied. Orie is on it. Orie: It still needs work, but I pinged the document for folks to make some edits on it. Murray: There is a document, awesome. That's further along than the next two are. o Murray Kucherawy and Éric Vyncke to create a draft IESG statement about using 2119 language. Murray: Eric and I haven't synced up on this one. I haven't started the next one. o Murray Kucherawy to draft an IESG statement on use of Internet-Drafts to meet "specification required" in IANA registries. Cindy: We'll keep it in progress. Warren: I think that one is moving along because that's part of the RFC blah blah bis. Murray: There is a certain amount of this that is waiting on that to resolve. Warren: So that one is really in progress. o Roman Danyliw to reach out Systers about the value of writing recommendation letters to employers. o Roman Danyliw to reach out to Dhruv Dhody to better track outreach initiatives. Cindy: We'll keep those in progress. 2. Protocol actions 2.1 WG submissions 2.1.1 New items o draft-ietf-rift-yang-16 - IETF stream YANG Data Model for Routing in Fat Trees (RIFT) (Proposed Standard) Token: Jim Guichard Cindy: It looks like there are currently no discusses in the tracker so unless there are any objections, it looks like this one is approved. Jim: Can you put this one in revised ID needed? There's quite a few comments from Mahesh and Orie that I haven't seen any responses to yet, and they look as if they're going to require some changes. Cindy: Certainly, so this will go into approved announcement to be sent; revised ID needed, and we'll wait for you to let us know when this is ready to go. o draft-ietf-opsawg-mud-tls-16 - IETF stream Manufacturer Usage Description (MUD) (D)TLS Profiles for IoT Devices (Proposed Standard) Token: Paul Wouters Cindy: There are a couple of discusses but Paul is not here to discuss them today. Do the discusser want to discuss them amongst the rest of the IESG? Mahesh: I don't have a question specifically for Paul, but anybody here who is a TLS expert. I don't understand that handshake process and this particular draft is trying to define how they would configure ACL rule essentially filters on the certificate authority list. My question to anyone who knows and how TLS handshake is, is that something that's known upfront in the order in which the certificate authorities are listed such that it can be written into an ACL rule? Or is that something that's negotiated at the time of the connection? Deb: Normally that's negotiated at the time of the connection. I was confused by the use of the term ACL for TLS, and so one of my comments was about business ACL stuff. I don't know how that works. I know about TLS, but I don't know about how that works so I think it's a good comment. Mahesh: Very briefly ACL is all about programming essentially a set of bits that you match on in hardware, pretty much in hardware. As the packet is coming in, you essentially load the packet header content and match it against the number of bits to say, ok, is there a match or no? The thing that they're also programming is the name, the certificate authority list to match against. Now i've never first of all, seen strings being programmed into ACLs because imagine how big that comparison would be like. Number two is, is the order well known? And do we know what to match against? Eric: When I read access control list, I read a layer two, a layer, three layer, two layer, three layer four access control list. I've also seen the word access control list being applied to anything outside of layer three and layer four. It's unusual. More about the certificate authority, I know for sure that my employer, but most probably every firewall or whatever vendors can apply some access control and the name access control list based on the endshake of TLS because it's in the clear. They all recognized some malware. For instance, when you start TLS but the destination that you see that is an encrypted clientele will defeat this purpose. To prevent because that's surveillance is basically for the good guy, we can see was the CA that was the destination name. You want to go to malware.example? We'll block you. You want to go goodguy.example? We'll allow you. I guess this is where everything is there. Then again, i'm not an expert. Erik: I assumed it's not like a literal ACL in the routing config sense, it's an abstract concept. Deb: That's the only thing that makes sense right? It doesn't look like an ACL like anything that i've ever heard described as an ACL before. Only in the very most abstract sense in that there's a control list that might be a list of strings, as opposed to a bitmap which is what you'd see in an unix ACL. There's a lot about this draft that confuses me and I'm glad you lodge discusses. I wrote comments and one of my comments was 'I don't understand how you're using the acronym ACL here' and I got a very terse answer back. Mahesh: I'll continue the conversation with the authors and seems they did respond but I have to really go through their responses to see if that makes sense. Cindy: Do the folks who have discusses think this is going to require a revised ID or should we just put this in AD follow up and Paul can pick it up when he gets back? Warren: Sounds like it needs a new ID, in my opinion. Deb: I would say it needs a new ID. Cindy: This will stay in IESG Evaluation; revised ID needed and Paul can follow up when he gets back. o draft-ietf-bess-evpn-mh-split-horizon-10 - IETF stream EVPN Multi-Homing Extensions for Split Horizon Filtering (Proposed Standard) Token: Gunter Van de Velde Cindy: There is a discuss from Roman who unfortunately is not here with us today to discuss this discuss. Gunter: The lead author was away for about two weeks after IETF but he responded this morning, so I think he will acknowledge the discussion from Roman. He will update the draft and make it very clear that there will be more registries and basically Roman was correct. The draft needs to be updated. Cindy: It sounds like this will stay in IESG Evaluation with a substate of revised ID needed. o draft-ietf-cose-key-thumbprint-05 - IETF stream CBOR Object Signing and Encryption (COSE) Key Thumbprint (Proposed Standard) Token: Paul Wouters Cindy: There are currently no discusses in the Tracker or unless there is an objection, it looks like this one is approved. I don't hear any objections but since Paul isn't here, we're going to put this into Approved Announcement to be sent; AD follow-up so he can do a last check and confirm that this actually is all ready to go. There's also a couple of down refs on this that we'll be asking him if those should be added to the registry when he lets us know that this is ready to go. o draft-ietf-ccwg-rfc5033bis-07 - IETF stream Specifying New Congestion Control Algorithms (Best Current Practice) Token: Zaheduzzaman Sarker Cindy: It looks like there's a discuss from Roman, who again is not here. Zahed: Thanks for all the comments that we got. I think the authors are replying to that and also the authors are in conversation with Roman with the proposed changes. I'll let that happen and see how that resolves. For now this will be revised ID needed. Cindy: This will stay in IESG evaluation with a substate of revised ID needed. o draft-ietf-lisp-name-encoding-11 - IETF stream LISP Distinguished Name Encoding (Proposed Standard) Token: Jim Guichard Cindy: There is a discuss from Paul who is not here. Jim: This one is giving me a headache to be honest because the reviews are talking about the use of ascii but the reviewers can't seem to agree on what the right thing to do is. The author, Dino, doesn't seem to know what to do either so I guess this is going to have to be discussed with Paul when he gets back because I really don't know what to do here. Orie: You might find some use in pinging the ART list, if it's related to ascii Unicode considerations. You may get some good comments. Deb: So I looked at the list before commenting on this and it looks like there's a member of the working group that had a suggestion from the author, but I didn't see the author respond to that and I don't remember the person's name. Jim: There's been quite a few things flying around. Dino's response to me was like: 'It's in your hands now' but no, it's not in my hands. There are comments that need to be addressed and Paul's got this discuss. I'm hoping that Paul can guide me a little on this one when he comes back. It's not an area I have expertise in so i'm kind of flapping around a little bit. We'll put this one in AD follow-up. Cindy: This will stay in IESG Evaluation with a substate of AD follow up, and there downrefs in this, RFC 8060 which is an experimental document. When this approved should that be added to the downref registry? Jim: I think so, yes. Murray: Before we move one, maybe we should make a suggestion to the authors that a security considerations that say there are none, will always draw fire. Zahed: I agree, I didn't discuss on it but I really hate saying that there's no security considerations without beginning any context. Jim: Yeah, there's several things to be resolved but the main thing i'm concerned about is, initially, figuring out what encoding this is supposed to be. He's insistent on ascii, and he's getting feedback saying it's problematic, but nobody seems to be able to direct on what the right thing to do is. Warren: Two quick questions, well, a comment and a question. It didn't really feel ready to me, the document, but I think that some of it is or at least what I had assumed is the set of people who are actually doing and implementing this might have more knowledge and I don't really think people who aren't implementing this are likely to suddenly stop doing so. If we go back, is it a Datatracker bug that one of reviews shows serious issues, but that tag doesn't have a circle around it? Murray: I noticed that too, that should be bright red. Warren: I'll try to remember to open a Datatracker bug. Jim: I didn't catch that. I'll follow up with Dino and see where we can take it. Cindy: Anything else on this lisp document? That will stay in IESG Evaluation with a substate of AD follow up. o draft-ietf-cdni-https-delegation-subcerts-09 - IETF stream CDNI Metadata for Delegated Credentials (Proposed Standard) Token: Francesca Palombini Cindy: There are a couple of discusses, does the IESG want to discuss these now with Francesca? I guess Murray, that's really a question for you since you're the only discuss holder that's actually on the call. Murray: Unless they're able to explain what the stuff in my discuss says, it's going to need a revised ID needed. Cindy: We will leave this in IESG Evaluation with a substate of revised ID needed, and Francesca can follow-up on this when she is back. o draft-ietf-extra-processimip-08 - IETF stream Sieve Email Filtering: Extension for Processing Calendar Attachments (Proposed Standard) Token: Murray Kucherawy Cindy: It looks like there are no discusses in the Tracker so unless there's an objection, it looks like this one is approved. Murray: Does it have enough ballots now? It didn't before, I guess it must. Cindy: It does, yes. Murray: You can approve this one. Cindy: Is this ready to go as is or does it need any revised ID or follow up? Murray: That's a good point, I do like to check with them first. Can you do AD follow up, please. Cindy: This will go into Approved Announcement to be sent with a substate of AD follow up, and Murray, you can let us know when this is ready to go. o draft-ietf-pim-3228bis-06 - IETF stream IANA Considerations for Internet Group Management Protocols (Best Current Practice) Token: Gunter Van de Velde Cindy: It looks like there is a discuss from Paul who isn't here to discuss this discuss with us today. Is there any other discussion that the IESG would like to have of this document? Gunter: No, not really. Brian is very responsive to Paul but he was already out so nothing really changed on that side. I'm looking to Paul at the moment to look into the answer for Brian and then it take from there. Warren: Generally, before I put a discuss on a document, I try to poke the authors off list and just ask them stuff. I've been looking at some of the discusses this week, and I can't always do that. Obviously, if I ballot very late or something or if I can't reach them but is that what people are generally doing or just me? It feels like this week, we got more discusses than usual. Gunter: What I do sometimes is, I set it to like no opinion and I sort of like send something out and based upon that i'll go into discussed or put some other thing. Just be gentle in the beginning, but that's maybe just me being a rookie AD. I'm not sure if that's the right thing to do, but it seems to work. Mahesh: Warren, does it help when you go off list and have the discussion? Warren: There's one further down from IDR on BGP send failure, I can't remember what the document is called (draft-ietf-idr-bgp-sendholdtimer) and I just poked Job on Slack saying I don't understand this, it doesn't seem to make much sense, and he explained to me what it was and I was like "Yes!" I think it often does, it depends on what the actual discuss is. Deb: So I will say that I've never done that. I must confess I don't think there's been a telechat cycle where we haven't been slammed completely to the wall. It's hard to read 16 documents and reach out to 16 authors and still get the work done. In fact, I didn't, like there's like six documents I didn't even review for this cycle, and I know Paul's on leave so i'm expecting that he might do that ordinarily , he didn't do it for this one. Warren: This wasn't poking at Paul, it's just a general, is my workflow different to other people? What I try very hard to do this time, I think there were three documents that I didn't actually ballot on is Jen Linkova's comment at the plenary on, trying to give people 24 hours. I tried really hard to do that. Deb: That comment was completely ridiculous, she wants then you would need to move the actual telechat stuff up. I think the actual answer to that particular comment was, you can't expect to have comments until the telechat after the telechat you shake stuff like there's no reason to take away the two weeks were given to actually review 400 pages of documents. Murray: I remember someone giving feedback in a panic because they started getting discusses the night before but that was because that person had an expectation that they fixed everything before the telechat, which means we have left them like an eight hour window to respond to everything, or they felt like we have left them an eight hour window. We had to explain to them there's no expectation that the document to arrive at the telechat in perfect condition. I think this might be an expectation thing we need to manage. Warren: That person who freaked out, I believe they generally participate in IEEE and they had misunderstood and thought we were trying to submarine destroy their document. That was some of the impetus for writing how to handle discussed ballots or something. We added things in there about getting comments late, and not to worry about it. Eric: But it's always, the earlier the better. My agenda is more relax than maybe many other people so i'm more relaxed. Like Erik Kline said in another thing, the grey old ADs know how to schedule stuff better. Cindy: So there's still a discuss on this document. Gunter, do you think it's going to require a revised ID? Gunter: It really depends on how Paul says, I think. Warren: I would assume it needs a revised ID because I think it wouldn't hurt to remove stuff up from the security consideration. Deb: So he has an empty acknowledgement section, do you want that in an RFC? Warren: Either way, the RFC editor will probably suggest to remove it. I think we have a couple of other documents that do. It does seem a little weird, but I suspect the RFC Editor would be be like 'ok, please remove it.' Gunter: Probably going to need a revised draft with one line extra, I suspect but that depends on how Paul sees it. Warren: I do think it's odd to have an empty acknowledgment section. I generally acknowledge anybody and everybody because it doesn't hurt and it's also a good place to put snark. Deb: You can put snark in the acknowledgment section? Warren: RFC 8914, extended DNS errors. Myself and Wes Hardaker, scroll down to the acknowledgement section. I mean, it's not really, but we thought it was. I've got some other things where Mirja put a discuss on my document because we had some stuff in the acknowledgement section that was more funny than she thought was appropriate. Cindy: This will stay in IESG evaluation with a substate of revised ID needed. o draft-ietf-pim-3376bis-11 - IETF stream Internet Group Management Protocol, Version 3 (Internet Standard) Token: Gunter Van de Velde Cindy: There are no open discusses so unless there's an objection it looks like this is approved. Gunter: There are some comments so I want to check them out before. Cindy: We can put this is Approved Announcement to be sent; AD follow up and you can let us know when this is ready to go. There are several downrefs in this document, all two proposed standard documents, RFC 2113, 2236, 4302, 4607, and 4604 should those be added to downref registry? Gunter: Probably, let me double check. o draft-ietf-pim-3810bis-11 - IETF stream Multicast Listener Discovery Version 2 (MLDv2) for IPv6 (Internet Standard) Token: Gunter Van de Velde Cindy: There are no discusses so unless there's an objection, this is approved. Gunter: There are some comments which I would like to look into. Cindy: This will be Approved Announcement to be sent; AD follow up and you can let us know when this is ready to go. There are a number of proposed standard downrefs, should those go into the registry? I'm assuming you'll want to look into those and let us know as well. Gunter: Ok. Thank you. o draft-ietf-idr-bgp-sendholdtimer-15 - IETF stream Border Gateway Protocol 4 (BGP-4) Send Hold Timer (Proposed Standard) Token: Roman Danyliw Cindy: There are no discusses in the Tracker, so unless there's an objection it looks like this one is approved. Warren: This is actually the document that I was chatting with Job. I was originally going to put a discuss saying this should never be needed because BGP hold timer is supposed to fix this, and it turns out a bunch of implementations actually generate hellos in a separate thread. The hold time is actually not as reliable as one would think so the main BGP process can get wedge or the receive queue can get full and because hellos are generated in a separate thread or separate process, these still come through. I figured that was an interesting thing to note. Mahesh: The receiver is essentially preventing the sender from sending any more messages because saying, my queue is full so even if it's on a separate thread, it won't help? Because you'll still get throttled by TCP. It's not really receivable data. Warren: It depends on how exactly you've managed towards yourself. If you're something lke BGP process is sufficiently busy, like RPF is sufficiently busy, it's not actually making any forward progress then you might not be able to generate them. For example, I believe BGP hellos are generated in Juniper PPMD, and so if RPDs are to get wedged, it would not be making forward progress but you'll still be getting hellos. Cindy: So there are still no discusses on this, and I didn't hear any actual objections to approving this one, but since Roman isn't here, we will put this in Approved Announcement to be sent; AD follow up just so he can give it one last check. o draft-ietf-lsr-labv-registration-03 - IETF stream Revision to Registration Procedures for IS-IS Neighbor Link-Attribute Bit Values (Proposed Standard) Token: Gunter Van de Velde Cindy: There are no open discusses so unless there's an objection it looks like this one is approved. Gunter, is this ready to go as is or do you want to give it a final check? Gunter: I think it is ready as is. I do want to check with Tony very quickly if he wants to put eyes on it and things like that. It should be fine. Cindy: You said it's ready to go as is? Gunter: I think so, yeah. 2.1.2 Returning items NONE 2.2 Individual submissions 2.2.1 New items NONE 2.2.2 Returning items NONE 2.3 Status changes 2.3.1 New items NONE 2.3.2 Returning items NONE 3. Document actions 3.1 WG submissions 3.1.1 New items o draft-ietf-mops-treedn-05 - IETF stream TreeDN- Tree-based CDNs for Live Streaming to Mass Audiences (Informational) Token: Éric Vyncke Cindy: There are no open discusses for this document, so unless there's an objection it looks like this one is approved. Eric: It's approved but put revised ID needed, there are some comments that are easy to address and it should be addressed. Cindy: This will go into Approved Announcement to be sent; revised ID needed and you can let us know when it's ready to go. o draft-ietf-teas-gmpls-controller-inter-work-15 - IETF stream Interworking of GMPLS Control and Centralized Controller Systems (Informational) Token: Jim Guichard Cindy: There are no open discusses in the Tracker so unless there is an objection, it looks like this one is approved. Jim: I know there are a couple of nits I saw in the comments. I'm not sure how important to fix those, but I do want to go through those and double check so if you can put it in AD follow up for this one. Cindy: This will go into Approved Announcement to be sent; AD follow up and you can let us know when it's ready to go. 3.1.2 Returning items NONE 3.2 Individual submissions via AD 3.2.1 New items o draft-halpern-gendispatch-antitrust-09 - IETF stream Antitrust Guidelines for IETF Participants (Informational) Token: Roman Danyliw Cindy: There are no discusses in the Tracker so unless there's an objection, it looks like this one is approved. Murray: Isn't this a BCP so it needs more positions? Cindy: No, it's going for informational. Hearing no objections, but Roman is not here, we will put this in Approved Announcement to be sent; AD follow up just so that he can give it a final look through and let us know when it's ready to go. 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 Cindy: Of the four potential crossover folks, I think Tommy, you were the only person who was on yesterday's IAB call, so is there any IAB news that the IESG can use? As I said that, it looks like Tommy has also dropped off from the call. I was on that call yesterday and I call you that the IAB is working on their workshop on AI Control that will be in September. The call for papers for that closed last week, so the program committee is reviewing stuff there and then they are also planning for the Future of Network Management Operation workshop that will happen in December. Elliot Lear will join them next week to discuss the ISOPEN session that happened at IETF 120 and things coming out of that for the IAB. Deb: Those calls aren't open are they? Cindy: They are. IAB calls are open to the public unless they go into executive session. Warren: They are also in the IETF calendar, if you want. Cindy: Yes, they are listed in the Datatracker calendar so you can see them there. Basically, they're using the interim meeting infrastructure, but not sending weekly announcements because that was determined to be too noisy. 6. Management issues 6.1 [IANA #1367916] renewing early allocations for draft-ietf-idr-sr-policy-safi (IANA) Cindy: This is one of John's document and I don't know if we want to wait for him to come back or if the IESG is OK approving this without him. Jim: Probably want to wait for John on this one since it's the fifth renewal. Cindy: Why don't we put this back on the next agenda so hopefully John can join us for that. Erik: Jim, didn't we recently review a document that used this registry? Jim: I don't remember. I'm trying to remember, i'm pretty sure it's a document that Linda Dunbar was involved in this SD WAN thing and John was on it for the Tunnel Encapsulation. I don't remember what the outcome of that one was, I'd need to go look. Eric: But five renewal is quite unusual, right? Jim: That's what caught my eye. Let's just put this on the next telechat, John will be back by then. Cindy: Ok. We will pick up this again at the next telechat. 6.2 [IANA #1367328] Designated experts for RFC 9575 (DRIP Entity Tag (DET) Authentication Formats and Protocols for Broadcast Remote Identification (RID)) (Éric Vyncke) Cindy: Eric, this was an action item that was assigned to you, and this is to approve Adam Wiethuechter and Mohamed Boucadair as the designated experts for this registry. Are there any objections to that? Hearing no objections, those are approved. We will send that official note to IANA. 6.3 [IANA #1367528] Designated experts for RFC 9606, "DNS Resolver Information" (Éric Vyncke) Cindy: This was the other action item for Eric, this is to assign Tirumal Reddy, Mohamed Boucadair, and Ben Schwartz as the designated experts for RFC 9606. Are there any objections to that? Hearing no objections, those are approved and we will send that official note to IANA. 6.4 Two new expert reviewers for JMAP registries (IANA) Cindy: Murray, you wanted to add Joris Baum and Arnt Gulbrandsen as designated experts for the JMAP registries. Are there any objections? Hearing no objections, that is approved and we will send that official note to IANA. 6.5 NomCom Updates (Orie Steele) Orie: I think as you know the NomCom process has started and unfortunately, I was not aware that I needed to gather up job descriptions from you all, prior to IETF 120. I have a few days breather room, and I know a lot of people take vacation after IETF and yet we still need to get the job descriptions posted so that the process can continue. I had shared a Google Doc with the IESG members, there's a general desired expertise section which sort of applies to all area directors, and then for reach area, a job description that sort of specific to that area and every time we go through a cycle it's an opportunity to make some adjustments of what talent or expectations we have for area directors in that area during the next NomCom cycle. My intention is to share with the NomCom Chair the revised job description after today's meeting. I had hoped Roman and some of the other folks would be here who could give a final sign off on it, but I think at this point, I may step out of my liaison limb and share with them the current job description after applying all comments after today's meeting unless there are strong objections from anyone on the call. Warren: Sounds great to me. Zahed: I was hoping this weight area description is also reviewed by Francesca but I think she's not available. So I have tagged you and Murray to actually have a look at it then because you also might need to sync up with what we have in ART and what we have in WIT due to the changes. I have initially done the work and I didn't see much of a comment from any others. Orie: I reviewed and actually stole some of your text regarding the review team for our area. I think you did a good job and just for the record, if you want to update any of these position in the NomCom wiki, I can facilitate changes in the future. Zahed: That's makes me more comfortable sharing it because what I might see that couple of working groups that Francesca has might have a kind of different requirements than what we have right now. We might amend it later. Orie: I have the action. I will share the revised desired expertise and i'll coordinate with Roman and the folks who couldn't make the telechat if they had any additional comments. 6.6 Col Disclosure (Erik Kline) Erik: During Vancouver, I had found out that Rick Taylor was going to accept an offer that my company had made him. He formally started, I think at the beginning of the week. While I was in Vancouver, I discussed with Roman what I should do about the disclosure process because I read the disclosure document and it seems like, as I think I put in Slack somewhere, 99% of it lists things that could qualify as conflict and the actual to do parts seem to be mostly about disclosure. Roman said that I should talk it over with the other DTN Chairs, and with Eric, and I did that while I was there. Eric, you can correct if i'm wrong, but we all agreed that any documents that Rick or I write would be shepherded by the other chair or another shepherd, if we could find one then would be AD by Eric. Roman said if Eric was OK with it, to bring it to the IESG and based on the outcome of this discussion, there would be some email sent to the DTN working group to see what that community thinks. I don't really know what the procedures are here though. Eric: After you check all the things, I think it's done. Warren: I think you've done it all. This is not uncommon thing especially with larger companies with Cisco and Juniper, and I guess possibly Google too, where there's enough people involved where it's unavoidable. Erik: Well in this case, it's small. Small community and small company. Warren: I think having all chairs be from the same company is more problematic than a chair and an AD. Zahed: So what is the problem? Warren: It's more like crossing the T's and dotting the I's. Erik: It's just doing the right thing. 6.7 [IANA #1369452] Designated experts for RFC 9595 (YANG Schema Item iDentifier (YANG SID)) (IANA) Cindy: This is brand new and on here to assign the action item to Francesca to find the designated experts for these registries. 6.8 [IANA #1369457] Designated experts for RFC 9580 (OpenPGP) (IANA) Cindy: This on here to assign an action item to Paul to find designated experts for these registries. 7. Any Other Business (WG News, New Proposals, etc.)