INTERNET ENGINEERING STEERING GROUP (IESG) Narrative minutes for the 2024-10-24 IESG Teleconference These are not an official record of the meeting. Narrative Scribe: Jenny Bui, Secretariat 1. Administrivia 1.1 Roll call ATTENDEES --------------------------------- Jenny Bui (AMS) / IETF Secretariat Deb Cooley (Department of Homeland Security, Cybersecurity and Infrastructure Security Agency) / Security Area Roman Danyliw (CERT/SEI) / IETF Chair, General Area Jay Daley / IETF Executive Director Liz Flynn (AMS) / IETF Secretariat Sandy Ginoza (AMS) / RFC Editor Liaison 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 Cindy Morgan (AMS) / IETF Secretariat Francesca Palombini (Ericsson) / Web and Internet Transport Area Tommy Pauly (Apple) / IAB Chair David Schinazi (Google) / IAB Liaison John Scudder (Juniper) / Routing Area Orie Steele (Transmute) / Applications and Real-Time Area Sabrina Tanamal (ICANN) / IANA Liaison Éric Vyncke (Cisco) / Internet Area Paul Wouters (Aiven) / Security Area REGRETS --------------------------------- Jay Daley / IETF Executive Director Zaheduzzaman (Zahed) Sarker (Nokia) / Web and Internet Transport Area Gunter Van de Velde (Nokia) / Routing Area OBSERVERS --------------------------------- Robert Sparks Greg Wood 1.2 Bash the agenda Liz: Does anyone want to add anything to today's agenda? Roman: I want to do a little bit of 121 prep housekeeping things so could we have a marker for that? Liz: We can add that. 1.3 Approval of the minutes of past telechats Liz: It's only been one week since the last formal telechat and we normally have two weeks for minute approval, so we have nothing to approve here today. 1.4 List of remaining action items from last telechat Roman: Could I have an action item that I think I took out of the last informal, which I took an action to make a proposal for the IESG on adding a box to the registration system to say willingness to be a working group chair just like you do for serving on NomCom? Liz: Sure. We can add that action item for you. OUTSTANDING TASKS * DESIGNATED EXPERTS NEEDED o Zahed Sarker to find designated experts for RFC 9653 (Zero Checksum for the Stream Control Transmission Protocol) [IANA #1378063]. Liz: He's not on the call today so we'll mark this in progress for him. o Warren Kumari to find designated experts for for RFC 9660 (The DNS Zone Version (ZONEVERSION) Option) [IANA #1385320]. Warren: I have one person already who said that they're ok with that. I'd asked three of them. Can we put an action item a little bit later in the call to approve at least one of them? Is that doable now or not? Liz: Sure. We can do that. o Murray Kucherawy to find designated experts for RFC 9559 (Matroska Media Container Format Specification) [IANA #1385324]. Murray: Ok. * OPEN ACTION ITEMS 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. o Murray Kucherawy and Éric Vyncke to create a draft IESG statement about using 2119 language. Liz: I know we are talking about later today and same with the second one, the statement about 2119 language, those are both on today's agenda, so we will just mark these as in progress. 2. Protocol actions 2.1 WG submissions 2.1.1 New items o draft-ietf-rats-eat-media-type-11 - IETF stream Eat Media Types (Proposed Standard) Token: Deb Cooley Liz: We have a discuss, do we want to discuss this now? Deb: So I'm fine not discussing it. I think he's working it, which is fine as you should. The author, that is. Francesca: Just to go back to this one, so my discuss is going to be easily cleared on this document, and the authors have already replied and they posted the review on the media types mailing days so that's not a problem, but the second part of my review that I put in a comment because I don't think it should be blocking on this document is actually related to the other RATS document that we reviewed, I think last time I chat or a while ago and I I feel like this one defines a media type for something that is also present in that one, the EUCC UJCS. What they call JCS, but it doesn't have a direct reference to that document. I think that was Roman's document by the way, not that so I'm still holding and discuss on that one and and Orie has been also having conversation with the author there and I I would prefer that this was held until that one was also approved just because it's defining many time or it's registered media types that are defined there or like for structures defined there. Deb: I'm fine holding it and that's not a problem, but do you want things referenced both directions, like from one to the other or from here to UCCS? Francesca: Well, this is only for this UJCS that appears in the the other the UCCS document in an appendix that says this appendix is informative and we're not defining anything, we're just giving a name to this thing and we call it UJCS. This document says, register media type for UJCS, which is a claim set as the finding reference to OJWT. So it doesn't even reference that other document, but there is, they use the same name, but it doesn't even reference that document and that appendix which is informative. Roman: I'm completely with you. It's a weird thing because the other document says we're not doing anything related to kind of JSON, this is a completely kind of CBOR kind of thing and here's this extra informative thing, and now we have another standards track document which is treating this thing that is informative. A throwaways not knock, not entirely fair, but like it's an informative thing that just kind of got added, but now we're registering media types in a PS like it's a first order thing, and that seems odd. Deb: This seems like what happened with the EAT document, right? Where they weren't registering something that we eventually forced them to register. Orie: Which EAT document? Deb: The first one. The one that they ended up running back through the process without the manifest suit document as a normative reference but they ended up with something that they weren't registering, but that they referred to. Actually I think it was Francesca too, said no, you need to register this thing. They did after much gnashing of teeth. So I think this looks similar to that just from the discussion. Orie: I don't have a discuss on this. I have no objection, right? I support Francesca's point in particular the media type review pieces, I think the most important for this RATS EAT media type document. Your question Deb about references from RATS EAT media type to RATS UCCS, I'd be fine to have pointers back to RATS UCCS to relate UCCS and UJCS as they are relevant to the media type. But my discuss on the UCCS document is really just you're registering this UCCFS plus CBOR media type, where in RATS do you use it and when should you use this UCCS CBOR media type over the EAT media types and I saw Thomas had filed a GitHub issue about that already. So I think they are planning to address it. Deb: On UCCS or on this draft? Orie: In my last comment I said like maybe explain in both documents since you're talking about the same terms in both documents. Deb: But they're not defining the registry in the UCCS draft, right? It's an informative blah blah. Orie: But they're registering a CBOR media type in that document UCCS. They're not registering a JSON media type, which was the original point that I raised in my review, and I'm fine with them not registering media types that RATS doesn't need to use. I just want to understand for the media types that these RATS documents are using, where are these media types being used and when would you use the EAT UCCS over the regular vanilla UCCS, if that makes sense. Deb: Sort of. So regardless, I think we need to talk about this with the authors, and that's fine. We have a meeting coming up, maybe we can talk about it there. So I think the disposition of this is revised ID needed for sure, right? And that I may write the RATS authors and say, hey, we need to talk about this because it's all intermingled. Francesca: I will remove my discuss and I also check that this its media type, each media type has a normative reference to the UCCS as it should, for other reasons, so it will get anyway blocked by that other one that we're still having a discussion with. Deb: But we still have the issue with UCCS adding things informatively that other people are then referencing normatively. Francesca: Not referencing but using. Deb: For something that's not actually been set up. That's the EAT situation where EAT sort of mentions this thing, they don't register it and you pop up and say, wait, what is this? And shouldn't you just register it? And they were all, we don't want to do that, and we said we have to, and they eventually did it. Something completely different probably, not anything related to this and maybe not even media types for all I remember. And so this is the same sort of deal where UCCS is popping up and saying, hey, there's this thing you might want to use someday, but not registering it. Are you gonna use CBOR or not? We can have that conversation too. But that's the UCCS conversation, not this conversation, right? Francesca: Right. Orie: Yep. Deb: So Orie's gonna hold a discuss on UCCS until we straighten this out, which will block this and that. Roman: It would block this one in misref, not for approval. Deb: It would be in misref. But we think this one the way that they've done it is ok if UCCS it does what they're supposed to do ok, right? I don't know that I want to have it held in misref because UCCS takes another way out then. Roman: So the corner case yeah i'm exactly with you. I mean the corner case for me is like what happens after all of deliberations that the UCCS document removes the JSON kind of stuff. And so now we're gonna have this document that's gonna make registrations and then there's no, I don't know what the words are, there's no kind of artifact kind of describing this unprotected JWT kind of claim set. Deb: Yep, so I'm not gonna let it get to this ref. I'm gonna hold it until after the meeting and we figure out what the hell they're gonna do. But I think this is another case of getting, the EAT people and the RATS people and whatever to like actually register the things they're supposed to be registering in the documents that make sense to register them in. By the way better than the OAUTH situation, so I'm happy about that. Orie: Deb's gonna be a media type expert in the next couple of weeks. Probably at this rate. Deb: I can't even tell you. It's not even funny. Anyway, so we're gonna hold this as revised ID needed. Does that put it in my queue or their queue? Eric: The authors, right? Deb: Perfect. Let's do that cause it'll come back to me when they revise it, right? Eric: Indeed. Deb: Thinking about my public queue, thank you very much. Liz: This document is staying in ISEG evaluation with a substate of revised ID needed. o draft-ietf-ippm-encrypted-pdmv2-09 - IETF stream IPv6 Performance and Diagnostic Metrics Version 2 (PDMv2) Destination Option (Proposed Standard) Token: Warren Kumari Liz: We have a couple of discusses, do we want to discuss this now? Warren: I think we might want to, I'm not quite sure what to do with the document at this point. It clearly has a fairly substantial amount of work still needed to help get it finished. So I don't know if the right thing for me to do is hold the document and work with the authors to get it progressed or if it would be better for it to go back to the working group. Paul: Can you or Tommy share some of the history of how this document came to be? Because I think that might be relevant to whatever has happened on the document: Warren: I took over the IPPM. Tommy: There was the old PDM version, stuff which I think had been originally done in IPPM like ages ago and they were like, hey, we need to revise this, we need to have some encrypted versions of it and they brought it in a couple of years ago. I think this is a case where the people within the group who are up on the measurement side of things were supporting and reviewing those parts of it, but they're not necessarily experts on some of the security aspects. Deb, I haven't read your discuss yet. I think I mean they have gone through several sectors. Deb: It's very hand wavy, right? So they basically say, these are asymmetric keys and that's what this means there's a private key and a public key or secret key and a public key, and then there are symmetric keys and you need to use these things, but there's really nothing in there that tells you how, and you might want to use TLS, but, you know, maybe not. There's another section that talks about AESGCM 128, that this is what we sort of recommend, but nothing that says how you get from point A to point B and like you should have an asymmetric key pair and you need to do a key exchange and a shared secret and generate a key in HKDF and, sort of that kind of thing. So it's very loosey goosey for a standard. Tommy: In terms of how the keys are provisioned or derived. I mean, I think that's not uncommon for this layer of like these are just kind of like markings that are going between kind of measurement devices within kind of a controlled network and so they're just saying like, I think the main point here is more to define just like the the format for within this kind of marking measurement system. How do we even incorporate the encryption at all? And I would almost imagine it's just like the it should be more explicit about saying the the actual negotiation of keys comes from somewhere else and that is not what this document is trying to do. Deb: So they could certainly say that and it would make it simpler, right? Or my suggestion was you normatively reference the TLS handshake and say go use that. (crosstalk) Deb: Out of scope, right. Say it's out of scope. So when you look at the packet format though, the encrypted packet, the stuff that's encrypted inside that packet is the same size as the unencrypted packet. Paul: I'm assuming that just So I'm assuming that's just a bug in their thing, right? They just copy pasted the encrypted unencrypted and because clearly the encrypted one is kind of a variable, it's a variable length other thing, right? Deb: If you're only encrypting these fields in the header, then it's gonna be that size plus whatever metadata you need for AESGCM, right? Tag and whatever, right? So all of that needs to be in there. You can't blithely say it's the same size because it's not. Tommy: The text could be the same size as the plain text, but then it needs the other field. Paul: Yeah but no the If you have a plain text and you encrypt it then for definition it's not going to be the same size. Deb: It could give you the same size, but they have not done that. Warren: Yeah, you'd have to, I think you have to get it padded too. Deb: No, there are disk encryption modes that do not expand the data. Warren: Sorry yes, but with what they've defined or with ASGCM. Some of this feels sort of like a, not actually or to me it feels not actually like a standard, more like a architecture/framework for we would like to get PDM encrypted, but I don't know if it has enough detail. Deb: For a guidance document? I get that it's not everything that I discussed it out of scope, obviously those things would go away. Roman: My discuss wouldn't go away if they pulled all that out. Paul: Mine neither. Eric: Mine neither. Roman: Because my fundamental argument is that if you want interoperability and you're putting a new kind of header in and you said all of this is kind of out of scope, there's no kind of MTI, there's no get there's no possibility for interoperability implementations cause I'm gonna invent my own crypto that you haven't specified and someone else is gonna invent their own and how are we gonna talk on the wire? Paul: But all of this also like I haven't even got to where the measurement parts are and how you would change that. So if you change the packet size, your whole measurements of what you're measuring goes out the window too, right? And like and you're doing crypto operations to encrypt things, so that affects all your measurements too, so like so how does an encrypted blob inside this thing still measure the original thing that you were measuring, like you're not anymore. Warren: I think that part you can still do. This is how big the packet was. I'm putting a header in, so the information in the PDM part refers to how big the information was before I added the header. Paul: But now you've got a server that has like a million of these connections and it has to do crypto operations for all of these things to add this information. So the entire state of that server has changed and now all the measurements of all the clients are no longer the real product. Warren: the act of measuring perturbs the system noticeably, but I think it's with the assumption that only doing a very small number of these would be done. Tommy: Like it would be incorrect to assume that this is being, A) being done on all connections that are being handled by, I think this is probably very sampled and very specific. And also going to the interoperability point I think is very common that it's not a limited domain, but like it's kind of within a particular operational domain where they are doing particular measurements and our coordinating is not talking to random other servers that are expected to be. Eric: The client and the server could be going through the complete globe Internet. Warren: I think part of the expected use case for this is, I run a server like in an enterprise. I run a server and it does my HR or something and people complain that it's a bit slow. So within my enterprise I allow IPPM connections to happen. And so from my debugging workstation I include this option and I see how long the round trip is and how all of that sort of input. So I expect this is used for debugging and performance troubleshooting, not everybody's expected to send these out. Tommy: This is there's the the PDM options that have been around, I don't know, it's like eight years or something that they've been doing. And they are using it, so I think it maybe useful to have them also respond and talk about the use cases and the deployment situations where they are using it. Paul: So what are the applications that are actually being monitored by this? Because aren't those applications in themselves already not using TLS and other things to encrypt their data? Tommy: I think I'd want the authors to comment on that. I don't want to speak for them. Deb: the other point too though is the point that John Scudder brought up, which has to do with this thing that they call a global pointer, which isn't a pointer, which is true, but also leaks between things if you're not careful. You have to look at John's discuss. I didn't rewrite it. I just said I agreed with it. Warren: So I think I’ll get back to you. I'm not sure what I should do with this. What I'm trying to figure out is normally I would just hold the document and help the authors walk through work through it but I'm not entirely sure if there are, if these changes are small enough that I can help them, I guess maybe I hold it, help the authors walk through it and then send it back through the working group for a consensus check. Does that make the most sense? Tommy: I think that works, I mean it depends. I wanna get their responses in, if some of the things like to devs are, these bits are out of scope and it's about tightening up that the things that are in scope are clearly like we're defining this bit of protocol foo and let's tighten that up and all the other stuff about how it's negotiated is out of scope, but here are some references to how it could look. That I I don't think changes the content enough that given what I've seen from the working group input on this, that would not really change what they're thinking, that I think the aspects that you're pointing out here, which are great and definitely need to be tightened up, are things that the working group participants aren't focused on anyway, so I think punting it back to a working group wouldn't be as useful as kind of working here to try to come up with the correct responses and have the right discussion on the emails for the discusses. Eric: Maybe you're right. But I think that the change will impact about 30% of the documents. Even it doesn't change the way the working group needs. Tommy: Right, but after I think it would be useful to have this exercise of going back and forth on the discuss and handle this over email with the ADs and the authors. And then once it is kind of clear what to do, then then we can absolutely have the working group review it again. I don't think punting it back to the working group now would help much because I think we need to get a discussion. Warren: so I think I will try and hold the document and try and keep discussion going and thank you everyone for all of your comments and also for being willing to potentially help the authors understand how to clear them. So I'll hold it and then after we've got a bunch of changes, I guess it's, dear working group there's a fairly large set of changes, please let me know if there's still consensus to progress this. Does that sound right? Paul: Sure. I still would like to ask one question. The documents sort of states that someone has worked on the implementation or there's a thank you for working on it. I was just wondering if there is an implementation or not? Tommy: Yes, there is. I think there's a couple. Eric: And if not mistaken, then even using EVPF for it. I can be wrong though. Tommy: I believe that's correct. Liz: This document is staying in IESG evaluation for now with I'm guessing your advised ID needed. Warren: Yes, it's going to be a revised ID needed. 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-irtf-cfrg-aead-properties-00 IETF conflict review for draft-irtf-cfrg-aead-properties draft-irtf-cfrg-aead-properties-09 Properties of AEAD Algorithms (IRTF: Informational) Token: Deb Cooley Liz: Deb prepared this response and is there any objection to sending this NO problem message back to the IRTF? Okay, I'm not hearing any objection, so this is ready to go. Deb, did you want to look it over over time or could we go ahead and send it? Deb: Send it. Ship it. Roman: I want to thank Robert for the back end support. Deb: Yes, because it was bad. 3.4.2 Returning items NONE 4. Working Group actions 4.1 WG crEATion 4.1.1 Proposed for IETF review NONE 4.1.2 Proposed for approval NONE 4.2 WG rechartering 4.2.1 Under evaluation for IETF review o Bidirectional Forwarding Detection (bfd) Liz: We have a recharter under evaluation for review. So John said in the comments, I think we can skip external review but push the wrong button. So is there any objection to just making this change without external review. Roman: Yeah, I'm fine with that. I would like some consideration on my comment because I think we should cut out the things that aren't going to be done and are already done. John: I was gonna respond to that and say, I will scrub those with the chairs. My intention would be anything that just obviously can be removed will remove anything where there's like any judgment call to be made. I'm just gonna leave it. Roman: That's perfect. I was looking for the mid thing and the other one that I recognized is already being done. John: The mid thing made my eyebrow go up too, but then I like looked at it harder and I was like, I bet that that's complicated, but I'll talk to the chairs and make sure that gets done. Roman: Milestones too, would be the other thing. John: Yeah, for sure. Is the conclusion that I do the scrub we just talked about at the milestones and we can just ship it? Very good. Thank you. Roman: I owe you a discuss. Liz: This is approved for just making the change but pending some edits from John, so John we will wait to hear from you that you're ready to move forward. Eric: And by the way, about your clearing the as I'm the actual AD for the unaffiliated one, just ping me when you do it. I'm not sure whether i'll get the message. Roman: I apologize, Eric. I forgot that you took that document. Appreciate you doing it. 4.2.2 Proposed for approval NONE 5. IAB news we can use John: There was no meeting this week. Nothing new from me. 6. Management issues 6.1 [IANA #1375267] IESG approval for protocol number (homa) (IANA) Liz: So 6.1 here was left on again from last week when Eric suggested waiting one more week just to await a response and if there was no more information to approve this today. Eric: So I suggest we do both because I got a reply from the professor Ousterhout from Stanford explaining what he is doing. It does not object to making RFC out of the protocol, but it's too early. So which is kind of weird to ask him for protocol number for something which is not stable. But as I said last week he's using currently the experimental code point and to make Roman smile its support IPV6 so all is good. So for me, my recommendation to the IESG is that we approve it. And I will follow up with John Ousterhout regarding the follow up and the potential RFC. John: A question, is this something that should be approved like early allocation type rules, i. E. It's provisionally assigned. Eric: It's not provisionally assigned, it's definitely assigned. It's forever. Because there is no draft, right? For it. So we can do an early allocation for a non-existing draft. John: It feels wrong to say if I bring you documentation, then I get a code point that isn't as good as I as as what I get if I bring you nothing. Warren: Can somebody remind me how big the protocol space is? Eric: So it's a one byte and about 100 being used. So they are basically two thirds still available. So, which is the reason why I say let's approve it. Now John I got your point, right? So I'm on the edge with you on this one. So we can say no and request for a draft, right? I don't think it will be a problem. John: I haven't even looked at the the registration policy on this on this thing, but, it sort of feels like we're doing an ad hoc process anyway, and why can't the ad hoc process be we're assigning you a temporary number, but you have to renew it on an annual basis just like we do for the more standard provisional allocations. Warren: Does somebody know if we've done this before? Deb: My understanding is you can't do an early allocation if it's not an IETF document. Sabrina: That's correct. John: So which is why I sort of revised my comment to say like if we're like inventing ad hoc process anyway, can't our ad hoc process be you or assigned this thing for one year? Eric: It's not an ad hoc registry. For this specific registry, it's either written. It's either standard action, which is not the case or IESG approval. Warren: Yeah, but the IESG could agree we're only going to approve this for a one year thing or the IESG could have could, you know, as part of their agreement to approve, could say, give us a one page draft saying I would like a thingy and then we have a draft to tie it too. Paul: wWat happens if after one year or what does you're gonna measure uptake or you're gonna measure whether or not the registration expires? And if it expires, would it just go back to the pool for the next one? Because that's normally we don't do that. Warren: That's kind of true for any temporary assignment, right? It's a provisionally assigned thing and then we said that we're not gonna renew it, but God I hope nobody's actually using it. Paul: But again like why we don't do this for protocol, right? Because the space is so small and we really don't want to burn them. Eric: We can burn it. If you look at the protocol history, we can burn it. We can make it temporary. John: My own answer to Paul's question would be, I think it would be your question, Paul. Like how do what do we expect to happen in a year? And I mean based on what you said Eric, that after how was like sort of seemed like he was collaborative and was open to doing a draft and so on. So it's like we approve this, you get it for a year and in a year we expect to see some progress towards having published documentation and then we'll renew on that basis. Eric: Extend it to two years. John: Sure. Roman: Sabrina, can you help us with precedent for any of these being suggested here? Sabrina: For IESG approval, I don't think we've ever had to mark something as temporary in the registry. I may be wrong, so I may have to look into that but I don't, this is not not something that we normally do. Warren: Is it something that you would be comfortable doing? Is that easy for you to do or is it great drama for you? Sabrina: It might be a little bit difficult to track, but I don't think that that's, you know, that should be an issue. I think we can, we can figure out a way to track this one. I am just curious how do you expect us to, I guess mark this in the registry? Do you, do you want us to kind of use the same temporary marking that we're currently using for 7120 early allocation? Warren: I would think so. Eric: I would say so as well. And rather than the email, either you can put a URL to the request somewhere on the web or the email address of John ousterhout; he's requesting it. Sabrina: Would it be ok to also link to the minutes of this telechat just so that we know that it was agreed upon here that this is what we want to do? Eric: I don't mind. The minutes are public. Warren: We could do that or could we, is it worth having just we do a quick separate management item to agree that, no that doesn't really work. I was just trying to find something easier for IANA to link to or to refer to instead of like, you know, 400 pages of minutes. Roman: Sabrina, could I ask a practical question for what we're proposing? And this has already been brought up. Aren't we burning the code point regardless? So let's say we did a temporary approval kind of here and I don't know, the IESG rotates out and they have a completely different kind of opinion on this and they let it expire. Would we return it back to the pool or would we just kind of mark it somehow as burnt? Sabrina: Ee would check in with you on that and you'd have to let us know whether you want to return it back to the unassigned pool or mark it as deprecated. That's something that we would normally ask the chairs for 7120 early allocations. Roman: Because I don't know any of any of this, so in cases where this has happened before not in this particular kind of registry, is there a popular answer? Do most people just burn the code point in most instances where this occurs, does this not occur? You know, can you kind of walk me through it? Is it kind of 50/50? Sabrina: Very rarely, so for 7120 early allocations, we've had it marked just as expired in the registry. I think there's been cases where it's been just marked as deprecated, but very rarely does it ever return to the unassigned pool? I can only speak about 7120 early allocation. Paul: I mean scanning the protocol page I actually don't see any individual entries that say reserved or unassigned or anything. It's just like old craft is still in there marked, like, I don't know Argus protocol 18. I don't know what that is. Warren: if it were not renewed, you know, or if it wasn't finally made permanent, if it was marked as expired or something, when we have ended up using 240 of these, people could then sort of try and decide which ones they might investigate more and might cherry pick? So I suspect, this is making our future lives 30 years down the road easier potentially, if it's marked as expired or deprecated or wasn't use, but we don't think it's being used anymore or was professional but isn't anymore or something like that. I mean I would assume it doesn't get reassigned the next time somebody asks for something. 20 years from now, somebody when they desperately need one. Roman: The background, Sabrina, is helpful and that thought process is helpful to Warren. I'm good with the temporary thing, I think I'm also with the I forgot kind of who said this about the ad hoc kind of nature. If we think we are going to ever do again it would be really great if we had some collateral describing this new thing we're just minuting here on the call. Eric: But if you look, not all of them have an entry to an RFC or to our standards. So they said been there multiple times. Warren: Some of the older ones, even if it's not pointed in RFC, it means we have no idea. The fact that something is listed as the registry and the registry is temporary, the fact that it wasn't renewed kind of signals, I don't know. Roman: I mean I'll speak out of the mount. I mean it really comes down to like, how much scarcity do we think we need and do we need to roll in a gate to manage the scarcity right now? The precedent would be just to hand out the permanent, the permanent thing. To me that would be the easiest thing. But if we want to do kind of something fancy, and the IESG kind of feels like that. I personally wouldn't be kind of against it, I would just hope that we would write something up to help us better manage this decision making next time. EriK: I mean we don't get a lot of non IETF documents asking for these things, right? Eric: In my five years, this is the first time. Warren: People figure out that they can get an assignment faster by not writing a document, maybe we will get more. Eric: But in this case, right, so I'm pretty sure that the gentleman in this team, I guess there are students working on it or whatever, right? They simply want to stabilize the protocol and make some tests. So I think this is good for them to ask for a protocol number. Roman: So we gotta decide here. So I'm gonna tip us to not doing kind of something different in here whether there's objection. It looks like they have published in a very reputable kind of place. They have open source kind of implementations. Would there be an objective that we just gave them a permanent registration and, and thought about the future about how we would want to handle these to prevent the situation you were talking, Warren. Warren: That's fine with me. Let's assign Murray an action item to write up a document or IESG statement on this Erik: I have no objections here to approving. Eric: And I understand the hesitation from John and Warren, right? I'm not 100 % for agreeing it, but I think that's the best way to do it. Warren: It's Fine with me. John: Go ahead. Roman: I think what we have here is that we're gonna approve this and it sound I think the the idea of Ianabis is actually an excellent idea. I think we should take this to the working group to to kind of figure out how to handle it to the potential working group because we're not approved yet. Eric: And I will follow up on a separate threat without IESG copy, but with Eric and then I think I put in initially with John Ousterhout out, asking him somehow to make a draft at least would be appreciated. Liz: We will send the official note to IANA with that approval. 6.2 Approval of IESG Statement on Use of BCP 14 Key Words (Murray Kucherawy) Murray: I apologize. I got nowhere near this, so what I'd like to do is, this doesn't seek community inputs, so correct me if i'm wrong, we could approve this when we all get together in Dublin, right? Roman: Absolutely. Murray: I'm gonna try to get a few of us together before the first meeting if that's possible or at least we could do it during the week. I think I can do this faster with facetime. I'm a little stimy because when at the retreat when we said we were gonna do this is everybody was kind of that's a good idea, and so I volunteered to do it because I thought we were on the same page, and now the amount of feedback I'm getting back sort of at the last minute is a lot, I think I need to look at this again so I want to get a few people in the room and like let's just hash it out fast so that we have something to show everybody. Roman: Free to loop me in on that Murray, so I provided I think a bunch of proposed edits instead of comments. Hopefully that's more helpful. And I personally narrowed down beyond the editorial to like, I think the two substantive things we're saying about using those keywords and I think those are the ones I want to talk about. Murray: If you've commented on it, if I at the time I start working on this again, if I see that you still have open comments I'm gonna try to corner you with that cluster of people so that we have something we can finish up. Roman: We can also add it to the agenda of the Sunday or Monday meeting. Murray: I don't want to corner the entire room into what could turn into a long conversation, but yes, we'll do it that way. Liz: We'll put it on the agenda for 121. 6.3 IESG Statement Addressing Comments and Crediting Contributions (Orie, Francesca, Murray, Mahesh, and Warren) Roman: So I'll explain what I've done in the document and in the chat. I think there was all sorts of different feedback on it and I was as guilty as anyone else providing comments but not alternative texts, so at the end of the document, I have a rewritten version of the statement that merges some of those words and a bunch of the comments that were provided into a standalone statement for discussion if that's helpful. I don't want to take this away from Orie, Francesca, Murray, Mahesh, and Warren who have this action. Orie: Thank you for doing that. I think it needed to kind of top down restructuring. We've merged a bunch of comments iteratively. I think the next step is to see if we can get consensus to take the rewritten text as the new base and then figure out if there's anything left to add. Eric: And I raised my hand on this the new text is very nice, Roman, but I still wonder whether it should be one IESG statement or two because the two parts addressing comments and crediting links are vastly different anyway. Roman: I dropped it, I think 10 minutes before the meeting. Did you see my new introductory paragraph desperately trying to kind of say why they're related together saying the same thing? Eric: Nope. I'll do it right now. Liz: Should we also put this on the agenda for 121? Roman: Yes. Francesca: Yes, and maybe we can ask everyone to read Roman's version just as the base and be prepared to send feedback before the meeting. We can do a first pass in preparation for the meeting. Roman: I'm not a G suite expert and so someone tell me that I am kind of wrong here. It might be easier I don't want to be presumptive if the proposal I had made to synthesize everyone else's text was accepted, so it was in the document, I think it might be easier than to provide comments because I think providing comments on suggested text is a little different than providing comments on suggestions. Francesca: We should definitely accept that. Roman: It might be easier just to hammer on it. Francesca: I guess we can delete the first text before because he can anyway we can anyway see it back in the history, so there's some version control. I'll do that. Deb: No, I would say make it as clean as you can cause it'll be easier to look at. 6.4 Confirm IANA email re: IESG-related early allocation process questions (Paul Wouters) Paul: That's my comment too. I'm not exactly sure what this is referring too. Sabrina: I believe this was in reference to Amanda's email, Paul that she sent a while back, but, so we're working on 7120 bits at the moment, and we just actually uploaded a 00 version, but there is a line there that we wanted to confirm with all of you if you want to keep it as is in the document or if you want to change it. But it's regarding the, the temporarily expiration kind of proof state, so where we would freeze the expiration date. And, in 7120 currently says that when its submitted for review to the IESG, and so our interpretation of that is is when it entered the IESG evaluation state, but in the past, I think a chair has suggested that this could be read as publication requested. So we're not going to list the states in, I don't think that's what you want us to do anyway. But we just wanted your input on if you think, we should update that or if we should just leave it. Paul: Right, I remember this discussion now. We did have a few emails about this back and forth with IESG and I think actually John Scudder convinced me that that really is where we should draw that line personally. But we haven't talked about this with IESG, so I don't have any answer for IANA yet. Sabrina: We can continue the discussion over email if that's better and or check in with you also at 121 I think this was one of our updates. Paul: I'll add it to the agenda, and confirm it again with the IESG at 121. Liz: Ok. We'll discuss this further at 121 and no action for the moment. 6.5 [IANA #1385320] Designated experts for RFC 9660 (The DNS Zone Version (ZONEVERSION) Option) (IANA) Liz: Warren's new one and he's already got three names here; Hugo Salado, Mauricio Vergara Ereche, Duane Dwayne Wessels as designed experts for this registry and the objection to approving these three? Paul: Just out of curiosity, I've never heard of the 1st two names actually. Obviously Duane I know. Warren: So they were the authors of the document and I know Hugo from ICANN world. Liz: I'm not hearing any objection, so I think we can call those three approved and we will send that official note to IANA and to take that action item off your list, Warren. 6.6 [IANA #1385324] Designated experts for RFC 9559 (Matroska Media Container Format Specification) (IANA) Liz: This is the item just officially assigning this to Murray to find designated experts for RFC 9559. So Murray, you've got that in your queue. 6.7 Markdown as a submission format (John Scudder) John: This came out of me being grumpy that there appears to be some minority but still a large group of authors that just like click through and submit text because I don't know why that's what they've always done. Somebody else said well that's probably includes probably partly because they can't submit markdown directly and so they just generate the text and submit that which like to me is saying why can't they just submit markdown? Which led to Robert saying, if you want us to do that, you have to say you want us to do that. So I want us to say that we want them to do that. And I see that Warren has his hand up and I also see that Robert's on the call and if it's ok with everyone I would like to invite him to speak if he wants to. And I see that Eric also has his hand up. Warren: So, Warren's main concern is, if they submit markdown and it's just a pile of unreadable and usable stuff, is that helpful? I mean. One of the like my reasons for being cool with all of this is I really like having some sort of page numbers to be able to refer to and hopefully if it goes through a process, we get that at least. But if people just submit markdown I'm concerned it's not gonna render into anything that looks like an RFC unless there's a bunch of like markdown lint. John: so there's my answer on that one is I'm already starting to understand why Robert smacked me upside the head and said this is more complicated than you think it is because all that was happening in my mind was, I want to be able to take the cramdown RFC that I sourced that I currently render into XML and then submit the XML and have the site do the work for me in the middle. But your point is no people will submit all kinds of crap and we have to make sure that the rule is written which I agree with, but I think that whatever our statement is, it should make it clear that this is like an aspirational goal. We would like the to work towards this and we don't want to open the floodgates to you submitting just any random garbage that doesn't render properly. Robert: I'd ask a clarifying question from Warren. What is the distinction between pilot junk that's not useful in Markdown and pile of Junk that's not useful in XML? Eric: Or text. Warren: I mean, I've noticed often when I write cram down, I managed to mess up the references and similar things to that or like the author section. And yes, I can mess it up with XML as well, but generally I've been writing it at markdown, and then I used Martin Thompson's tooling which does it from cram down to XML to something and so there's like a sanity check. Where one of those parsers barf set me and says this is not a valid looking reference or your author template bit is misformatted. So I think it's the fact that I had to manually par pass it through some sort of parser, which does sanity checks. If the submission tooling can do those sanity checks, then I don't care. Robert: I had assumed that things would have to flow through something similar to IDNITS. Eric: And my question is that as far as I know, there are multiple dialects for writing markdown for an ID, so this could be challenging for swallowing it and digesting it by the tools team, but just my concern. But I don't object to your proposal John. John: Is it ok that we minute the, you know, statement either that's on the screen right now or something like that? Basically, nothing more to say. It's on the screen. Roman: I'm very comfortable committing to that. Liz: Robert, is that enough detail for you if we just say something like this or do you need anything else? Robert: This is fine. Thank you. 6.8 Registration changes (Liz) Liz: So just a quick update for you all. For some time we've been moving toward opening registration for multiple meetings at the same time. For a few reasons, e.g., allowing people earlier access to letters of invitation so they can begin their visa process sooner etc. And we're planning on opening registration for 122 this week, I think it might even be today. And there are a couple of consequences to IESG related things that we just wanted to make sure you're aware of. Firstly, we'll be changing the registration opening dates on the important dates. I'm not sure how we'll handle this long term in terms of like what dates will automatically assign for that, but for now, we'll probably just be manually updating some of the registration related important dates for the next couple of meetings. And then, the other thing is we may need to refine some of the details of the bof request process. E.g., adding a line to the template, be asking at which meeting are you hoping to have your bof because there's is a closing date for bof requests but there's no opening date, but we sort of feel like registration opening is a queue for people to like that it's time for them to submit their bof request. And so with the earlier registration dates, we anticipate people might be a little confused about when to submit their bofs and what the timeline is. we were thinking maybe adding something to the template, asking about what number, maybe some more explanatory text somewhere at the top of that page or another page about sort of how the process works, things like that. So I mean I'm not sure if people get confused, but we just thought maybe they would, so we'll be thinking through a little bit how to sort of make this a little clearer. Eric: I just want to know why would someone propose a request to bof for one meeting which is four months from now? Liz: like if someone were to register today for 122, like and try and submit a bof request, it's not actually clear from the request page like what the timeline is the the deadline, like per meeting is listed on the important dates, but it's not listed on the bof request page. So we were just thinking some people might just get confused about how the process works, when are the cutoffs and how does that go? So we were just thinking like some way we can add some more clarification to the bof request page about sort of how the deadlines work and that. Roman: I mean one thing that immediately jumps to mind to your question, Eric, is I've previously heard proponents say, I want to pitch the idea and I want to be ready and geographically more people are interested in my thing are in this kind of meeting kind of venue, and so they try to align because they think they can get more proponents to come on site because of the location and they may choose to delay as a result of that or accelerate potentially I've only heard delay. Eric: Fair enough. Liz: so we don't have any concrete changes right now, but just sort of a heads up that we'll be keeping an eye on this and also seeing if people are getting confused, and maybe using that as a cue to you know how we might need to explain this a little better for people. So I think those are really the only impacts to the IESG about opening registration earlier, but of course if you notice anything else that's weird or you think is not right. Eric: And out of curiosity, so will we be opening the registration four months in advance for all meetings or six months? Liz: I'm not sure if we have that time frame yet, so it might be a little too early to say I don't know if we sort of can exactly set what that interval is right now, but it kind of depends also on getting all the information for the letters of invitation and all of that, so more to come on that. 6.9 IETF 121 Prep (Roman Danyliw) Roman: I pretty much just have a basket of things to mention. I don't think they're long in a discussion items, just a few requests and a few heads up. Deb: Do you want an executive session? Roman: No executive session. First, I'm trying to prepare the agenda items for the joint meeting, our meeting on Sunday and then Monday and kind of Wednesday largely recognizing that Wednesday is gonna be largely focused on plenary prep and things that we think are related to that. So I think the biggest kind of scheduling is what do we want to put on Monday or potentially cancel the money meeting and what we do with the IAB and with ourselves on Sunday. One thing I wanted to mention that I'm going put on the agenda, Sandy knows this because we just talked about this, but this maybe new to you, Sabrina. We had a bunch of discussion I think over time when we ballot on how individuals have written up IANA considerations and are they very clear and separating the difference between being clear to everyone versus being clear to IANA who is lean forwarded, and trying to understand the best they can and like how do we handle that? The the RPC has been snagged by that. I know we ballot it a little bit, so I, we don't often get all three parties kind of together. So that is one item that when you see it on the agenda I wanted to explain the background on that. Roman: Then I wanted to warn everyone that I'm going to rerun all of the different analyses around the document pipelines sometime, maybe mid next week you can maybe kind of push me a little bit later. So now would be a great time to clean up public things to get the numbers. I can of course kind of hand change things as are required, but my intent, my working thinking is that I don't know yet how much time I can allocate during the plenary session, whether I can replay those slides, but I was thinking of replaying what I can't replay that I would put some of them in the IETF chairs report given that I've gotten indications that people actually kind of read that, so that might be a good, good spot to put some of those stats just so, I mean no action other than doing what you always do before. Realize I'm gonna probably do a run mid next week to produce some charts. Roman: Then the last one is largely just an FYI because we probably have talked about this at at different points in time. I had an action item to take our working thinking on, on those like recommendations letters or what have you done in the IETF contribution letter to talk to Systers about that. So after different kind of scheduling scheduling things have been discussed, what the sisters have have kind of gravitated around is that there will be a session on Thursday of the at lunchtime if someone's gonna correct me if I remember that correctly. They want to have a scrum with a small group of IETF leaders and the agenda is gonna roughly be me, Jay, Greg, Colin, and Tommy and Francesca and you, Deb kind of as well. I am gonna prepare, actually I've already prepared, I've sent you kind of links. All of the things that we have been talking about women's experience in the report for the experience of women in the IETF and some of the different actions and kind of lining up what we're doing, kind of what we're talking about doing. I've consolidated that with also things that is already happening in the LLC and kind of in one stop shop, and my plan is to kind of facilitate a bit of a discussion on what we're kind of doing kind of elicit feedback and kind of what not, and that's gonna be I think the good part of the agenda as the Systers have explained it to me, and in addition, the Systers before that are gonna explain some of the, some of the things that they are working on and explaining their charter. So I wanted to make you kind of aware that that's happening, but you are not looped into all of that. I would appreciate feedback on the slides if kind of possible that I sent around earlier this week. Alright, that's it for me, for IETF 121 prep. Is there anything else anyone else wants to mention to the group about? Murray: I had one thing about 121, but not about prep specifically. Ianabis passed its internal review. I wrote the text up for the external review, but I don't think it went out. It's currently scheduled for a telechat in November, but it has an agenda slot, so, what's our way out of this? Do we cancel the agenda slot or can we do this in a kind of a rolling approval if someone suggested. That we start the external approval and then if as long as it clears with no objections, then it's implicitly approved some that someone might look at that and go call shenanigans, some people might be fine with it. I just need a disposition here because it's kind of half approved right now and we need to, we need to go one way or the other. Roman: I would personally call significant shenanigans. If it's in external review, we can't convene it as a working group, we can convene it as a bof and as what are you, to me it would be what are you bof-ing, and if you aren't really bof-ing but you're trying to do the start of the meeting like we shouldn't do that. Murray: I mean if it's a first meeting, then it would be like organizing itself. What's the order in which we're gonna do stuff? And you can do that informally, you just can't, there's no chair, nobody's adopting documents, nobody's setting milestones or anything like that. Since it's got agenda time, we could do something with it but it can't have any sort of official status and it looks a little weird. So I think the cleanest thing to do is just remove it from the agenda. Roman: I strongly endorsed that because I think anything else begs a lot of process. Murray: So Liz, I guess that's where we're going. Roman: In terms of time, you were unable to squeeze it into this telechat? Murray: It needs two weeks of approval. Cindy: To a point of clarification, so there's some sort of multiple points of not greatness here. The default external review is for ten days. The minimum is one week and when we had talked about this, we had said that like when this is approved for external review, we need to explicitly call out that it's going to be a one week external review and we didn't do that. So when the message went out, the default ten day message or ten day external review went out, which put the end of the external review date after today's telechat. Murray: I didn't even see the external review go out. Cindy: I believe it went Thursday or Friday. Murray: Oh, here it is. We asked for feedback by the 28th, which is four days from now, yeah. Okay, so we can't it's it can't approve properly before IETF 121. Cindy: I will say that past IESGs have like we we've had that concept of placeholder both and past IESGs have used those for working groups that may not have finished chartering by the time the meeting rolls around, it sounds like the current IESG is less comfortable with using that, but I would be shocked if it hadn't actually been used before. Murray: The only thing I can say in favor of proceeding is that this is very likely, I mean look at the number of yeses it got. It it's very likely to be uncontroversial, and we haven't received any adverse feedback so far. Of course something could come in. But I mean I'm not gonna I'm not gonna push the point. It's not like this has to happen at 121. Francesca: But I mean it does feel a bit like a waste of meeting to not have them meet because of a process problem. Can we really not approve it at the IESG meeting before? I know we've had this discussion before and we we have refused to approve working groups before in that meeting, but I feel like that maybe that was because we didn't have enough like notice in advance to do that sort of approval and can we not just a formal meeting where we approve that? Warren: I think technically we could, but the optics around it are followed the letter of the law, but we didn't actually follow this for it. Roman: I would be very unexcited by this, and I don't think we should do that. Murray: No, i'll give you one other example of why we shouldn't do this. DKIM2 is pushing really hard for agenda time somewhere, and if I given if we if we bend for ianabis, we've gotta bend for that, and I really don't want to give them that sort of agenda time Francesca: What I'm saying is the only thing that we are missing is the IESG convening in in a formal meeting and approving it because we have done all the steps, right? We've had the internal review, external review, and then we're just missing a moment in time where we convene and we say, yeah, let's approve and we formally minute that as well. so if we consider like the weekend meeting as an informal, then of course you cannot do that during informal. But if we consider it as formal, at least for the part. I'm just wondering maybe and and this is. Cindy: From an optics perspective, the Sunday meeting, like the the meetings that you will have during the IETF week are not open to observers, which is one of the things you guys have been doing for the formal tele chats, so doing that at a meeting that does not allow observers, obviously I don't think that there's anything untoward here, but if somebody wanted to make a stink, they would. Roman: I'm concerned kind of procedurally so we would convene a special session to approve this what would be the threshold we would use to convene special sessions for any of the other things that we did not get during the regular IESG meetings. Francesca: To be clear I wasn't suggesting that we convene a special meeting. I was saying we are meeting anyway. Can we use that meeting and it's a little bit different but Cindy has a point that we don't have observers. Eric: When is ianabis scheduled? We could approve it during the plenary, there are observers. I'm only joking. Warren: It does actually it does feel like initially it kind of felt like a joke, but it does feel like if we went to community and said hi community, we understand you want to do this because of weird process reasons we couldn't, so we'd like to do this now in a public thing and we would like to do it that way. We've dotted the I's and crossed the T's. I think the community would be ok. I'm not sure if it's on fire enough to do that, but I think if we really wanted to be. Murray: I appreciate the creativity but I think the precedent this would create would be too dangerous for us. Cindy: The minutes of the plenary are not the minutes of an IESG meeting. Murray: There's this new effort with lots of large operators in the application space. Dkim two is the successor to dkim. They really, really want some agenda time somewhere. They try to get into all dispatch but it's full. And they are just like we were just doing coming up with all kinds of creative ways that they can get some kind of airtime. Can all dispatch have a second session where they get some airtime? Can mailmaint get a 2nd session so they can get some airtime there, even though mailmaint will determinately not take up this work cause it's too big. They have a side meeting but like what's the point of traveling all the way to Dublin for a side meeting if that's all you're gonna get? So is there anything they can do? I don't know what people's thoughts are about adding time to all dispatch. I don't have a lot of other good options. I could give them the ianabis of this slot if we're gonna cancel it, but it's not a working group, it's not even a bof yet. Warren: Could mailmaint or someone put a request in for a second session and they use that second session during ianabis time. Murray: Weird thing and tell me what you think of this dkim2 two will absolutely not become a mailmaint work item because mailmaint is chartered for just small things and Ddkim2 is a complete overhaul of dkim, like that's it, it doesn't fit their charter. But if they need airtime somewhere, like this could be like an AOB ART area type thing. I just think that looks a little weird. Warren: I mean DNS OPS is giving some time to something which is gonna be in UTA, but UTA's not meeting and so DNS Op is like, you know, it's related to the DNS, you can talk about it here. We're not adopting it but we wanted people to be aware, so that feels like it could be done or a late approval of a bof. Roman: No, please. Francesca: Why don't you take the ianabis slot and make a late ART area meeting if you don't have conflicts, and you and Orie are the chairs so you can put whatever you want on the agenda. Murray: The other alternative I thought was making in ART area meeting but it would be an ART area meeting just for this, which also has bad optics, like it's clear I'm favoring this group to get air time. John: It's clear that your favoring this because you think that it's an important topic and has community, forced behind it and like isn't that our job actually is to identify valuable work and then favorite it? Warren: Yes, but as long as it doesn't look like you're favoring your own stuff. Paul: We could wing it a little bit and give them five or 10 min at saag since clearly this is a security area. Murray: Do you have 5 minutes at saag? Warren: Is alldispatch full? Murray: Yes. And like one of the solutions to this was, can we just create a second alldispatch session and continue their agenda there? I don't know if the chairs would be happy with that. Nobody's actually approached them about it yet. I don't want to spring that on them and go, you've got one more session to manage. Paul: I don't think you can do that because they did send emails saying no more proposals. Roman: The other piece is, does this have a document to actually dispatch? Murray: There's really only one outcome for something this big, but I mean, we could go through the dispatch motions, but they do have a draft apparently, I just haven't seen it yet. There is no charter though. Roman: I just wasn't sure if there was a document or just an idea. Murray: I understand what the idea is and they told me just yesterday that there is finally a draft available, but a draft, like a draft, an internet draft but a charter draft. Roman: No, I meant an internet draft because one of requirements to enter the gate or any dispatch is typically a document. Murray: I think i'm going to go the route of trying to get mailmaint a second slot or if they can fit themselves into mailmaint somehow now, I'll try to keep it there, even though it's a little weird because mailmaint absolutely will not pick this up. I don't want to create an ART area meeting that's that's clearly just for this one thing that I think needs air time because then again a precedent. Someone down the road is going to say: 'hey, you did this for them so why aren't you doing it for me?' Orie: Maybe if 5 minutes of saag is available or hotrfc? Murray: Paul, i'll ask you about saag offline. Deb: We don't have a problem with them taking 5 minutes of saag. Murray: My only thing is 5 minutes enough? I think they might want 10 minutes. Deb: That's fine. There was an email about this that came out, do you remember where? Murray: About dkim2? Deb: Yeah. I saw it earlier. Murray: There was some stuff about alldispatch. Paul: I also talked to a few people on Slack about Stephen Farrell ended up meeting with the dkim2 people. Deb: Maybe you sent it to me, maybe that's where I saw it. Murray: That's i'll figure it out from here. Liz: We're taking ianabis off, but we're not putting an ART area or anything in it's place. Murray: No, not an ART area. I might ask for a second mailmaint slot if a chair is willing to run that. If not, i'll see if I can pack it into the tail end of saag or mailmaint. Delete ianabis, and I may come back and ask if we have open slots if we decide we want a much longer session. 7. Any Other Business (WG News, New Proposals, etc.) Roman: I would just remind everyone now's a good time to provide your NomCom feedback. Warren: That's a good time to provide your NomCom feedback, and I put the link in the Slack so everybody can easily click on it. If people don't provide feedback, you're going lose the right to complain if I get reappointed or something. The NomCom really does need feedback, and the IESG you get is the one you help create. Eric: It looks like it's pretty efficient this time. I got my interview slot already booked ten days in advance during the IETF week and the convenient time for me which is good. Liz: Yes. Jenny's helping with the scheduling this time, so those of you who are up, you should have already been in contact with her about scheduling your slot. If you have not yet, then please check your email. Roman: The last thing I just mentioned, if anyone hasn't noticed I put out the meeting experiment stuff we talked about to IETF announced, so it's public.