**Session Date/Time:** 16 Mar 2026 06:00

This is a verbatim transcript of the PROCON working group meeting from IETF 119.

**Leslie Daigle:** Okay, I think it's time and we should get going. All right. So welcome to the PROCON working group meeting. I'm Leslie Daigle, I'm your co-chair.

**Yari Arkko:** And Yari Arkko, the other co-chair.

**Leslie Daigle:** So, please do note well even if you have participated and perhaps participated in writing the note well. These are the terms under which we have IETF meetings and you participate in them. If there are any elements here of which you're unsure, please do go ahead and read the material describing the expected behavior in detail.

Okay. Some meeting tips which you may already have been exploring if you were in dispatch this morning. We will be using MeetEcho for the queue whether you're in the room or remote. So everybody please make sure to log in if you haven't already. And some handy resources. 

All right. This is our agenda for today. We've done the note well, and thank you very much Pete Resnick for agreeing to take notes. I know he is soliciting for others to help him in the group edit document, so please do join him in there and help. Are there any bashes to this agenda? We've got a thumbs up from Barry. No other reactions. This is the first session after lunch in this time zone, so it's going to be lively. 

All right. So first up, we will go to Rich for the 2026bis update. Rich, do you want to drive? 

**Rich Salz:** No, why don't you—there’s only five slides, so I'll just say next. 

**Leslie Daigle:** All right. Hang on. Still going through all the clicky clicky. All right. 

**Rich Salz:** Okay, so the update since we last met in person. There have been four drafts. This is I guess the second meeting of the PROCON group. So 02, published in December—1st of December. This clarified that decisions, not discussions, must be public. Because it had come up in recent things, you know, anyhow, that's all. That's the only semantic content in that revision. Plenty of time for people to absorb that. 

Revision 3, in late January, pointed to BCP 78 for the definition of what a contribution is. Clarified the procedures for experimental and informational. Clarified that ADs can delegate to another AD when handling an appeal. Added AD-sponsored as an example of a non-working group creation of or initiation of an RFC. There are other paths to have them created, right, and then progress through the Internet Standards process. Point out—clarify that the LLC maintains mailing lists and public records. It previously said that every working group must have a mailing list. Well, yes, the LLC handles those kinds of things. Minor renaming of the IETF Trust to the IETF IPMC. And some other minor editorial wording changes. Things like where is in the previous publication, things that had to be emphasized were set offset from the left margin and surrounded by rows of asterisks. We have more technologically advanced ways of doing that now, you know, typefaces and such. So some of those appearances also changed. Next slide. 

At the end of the month—end of January—Pete pointed out that we were pretty much able to remove the terminology section completely. There were only a couple places where we had to point—either make some forward references or the terminology says you should now know who the parties are as defined in RFC—and I don't remember what the number was, but the one that I wrote that updated a previous thing. Some editorial changes: consistency around the Internet Standards process, avoiding things like hyphenating "Internet Standards related". Erroneously change "RFC Editor" to "RFC Publication Center". It should be "Production Center"—fixed in the next draft. Updated the BCP definition and explain that that's how the IETF—that's where the IETF—the sub-series that the IETF publishes the documents that control how it works. Sometimes it was called a sub-series, sometimes it was called a sub-stream, so made that all consistent. 

A couple days later, updated the Internet Draft section thanks to Brian Carpenter who pointed out there were some inconsistencies about where Internet Drafts were defined and maintained and used between 2026 and 2418. So that was all done. Yes, Jean, it’s the later draft—Yari pointed that out also and it’s fixed in the editor's copy right now. 

Okay, so that’s everything that’s happened since in terms of draft publication. Next. 

Also, in 124 we asked the IESG—Miri, Miri-a, sorry, brought up that there have been some BCPs that were published on the IAB stream. Brian was there or did some other research and all of those went through the IETF consensus process. So while they are marked as being on the IAB stream, we asked—Brian and I—asked the IESG to ask the RPC to change them all to be marked as being in the IETF stream, because some of them had to do with how the IETF does its work. Sent a copy of that email to the mailing list. We got an ack from our chair, from Roman, saying "yeah, we’ve got it, we’ll get to it at some point presumably." But that’s just—disentangling that historic thing, it was sort of the last thing about the confusion about where BCPs can be published, because other text says that if it’s published on the IETF stream, of course it must have IETF consensus. So all of those documents had consensus, and so we’re asking that they all be—indicate that they are published on the IETF stream. 

So Roman is in queue. Roman, do you want to speak to that point? 

**Roman Danyliw:** I do. Hi. Thanks, thanks actually for the group for identifying that issue. Yeah, we have not had a chance to get to that as we were preparing for this meeting, but we have it scheduled for the next telechat to walk through those documents and get the IESG opinion on that. So we'll have more back to you soon—pretty soon after this meeting. 

**Rich Salz:** Great. Okay. Is it a nit on the slide that—I’m just reading the commentary from Robert there, the question. Yeah, what should really happen—the problem is that the stream implies, right, where the thing was published, or who wrote it. In most of the cases, it doesn’t matter. In cases where it does, the IAB documents have to—should explicitly say this is an IAB thing. It’s kind of weird that the IAB chair authored one or more IETF BCPs, but so it goes. 

**Leslie Daigle:** So I see a number of people in queue and I’m wondering, do we want to dive in more into this now or are we going to wait and see what the IESG thinks? And I’m sort of looking at you, Rich, for thoughts. 

**Rich Salz:** We already made the request and put it on the list. If people have comments, sure, happy to hear it now. 

**Leslie Daigle:** Okay. Eric. 

**Eric Rescorla:** Yeah, I guess I’m not sure all these documents did have IETF consensus. They may have had IETF last calls. That’s not the same thing. And certainly when I was in the IAB, we did not feel like we were bound by the IETF consensus process before publication. So, um, so I’m not clear to me—I’m not sure actually that works. 

**Rich Salz:** Okay. Brian. 

**Brian Carpenter:** Yeah, I was going to comment on the same point basically. I believe that all the ones in question—I went back far enough in the records and they all have tracker entries, which is a bit of a miracle for the older ones. They all do seem to have had, you know, some sort of last call. It might have been less formal than today because we didn’t have the tooling. And, um, so I think investigation would show that they all did go through some version of the consensus process, though not necessarily the consensus process we have today. 

And the other comment is that back in the day, the IAB was not consistent in how it handled authorship in their documents. So some of them have a list of members, some of them don’t. It was all a little bit dumb, a little bit loose. So I’m fairly sure that all the ones we mentioned in our message to the IESG really did go through a BCP consensus process. You know, we’re not talking about informational stuff or opinions of the IAB, we’re talking about consensus documents. So, um, anyway, I’ll leave the IESG to look at it, but that’s my opinion. 

**Leslie Daigle:** Barry. 

**Barry Leiba:** This is Barry Leiba. I’ll go a little farther than what Ekr said. I’m quite convinced that they are not—that they do not have IETF consensus. For the most part, they were put out for comments, not for IETF last call, and there is a difference. They were not approved by the IESG, so the process was entirely different. I’m okay with picking specific ones where there is a reason to move them to the IETF stream and addressing it that way, but just taking all IAB-authored RFCs and moving them to the IETF stream does not seem the right thing to do. 

**Rich Salz:** Sure, I’m sorry if I was—I mispoke there. It wasn’t intended to move all of the—all of the IAB RFCs. It was specifically the ones that are labeled BCPs that had to do with IETF operations and procedures. 

**Barry Leiba:** Ones that were published as BCPs probably did have IETF consensus, so I would be okay with that. We just need to be careful about which ones we move and which ones we don’t. 

**Rich Salz:** Yeah, no, there was an explicit list in the mail that went to this working group and to the IESG. 

**Barry Leiba:** Okay, thank you. 

**Leslie Daigle:** Yeah, I think that mostly covers what I raised my hand for as an individual participant, not as chair, is that, no, you certainly can’t take all the IAB documents and make them IETF stream because the IAB ain’t the IETF. And I had recalled it as being about the—if you’re going to publish something in the standards process, which is what the BCPs and standards are, then that’s a different question. So yes, we have to be pretty crisp in our terminology there. So speaking to the slide is not really that helpful, it’s more about speaking to the issue. So I locked the queue. Paul, go ahead. 

**Paul Hoffman:** Paul Hoffman. So I have a concern and I'm—I’m sorry, I don’t remember if it was Ekr who brought it up, which is a saying something's an IETF stream document or, you know, that it’s a BCP that was not actually after the public comment was considered in the IESG and had a vote and such, and I don't think some of those did because they were IAB documents. My question here is: are we going to have sort of two types of IAB BCPs? 

**Leslie Daigle:** So, having lived some of that dream— 

**Paul Hoffman:** Right, exactly right. And I didn’t. I just want to be very clear. Yeah. 

**Leslie Daigle:** I think that as Brian articulated earlier, it requires a little bit more digging and clarity and fact-finding. So I think again, we shouldn’t be speaking to what’s on the—on the slide, but recognizing that the issue is making sure that if there were things that are—were BCPs and, you know, put them in the IETF stream if they demonstrably had the kind of process review they needed. 

**Paul Hoffman:** And I just want to make sure that that includes an IESG evaluation of the public comments. And if not, we can have two types, but I would like to make that clear. Thanks. 

**Yari Arkko:** Yeah, Yari. So just to make a chair comment that this issue initially came from the discussion in this working group, but we’ve sort of handed it over to the IESG, and the IESG will for sure make a careful determination, take all the comments that were spoken today into account and they'll do the right thing, but it’s not our job in this working group to figure out the details of that. 

**Rich Salz:** Yeah. I didn’t carefully edit the slide after I—before I submitted it. It's not to reclassify all IAB-authorized IETF BCPs, not all of their RFCs, like it should not be on the IETF stream for the report on monitoring networks and, you know, and so on. 

**Paul Hoffman:** My point is just the ones that came out of the IAB but were really IETF documents in the first place. 

**Rich Salz:** Yes, that’s what we’re talking about. Yeah, and there’s a specific list and I'll repost the message to the list. Roman pasted it into the chat. Okay. So that’s what has happened up until now. 

Pending changes. The editor's copy: Pete found a bunch of editorial nits a couple times, Yari found one about RPC and the "P" being wrong. We have two public pull requests waiting. One point out—remove some words because STD and BCP sub-series need not get a—need not have a new RFC published. Also, by that wording change, it also makes it clear that a, for example, BCP 9, I guess that includes 2026, would then be changed to uncover—to include instead what this new RFC would be. So that’s all. They—sometimes they'll get a new number, sometimes they won't. Sometimes a new RFC will be published, sometimes the new RFC will not be published. We have examples of both. 

Another pull request, 71. This section that talked about how the IESG looks at the draft—when given a draft to be published, reviews it, decides what track it should be on if it disagrees with what the original proposal is. It goes to IETF last call. After the last call is done, they may—the IESG may decide, okay, based on the feedback we heard, it shouldn’t be proposed standard, it should be experimental. I sort of shuffled around a few sentences about that to make it look more chronological order. Pete suggested the wording is still worse—is now worse. I don’t know if anybody cares other than Pete and I. If anyone has strong feelings, post to the list or say it here, otherwise I’ll probably just revert it back to the way it was for efficiency. 

**Leslie Daigle:** Pete, you're in queue. Did you want to speak to that point? 

**Pete Resnick:** No longer. 

**Rich Salz:** Okay. So yeah, the plan on 71 is just to go back to the original text—the previous text. 

Next steps. New draft to come out which will have just the couple of other changes that were mentioned on the previous slide. And then I think it’s ready for last call—working group last call—and push it out along the process. Great. 

**Leslie Daigle:** Any—anyone want to make any other comments? Any final thoughts from you, Rich? Sounds like a plan. 

**Rich Salz:** Sounds like a plan. The room from here looks like a waiting room for a Chinese restaurant. I hope nobody takes offense at that, but... 

**Leslie Daigle:** Well, I mean, it is positively bursting with people at this point, so I mean we’ve made great progress. Great. Thank you, Rich. 

**Rich Salz:** Okay. 

**Leslie Daigle:** All right. So, are you ready, Dave? 

**David Schinazi:** Yes. Let me see how this works. We haven't tried doing a remote presentation from Tokyo yet. So, can you hear me all right? 

**Leslie Daigle:** Did you—I think I’m going to have to do the—hang on. Who’s driving? 

**David Schinazi:** Uh, I’m not. 

**Leslie Daigle:** Should be me, but—oh, there we go. Sorry. I will—okay. Are you ready for the next slide? 

**David Schinazi:** Uh, well, just can you hear me all right? 

**Leslie Daigle:** Yeah. It’s better when you’re a little bit closer to the mic, but that sounds okay. Yeah. 

**David Schinazi:** All right. Sounds—here, let me actually put you like this so I stop looking so ridiculous. Okay, there we go. All right. Hi everyone. I’m David Schinazi, one of the editors on 2418bis. So, next slide, please. 

A quick update for in the odd chance we have someone in the room who actually hasn't been at the previous meeting—it doesn’t appear to be that way on either of the camera feeds—but um, we’ve been starting this kind of for the past few years, um, but more recently now that we’ve kind of adopted the documents, I’m going to start doing a—like today focus on everything that’s changed since Montreal, which was our meeting last November. And then we’ll have time for open issues at the end. Next slide, please. 

So, one of the—one small change that we had, we were talking about the working group facilitator. We added a mention of moderator next to that. Someone realized later that that actually wasn’t the right fix, so we have another fix that we’ll discuss in a later slide, but that is what is in dash-01. Next slide, please. 

And, um, another one over the updates—we had at some point added a reference to RFC 7322 which, as you can imagine, was did not exist—or for the original 2418. Um, and the discussion kind of decided that we didn’t really need that reference anyway. It’s—it’s just a style guide that’s just guidelines, so we just ended up removing it because it wasn’t helpful. Next slide, please. 

Similarly, um, well, not that similarly, um, we had a lot of text that described individual drafts in this document. And it was kind of duplicative of what we had in 2026bis, so we said let’s just delete that and instead have a reference. So again, simplify things and puts all the knowledge in one place. Um, just a simple PR. Next slide. 

Another one in terms of matching reality. There was a lot of text in 2418 about how to schedule working group meetings, and all of it involved emailing agenda@ietf.org, which is something that we haven’t done in at least a decade because we have better tooling. Um, so we had a PR that pretty much just says—removes all of those and just mentions that the chairs request sessions through the secretariat and is not prescriptive about tooling, we might update that later. The details don’t need to be in the RFC anyway. Next slide, please. 

Another one is these are like the six and now seven items that are mentioned in 2418 about what should be discussed in charters for new working groups. Um, there was a request to add privacy next to security, and we have kind of some precedent there thanks to 6973, so we just added a privacy bullet in there. It’s not particularly normative list, but a good thing to keep in mind. Next slide, please. 

Um, someone mentioned that the word "staff" used in a—like three places in the document was a little confusing because in other standards bodies, staff is often a paid position, whereas at IETF, our working group chairs and other roles are not. So we replaced that with the word "role". Editorial change. Next slide, please. 

Um, another aspect, so I forget the number of the RFC, but many years ago we removed the draft standard from the Internet Standards track. Um, and it was—so that’s been kind of cleaned up in 2026bis already, but 2418 was still mentioning that in two places. So we had a PR that kind of cleaned that up, and part of it was kind of some text about working group being dormant, so that we can progress a standards track document to the next stop on the standards track. In practice, that hasn't been done in years. I don’t think I’ve seen it happen in a decade. 

**Colin Perkins:** We did it in RMCat recently. 

**David Schinazi:** Oh, so but was that group dormant before then or was it just an active group? 

**Leslie Daigle:** We didn’t—we didn’t hear the actual—sorry. Let me repeat for the caller instead. So that was Colin Perkins saying that in what working group? RMCat, uh, they actually did this. 

**David Schinazi:** So that’s helpful. Thanks, Colin. Um, so we kind of tweaked that text, maybe we can put some of it back then. We’ve definitely—we have a new PR that will kind of mention that once the working group is closed, you can still have the mailing list open because that’s easy and pretty commonly done. Next slide, please. 

All right. So, there was some text in 2418 that mention—that tried to explain consensus a little bit and said, well, 51% doesn’t mean consensus, but 99% doesn’t mean that either. It was a little bit confusing. We decided instead to—since this is not normative anyway—to reference to Pete Resnick’s very good RFC 7282 instead, which kind of goes into way more detail about how consensus works in the IETF instead of having this odd sentence that tries to encapsulate it. Ekr, go ahead. 

**Eric Rescorla:** Why do you say this isn't normative? 

**David Schinazi:** Uh, there aren't any 2119 keywords in 2418 or—actually there are, sorry. 

**Eric Rescorla:** Good. The text that I deleted didn't have any 2119 keywords. Let’s say that—that's— 

**Eric Rescorla:** I agree with that. But I actually object to listening—to referencing 7282. So, um, I think there’s a lot of very misleading stuff in there that actually we don’t do, and I—I regret that I didn’t object to it when it was published. But—but um, but notice it does not—it actually quite carefully says that the contents do not have consensus. Um, that merely was consensus to publish it, and so I—I really strongly object to actually upholding it here. 

**David Schinazi:** Even if we included it in the current form, which is to say that it—it says as examples of how to reason about—do you still object to that reference? 

**Eric Rescorla:** Yes, I think I think—I think some of it’s just wrong. I think the stuff about like 99—if—if like 999 people think one thing and—and one person thinks the other thing, that can be consensus and the one—that's just like wrong. And we don’t do it, and like we shouldn’t say it. So, no, I—I just—any reference at all is 7282. 

**David Schinazi:** Okay, that’s— unless you want to say it’s wrong, which I'd be fine with. I—I don’t think it would be helpful to include it and say it’s wrong. Um, okay, I think we might—like, let—can I ask you to file an issue on that and let’s keep the—take the conversation there? 

**Leslie Daigle:** So we have two people in the queue. Myself first, and no chair hats but just observation that the reference is informative in the current text. 

**Eric Rescorla:** That makes me no happier. 

**Leslie Daigle:** Yeah. So I think what I was going to say was it sounds like that there’s—there’s been clarification that there had been a normative statement, even if it didn’t have RFC 2119 language in it, so it shouldn’t be taken out. Um, I think it’s—there’s an open working group discussion about whether or not it’s helpful to refer to the more detailed document. And I think that is still an open working group discussion, although clearly Eric doesn’t think so. Um, not—doesn't think it should be referenced. Um, so David, I think that—I think that means that this needs a little bit more work in terms of reframing it. 

**David Schinazi:** Yep, I—I absolutely agree. Especially the definition of consensus is one of our core tenets, so that deserves our time and attention to get it right. So absolutely, I’m down to spend more time on this one. Colin? 

**Colin Perkins:** You're going to have to come up here to the mic, though. 

**Leslie Daigle:** How near do I have to get before—no, that’s good. You look good. This is good. 

**Colin Perkins:** All right. Um, so I—I agree that 7282 cannot be a normative reference and doesn’t have IETF consensus, and it explicitly says that in it. I do not agree with Ekr that it is incorrect and that the 1% 99% thing is wrong. I think we do that all the time. So, uh, I think we need some more discussion here. And I think this is one of the fundamental things about how—how the IETF works, so we—we really need to get it right and maybe that should be a separate document, I don't know, for those small parts of that RFC. 

**David Schinazi:** Definitely agree with that. Um, Miri is next. 

**Mirja Kühlewind:** Um, yeah, Mirja Kühlewind. So 7282 has IETF consensus. It has a preamble saying "This is not a BCP, it's an informal reference on purpose", but then it further says it has IETF consensus, so I don't see a reason why we shouldn't reference it. We can discuss if we want to revise 7282 because we don't agree to it anymore, but it has consensus then we should treat it like that. 

**David Schinazi:** Didn’t we say that 7282 didn’t have consensus? I’m going to re-read it more thoroughly, but like okay, let’s take it to an issue. I think this one deserves more—more conversation. Uh, Ekr? 

**Eric Rescorla:** I'm actually finding the text. So I think there are two points. One is I agree with Colin that we will sometimes let a one—a one—a single dissenter stop—stop something from going forward if their arguments are strong enough. What I do not agree with is the claim in 7282 that we will sometimes say that you can advance a document, you can go—that—that the—that not only is the—not only is the 1%er right, um, dissent can stop, yes, um, but also—also that you can declare consensus and say "Oh, the other people are wrong and they can shut—they can shut up." And the point—and I was going to quote the text that Mike Bishop just quoted in the—in the chat, which is "This document is quite consciously being published as informational, it does not present any IETF process different out of a BCP. It's simply a collection of principles, hopefully around which the IETF can come to at least rough consensus." So I don't think that—so there's consensus to publish, that doesn’t mean consensus on the thing itself. Um, so um, so I think that—that's what I got back in the queue to say. Well, that and the 1% thing. 

**Leslie Daigle:** Yeah. So I think this is another issue where discussing around the text on the slide is—is going to send us in circles. So David, I think you have the right of it, it’s another—it’s another request: send text and—and we'll see what happens. 

**David Schinazi:** Absolutely. And I’m not going to put Pete on the spot today, but I will ask you to comment on the issue, Pete. I would love to have your thoughts as well. All right. Next slide, please. 

All right. So, 2418 never mentioned the concept of a working group adopted document. Um, it is something that we—every IETF working group uses, um, that our tooling and the datatracker supports, um, and that is an integral part of our process. So we—I wrote a PR to actually define adoption. That’s the extent of the paragraph. Um, pretty much it just says that working groups can adopt documents and the diff—what that means is that the working group has change control. Anyone have thoughts and opinion on that? 

**Deirdre Connolly:** I should get in the queue. Um, do we have to do any work to define—speak up, I’m not sure that the microphone can pick you up. Is there any work that we need to do to define hands over change control to the working group? And for the sake of the note-taker, we're going to need a name for the speaker. Deirdre Connolly. 

**David Schinazi:** Uh, not in this current PR. It doesn't define it any more than this. Are you suggesting we should? 

**Rich Salz:** Well, 2026 says that anything that goes forth as a standard has to meet the—the necessary IPR requirements. So I think that may be enough. 

**David Schinazi:** What does that have to do with change control? 

**Rich Salz:** Because you're giving the right—in the—in the IPR requirements, sorry, you're giving the right—you have to IPR requirements and the rights you are granting to the IETF. Both things are mentioned. 

**David Schinazi:** Yeah, but that's different from change control. 

**Rich Salz:** No, because you're giving the right—one of the rights you're granting to the IETF is them to modify it. 

**David Schinazi:** Okay. And we have a queue: Ekr is next. All right, Ekr, go ahead. 

**Eric Rescorla:** Yeah, so um, I—I think um, that this text is fine, but I think we probably are going to need to be clear about what—about what is required for adoption and whether it is a working group decision that needs to be taken by consensus. And when I read—when I read the text of 2418, the current 2418, it seems to me that all working group—all major working group substantive working group decisions are made by consensus. And the question is: does this become such—such a—such a working group decision? And—and we've already seen this be relevant in at least one working group in the past, you know, three months. So I think it's probably important to actually like not necessarily leave that be, um, you know, not just leave that be empty. 

**David Schinazi:** That's—and just to make sure I’m understanding you correctly, Ekr. You're saying that we should say that working group adoption is a decision taken by the working group as a consensus of the working group. Sorry, right? 

**Eric Rescorla:** I—I believe—I believe we should say that, but I think either we should say that or we should say it is one—is unilaterally granted to the chairs. But we should not do is be silent. Um, I would—so if we are—if we are voting or taking a hum, I’m humming for say it has to be by consensus. I think that's what it should be. But I think it would be better to say it was within unilateral grant of the chairs than to say nothing at all. 

**David Schinazi:** Okay. My gut feeling would be to say that: that it is a consensus decision, because that's how every working group I know operates. So if anyone disagrees with that, please get in the queue to say so. Um, ah, I—I guess I would observe that the—the recent um response by the IESG to um an appeal suggests that they believe perhaps it does not. Um— 

**David Schinazi:** All right, then I think I need to read up on that. Um, okay. Pete? 

**Pete Resnick:** Yeah, um, I definitely have been part of working groups which do not do a formal call of consensus for adoption. Um, it’s just simply um a relatively new practice, new past decade, um, but it is certainly not universal. Um, it’s still the case in some working groups that in the room, um, enough people uh do not motion violently against adopting and the chairs say "Okay, this seems like a fine starting point." Um, there was the whole discussion of adopting a document can be assigning an editor and starting them with a blank page. Um, you know, this is just—this—this would be new. Um, so I would prefer to have it um clear that it's not necessarily a consensus call by the working group. 

**David Schinazi:** Okay. And so Pete, before you go, you—we should define it as a decision of the chairs then? Or something else? 

**Pete Resnick:** I think I would be fine with that. I think there is something implicit in 2418 that the chairs are supposed to take the lead from the working group, um, but and so I'm less queasy than Ekr about just letting it be silent on the topic. But if we're going to say something, saying that the chairs can make a call to assign a document editor and take it on as a work item is probably closer to the truth. And, you know, or we can say the chairs can do that, you know, um, and may ask for working group consensus to—to adopt a document, something like that. 

**David Schinazi:** I mean, it makes sense: like the chairs pick document editors unilaterally, and so having this in that same vein is—is reasonable to me. Yeah. Mirja? 

**Mirja Kühlewind:** Mirja Kühlewind. Um, I totally understand the desire to say something about adoption because we use it very often and it’s weird to not like say anything about it. Um, but I would rather say less than more here because effectively it’s not really part of the standards process in the sense that at the end of the standards process you have to have consensus in the working group and you publish the document as standard, and that’s the important part. Like anything else like this is more kind of how we internally organize our working groups and make ourselves, you know, more comfortable or like finding a better process to move forward. So it’s not really a requirement of the standards process. Um, the—and I—and I think the point about change control is actually wrong. Uh, so as soon as you submit a draft you give change control to the IETF. You can just like take the text and work with it, find new editors or whatever. It’s just like a matter of how we’re handling things that authors of a document, I think, are more careful like as long as it's an individual document you just like freely edit things, and as soon as you have a working document you try to more carefully, um, look for working group consensus and update based on that. But that’s also because at the end the working group has to decide if it wants to approve the document for publication, and if you don’t do that, it will not happen, right? So it’s—like—this is how we handle it but it’s not really like a formal requirement, so I wouldn’t put in this document. 

**David Schinazi:** Thanks. I—if I can respond as editor, I think the fact that we had an appeal on a document adoption recently indicates that probably we should say a bit more, um, as my personal opinion. 

Go ahead, Fluffy. 

**Cullen Jennings:** I—I think I was going to poke on this change control thing. I don’t—I don’t think change control’s the right metric for what you’re trying to hit at here. I think it actually— because every—you know, everybody has change control in many ways to every document. Um, I think the thing that is important about a working group document is that at some level to the best of its ability, it’s trying to reflect working group consensus. And maybe I’m wrong about that. I’ve seen several working groups lately where they do not try to have the document reflect, you know, have reflect working group consensus. Um, but I think that that is the important thing that we sort of need to come down on and figure out a little bit here. And I think that traditionally in many working groups I’ve been in, it’s been like "Yeah, the working—the document represents working group consensus." Um, so I—I think that might be a better way to poke for the definition of how to write this. Thanks. 

**David Schinazi:** All right. And we can say things a bit more vague in terms of aims towards the consensus of the working group, because I think it’s very common—take for example, I landed this PR, no one objected it when I landed it, clearly it doesn’t have working group consensus based on the discussion we’re having today, so it kind of equalizes over time but might not be true at every single point along the way. So that—but I can—I can take a stab at incorporating that in terms of consensus more than change control. Okay. 

**Eric Rescorla:** So, um, I actually find the text... so, I think there are two points. One is, I agree with Colin that we will sometimes let a one—a one—a single dissenter stop—stop something from going forward if their arguments are strong enough. What I do not agree with is the claim in 7282 that we will sometimes say that you can advance a document, you can go—that—that the—that not only is the—not only is the 1%er right, um, dissent can stop, yes, um, but also—also that you can declare consensus and say "Oh, the other people are wrong and they can shut—they can shut up." And the point—and I was going to quote the text that Mike Bishop just quoted in the—in the chat, which is "This document is quite consciously being published as informational, it does not present any IETF process different out of a BCP. It's simply a collection of principles, hopefully around which the IETF can come to at least rough consensus." So I don't think that—so there's consensus to publish, that doesn’t mean consensus on the thing itself. Um, so um, so I think that—that's what I got back in the queue to say. Well, that and the 1% thing. 

**Leslie Daigle:** Yeah. So I think this is another issue where discussing around the text on the slide is—is going to send us in circles. So David, I think you have the right of it, it’s another—it’s another request: send text and—and we'll see what happens. 

**David Schinazi:** Absolutely. And I’m not going to put Pete on the spot today, but I will ask you to comment on the issue, Pete. I would love to have your thoughts as well. All right. Next slide, please. 

All right. So, 2418 has some text that says the main difference between a draft owned by an individual and one adopted by a working group is change control. Is that also something that we should look at? 

**David Schinazi:** Oh, I see. The difference between an individual draft and a working group document. Yep, that— I can—I can change that. Thank you. 

All right, next slide, please. Design teams. So, the 2418 mentions them already. We still make use of them quite regularly. Folks have pointed out that we don't put any constraints on design teams in 2418 specifically, but working group chairs generally do in practice. In particular, we ask design teams to write down who was in them and what their contributions were, specifically because of IPR and other reasons, you know, code of conduct and whatnot, which are concepts that kind of arrived to the IETF after 2418 was published, which is why it wasn't there in the first place. So I wrote up this paragraph that just says you might—like design teams must produce public records, um, to ensure that contributions follow the rules. And then there's an example about IPR. Does anyone have thoughts or comments on that one? 

Go ahead, Joel. 

**Joel Halpern:** Well, um, I find myself torn by this. In principle, I like it, but then I look at the practice. I don’t know and have not known who were on the design teams behind certain documents. I know who they chose to list as authors. I am fairly confident in some cases that that is not all the people who were involved in the design team that led to the document. As long as we get the rights, I don't care. So I'm a little nervous this doesn’t comport with reality, even though I like the idea. 

**David Schinazi:** Okay. Um, that’s—that’s fair. That might be a—a change. Um, what do other folks think? Colin? 

**Colin Perkins:** Hi, uh, Colin Perkins. Um, I was going to say roughly the same thing. Uh, I think this is probably how things ought to work. I’m not convinced this is how things do work in practice. But I would agree it’s how they should work. 

**David Schinazi:** So I guess question for the chairs in terms of our charter or or for our responsible AD: does this fit within our mandate or is this outside of it? 

**Roman Danyliw:** Uh, yeah, I just hopped in queue to ask kind of that same question. So, this does seem to provide more guidance than is just an editorial merge. So the question I wanted to kind of hear is: what is the basis we think we're threading—threading some of that normative language in? Is it that something came out after 2418 which made it mandatory for everyone and it's a flow down then on kind of all participants? Or is this kind of aspirational? In my kind of quick look, it more looks more aspirational, but you've done the deeper archaeological survey. So we may have to defer this depending on kind of your analysis. 

**David Schinazi:** I—so I am not a lawyer, um, but I have read BCP 79, uh, and it kind of defines what a contribution to the IETF is. Uh, and the design teams being defined in an IETF document are an IETF venue, and therefore any contribution made in a design team is covered by the IETF IPR policy. I think that’s fairly clear. Uh, the therefore, um, it would be a pretty big oversight if we had no way to enforce that policy, and the way we generally enforce it is by requiring people to name themselves when they make contributions. So I think it—it doesn’t take too much squinting to think that that change happened in 79, um, which we might think. 

**Roman Danyliw:** Yeah, I’m going to check some of the references there. I understand the logic, thank you for explaining. 

**Brian Carpenter:** Uh, yeah, Brian. Um, I was just looking at 2418 and it says explicitly: "It is acceptable to have closed membership and private meetings" referring to design teams. So I think it's a bit of a stretch to say that you require them to publish everything. You know, I'm not against what you proposed, but on the point of view of whether it's a change, I'm afraid yes, it is a change. 

**David Schinazi:** Okay. Fair. 

**Mirja Kühlewind:** Yeah, Mirja. I agree that like the way you put it is a change and it probably goes beyond what you actually want to achieve. I think what we want is, or what we need is, that we have a public record of the standards process, so we can actually later on figure out like who contributed at what point of time. And I think the way we're doing this is that the design team as a team at some point reports back into the standards process. So like they give a presentation at an official session and that's how you produce a record. And I think that's very useful and that's really needed, and I think it's already covered by other documents. Like what you wrote here is more kind of saying you need to every time you talk and you have a call or whatever, you also need to produce minutes or whatever. I think this is how you could interpret it. And that's really beyond that. 

**David Schinazi:** Yeah, so I think like yeah, like in terms of the output of the design team, I think we're all in agreement that that is a single contribution made to the working group at the end, roughly. Um, unless the working group says go back to the design team. But I'm not saying they need public minutes. I'm— those contributions are already public at the end. The question is who is behind these contributions is kind of the new change. Does that need to be documented? 

**Mirja Kühlewind:** So it's—it's really just documenting who was member of the design team. 

**David Schinazi:** That’s right. 

**Mirja Kühlewind:** Yeah. And okay... I mean actually I think from a general perspective that's very useful because kind of that's the kind of record we need, right? Um, and yes, I also remember that there was something in 2418 that says you can have closed design teams, but I think that was intended to say you have a closed membership, not like keeping it secret, so I don't think that is a— like yeah. 

**David Schinazi:** But that's right. The fact that they can be closed doesn’t mean it needs to be secret, absolutely. 

**Mirja Kühlewind:** Exactly. So like you need to—what you need is a list of members and you need a final outcome that you feed into the working group. That's the two things you need. 

**Pete Resnick:** I got lost somewhere and maybe David can help me. I—I think most of this is covered elsewhere. BCP 79 defines what a contribution is, so repeating it in the context of design teams doesn't matter. Producing public records of their contributions is already said in this—in 2418. So the only question now is secret memberships. Is that actually formally forbidden in anything or is this brand new? We want a new requirement? In which case, I think that is out of charter. 

**David Schinazi:** I—all right, I'll try one last time to—to see if I can get it across because it could be that I'm completely confused as well. Um, is that let's say the chairs have selected us as a design team and picked me as the chair of the design team, and I come back and I present to the working group our output. Um, the question could become like how—has—have we laundered that contribution in that someone could say it wasn't mine, it was David's contribution. Um, I could imagine a way we paint ourselves out of this corner is to just kind of remove the first bit and just say "Contributions made within design teams are IETF contributions and need to follow the rules" and we leave it at that. Um, that way it’s kind of clear and if anyone kind of—maybe that’s enough. Um, and it sounds like the making the records of membership is outside of charter, so maybe we just kind of put that in the trash then, um, and that we call that good enough. 

**Leslie Daigle:** Yeah, um, Leslie Daigle's in queue. I think— I—I put myself in queue to respond to the question from some moments ago of what do the chairs think of this as—is this beyond the scope? And I think the text on the screen is beyond the scope of the work of this working group. Um, I think others have—have sort of pulled the problem apart nicely, pointing out that the two—the two key issues are IETF IPR and also um delivery into the working group process of any results. Um, so I think—I think you—you are on the track to find something that might be an appropriate clarification in 2418 and I think it's potentially worth flagging, you know, issues to work on elsewhere or elsewhere, um, whether or not there's more clarity needed around design teams and—and you know, how to manage them effectively in—in the context of the process. Um, anyway, that's where I think we are. 

**David Schinazi:** Great. Thanks. And I—I think we're landing on a reasonable answer where we remove that requirement. That sounds fine by me. All right. I’ll write a PR. Ekr? 

**Eric Rescorla:** Yeah, I concur with that, I think, because I think it is outside the scope. I do think that it would be good for the chairs to be required to formally designate design teams, sorry, if they are creating them. Um, like I think prob—I think this text like kind of like the text you have—not the text that—you know, um, uh—the text that exists now or the text you have, like actually is kind of weak because like there really is a thing where the chair say, you know, Alice, Bob and Charlie are going to go off and do something and come back and we're going to listen to them when they come back and versus you versus Alice, Bob and Charlie go off on their own and come back and have their idea. Like those really are different things, and I think that like the second has some formal status even though like you—even though it’s subject to working group consensus, like you know, I think everyone knows that, and that's why like you know if that happens people kind of like defer to those design teams quite a bit. Um, so I do think—I do think it’d be better in some future world to require those to be actually identified and named as you suggest, but I think there’s not an IPR issue other than the usual IPR issues here. So I think that for the purpose of this we should leave it as—as it is. 

**David Schinazi:** All right. Thanks, Jay. 

**Jay Daley:** Thanks. Um, Jay Daley, IETF Executive Director. Um, back in 2023, there was a joint IAB IESG retreat under um the then chair, some guy Lars Eggert you may have come across. Um, and I was tasked with uh getting legal advice on a whole series of questions related to design teams. Um, and I have I have that legal advice in front of me. I'm not going to share it because I don't necessarily want to disclose it all, um, but one element I will point out is that um when you read the um documents, design teams are described as subgroups of a working group. Um, and that then could lead people to believe that they are therefore clearly part of the process and therefore that all policies apply, not just um the IPR policies. But um I think given the sensitivity of this, it's probably best if I share this advice with Roman and let him decide what he wants to do with it potentially with the chair chairs as well and let them carry that. Okay? 

**David Schinazi:** Thanks, that sounds great, and I think I was at that retreat but I don't remember. Lars says the same: we don't remember what was said though. So yes please. Colin? 

**Colin Perkins:** Hi, uh, Colin Perkins. So, um, just on Ekr's previous point, I would probably agree that design teams ought to be appointed by the chairs. That's not what 2418 says though. Um, so if we are making that requirement, that would be a change. Um, with regards to the text on the slide, um, I think the clarification here should be that the outputs of the design team are contributions which must have a public record and not the discussion. And I think that's what caused some of the confusion. 

**David Schinazi:** Yep. No, and I'm realizing that my first sentence I didn't do a great job on that, so apologies for the confusion. Barry? 

**Barry Leiba:** This is Barry Leiba. So you touched on this uh in your response uh to Pete I think earlier, so this is going to be short. I think this whole paragraph can be replaced by something that says um that work within the design team is considered an IETF contribution and the output of the design team is subject to the consensus of the working group. I mean those are the really the two points that we really need to make. 

**David Schinazi:** Thanks. Yeah, I—I agree with that. I think that’s—that’s the simplest way out of this. All right, next slide, please. 

All right, so congratulations everyone on the publication of RFC 9945. Modpod is a reality, that's amazing. Um, and now in 2418bis, since that document discusses disruptive behavior, we can remove that text and point to um 9945 instead. Um, that’s what this sentence does. Um, hurray. Next slide, please. 

Oh, this is the fun one. So, um, there's a bunch of open issues um around the topic of what like the—the working group chair. 2418 defines the authority of a working group chair, um, and then explains that some sub-portions of that authority can be delegated to others. Um, and then there's a whole set of roles for this. Um, working group facilitator, um, the—so moderator is not in 2418, that's in 9945. The um administrator also 9945, um, refers to the administrator of the mailing list. Um, technical advisors are mentioned, um, that's actually not delegated by the chair, it's by the area director. Um, there's mention of consultants and secretaries. Um, some of these roles are used extensively, some of them we haven't found a record of them being used in the last quarter century. Um, but the discussion we had in Montreal was that we wouldn't remove them because that would be a change that's outside the charter. Um, but kind of after going back and forth on a bunch of these issues, um, I tried to write a PR that uh solves all of them, um, and then I have three or four slides to go over it and you can all tell me why I got it wrong. Um, but here's the concept of what I tried to accomplish. Um, I took multiple of these subsections that define these roles and kind of smooshed them into one that I called "Working Group Chair Delegation". Um, and a bunch of the text is moved. Um, it also mentions new fora, um, such as GitHub and other elements um that like 9945 mentions these and explicitly says that those are managed by the chairs or can be managed by administrators or the moderator team, so we kind of bring that concept in as well, and also reference BCP 245 which is RFC 9945. All right. I've split the PR into multiple slides so it's not an eye—not as much of an eye chart. Bear with me um as I get through it and then um ideally we go for comments after I've gone through it. Or or no, actually do comments as they come up uh on— 

**Leslie Daigle:** Next slide. I think—I think we should do the whole thing because I know I've got questions that you may be about to answer. 

**David Schinazi:** Okay then let's do the whole thing. Sounds good. All right. In these, um, text in yellow is text that was um changed, text in green is text that was added, and text is red—is text that was removed. Um, so the first bit here in yellow is mentions that instead of saying mailing lists everywhere, it says public fora and it defines what that means, which is the list, chat groups, GitHub, GitLab, etc. Um, and then separately it adds um a reference to 245 saying the way you handle disruptive behavior on these online fora is documented over there, go read that. Next slide. 

All right. So this is now this new section, um, I changed the name of the subsection to mention "Chair Delegation". Um, and this text used to be in the Working Group Secretary subsection, so what I did is I moved it here and I added the sentence in the middle to say "this role is named working group secretary". So this is not any kind of normative text, it's just moving text around to make it easier to digest. Um, next slide, please. 

All right. Third part, um, this one is about um the uh role of the facilitator. Similarly, instead of being in the subsection title, it is now as a sentence in the middle of the paragraph, um, and also a reference for BCP 245 because that's where that is actually formally defined. Next slide, please. 

And then similarly, the working group consultant subsection, um, someone mentioned that we have technical advisors in our process supported by the datatracker. Um, it's not mentioned in 2418, uh, but it mentions a consultant and they're defined to be the exact same thing, so I just added a "hey by the way, we call this technical advisor sometimes" um since those roles are the same thing, to make it easier. Um, next slide, please. I think that was all of it... okay, yeah, and this is my summary slide for—you can go forward one, uh, because that's the overall summary for this. All right. Thoughts, comments? Deirdre. 

**Deirdre Connolly:** Deirdre Connolly. Uh, on the public fora, uh chats, etc., there are lots of chats that cannot have like a URL to a conversation that has happened somewhere sometime. That includes uh the official IETF Slack, that includes Zulip. Like maybe the URL exists for a certain period of time but I wouldn't be surprised if it went away. I might suggest cleaning up the specific language there because there's a difference between mailing lists hosted by the IETF, GitHub, and other places that feel public that are harder to be like "Yeah, we talked about it over here. Oh wait, uh, that—that got cleaned up by the tool and so..." We might need to clean that up a little bit. 

**David Schinazi:** So in terms of cleaning that up, I think all I'm doing here is kind of reusing text from 9945 which—that's kind of the normative reference for the chair—part of the chair's job is to moderate the GitHub, for example. Um, I think you're raising a good point which is that it might be hard for a chair to moderate something with disappearing messages, but I think that might be out of scope for what we're doing here because conceptually this is just pointers to already decided things. 

**Deirdre Connolly:** Yes, but uh for some of the consensus calls that we've just had, which not everything in every working group does a consensus call or whatever, but like being able to refer back with like a URL reference to such and such a thing that is like part of the debate and discussion of the working group was very, very important, and like the for us it was either if it did not go to the mailing list, which has a IETF operated mailing list and URL indexable reference to basically every message, uh, if not why not? Because having a URL to that discussion about the debate of the working group was very— was very important. Um, so not so much the moderation of the behavior, but like "Oh, why are you having an official working group conversation over there in a place where we don't have a record of it?" That's the vibe I'm trying to convey. So yes this is stuff that's already been decided somewhere else and we're just shuffling around the language but I'm new here, um, so I'm just noticing this for the first time. 

**David Schinazi:** Right, you're new, you've only been here for five years, it seems! Welcome to this working group! Um, I—so I think I agree with everything you said. I'm not sure it would lead to a change in this PR necessarily. Okay. No, but if you find some text that you think we should change if you can either send me a PR or an issue, I'm happy to— to look into it. It's just that I'm not sure like it might be a normative change that's outside of scope of this document because our—like our charter very much constrains what we're allowed to do. Cool. 

**Leslie Daigle:** Leslie Daigle in queue. I think I put myself in queue to respond to the question from some moments ago of what do the chairs think of this as—is this beyond the scope? And I think the text on the screen is beyond the scope of the work of this working group. Um, I think others have—have sort of pulled the problem apart nicely, pointing out that the two—the two key issues are IETF IPR and also um delivery into the working group process of any results. Um, so I think—I think you—you are on the track to find something that might be an appropriate clarification in 2418 and I think it's potentially worth flagging, you know, issues to work on elsewhere or elsewhere, um, whether or not there's more clarity needed around design teams and—and you know, how to manage them effectively in—in the context of the process. Um, anyway, that's where I think we are. 

**David Schinazi:** All right. Thanks, Jay. 

**Jay Daley:** Thanks. Um, Jay Daley, IETF Executive Director. Um, back in 2023, there was a joint IAB IESG retreat under um the then chair, some guy Lars Eggert you may have come across. Um, and I was tasked with uh getting legal advice on a whole series of questions related to design teams. Um, and I have I have that legal advice in front of me. I'm not going to share it because I don't necessarily want to disclose it all, um, but one element I will point out is that um when you read the um documents, design teams are described as subgroups of a working group. Um, and that then could lead people to believe that they are therefore clearly part of the process and therefore that all policies apply, not just um the IPR policies. But um I think given the sensitivity of this, it's probably best if I share this advice with Roman and let him decide what he wants to do with it potentially with the chair chairs as well and let them carry that. Okay? 

**David Schinazi:** Thanks, that sounds great, and I think I was at that retreat but I don't remember. Lars says the same: we don't remember what was said though. So yes please. Colin? 

**Colin Perkins:** Hi, uh, Colin Perkins. So, um, just on Ekr's previous point, I would probably agree that design teams ought to be appointed by the chairs. That's not what 2418 says though. Um, so if we are making that requirement, that would be a change. Um, with regards to the text on the slide, um, I think the clarification here should be that the outputs of the design team are contributions which must have a public record and not the discussion. And I think that's what caused some of the confusion. 

**David Schinazi:** Yep. No, and I'm realizing that my first sentence I didn't do a great job on that, so apologies for the confusion. Barry? 

**Barry Leiba:** This is Barry Leiba. So you touched on this uh in your response uh to Pete I think earlier, so this is going to be short. I think this whole paragraph can be replaced by something that says um that work within the design team is considered an IETF contribution and the output of the design team is subject to the consensus of the working group. I mean those are the really the two points that we really need to make. 

**David Schinazi:** Thanks. Yeah, I—I agree with that. I think that’s—that’s the simplest way out of this. All right, next slide, please. 

All right, so congratulations everyone on the publication of RFC 9945. Modpod is a reality, that's amazing. Um, and now in 2418bis, since that document discusses disruptive behavior, we can remove that text and point to um 9945 instead. Um, that’s what this sentence does. Um, hurray. Next slide, please. 

Oh, this is the fun one. So, um, there's a bunch of open issues um around the topic of what like the—the working group chair. 2418 defines the authority of a working group chair, um, and then explains that some sub-portions of that authority can be delegated to others. Um, and then there's a whole set of roles for this. Um, working group facilitator, um, the—so moderator is not in 2418, that's in 9945. The um administrator also 9945, um, refers to the administrator of the mailing list. Um, technical advisors are mentioned, um, that's actually not delegated by the chair, it's by the area director. Um, there's mention of consultants and secretaries. Um, some of these roles are used extensively, some of them we haven't found a record of them being used in the last quarter century. Um, but the discussion we had in Montreal was that we wouldn't remove them because that would be a change that's outside the charter. Um, but kind of after going back and forth on a bunch of these issues, um, I tried to write a PR that uh solves all of them, um, and then I have three or four slides to go over it and you can all tell me why I got it wrong. Um, but here's the concept of what I tried to accomplish. Um, I took multiple of these subsections that define these roles and kind of smooshed them into one that I called "Working Group Chair Delegation". Um, and a bunch of the text is moved. Um, it also mentions new fora, um, such as GitHub and other elements um that like 9945 mentions these and explicitly says that those are managed by the chairs or can be managed by administrators or the moderator team, so we kind of bring that concept in as well, and also reference BCP 245 which is RFC 9945. All right. I've split the PR into multiple slides so it's not an eye—not as much of an eye chart. Bear with me um as I get through it and then um ideally we go for comments after I've gone through it. Or or no, actually do comments as they come up uh on— 

**Leslie Daigle:** Next slide. I think—I think we should do the whole thing because I know I've got questions that you may be about to answer. 

**David Schinazi:** Okay then let's do the whole thing. Sounds good. All right. In these, um, text in yellow is text that was um changed, text in green is text that was added, and text is red—is text that was removed. Um, so the first bit here in yellow is mentions that instead of saying mailing lists everywhere, it says public fora and it defines what that means, which is the list, chat groups, GitHub, GitLab, etc. Um, and then separately it adds um a reference to 245 saying the way you handle disruptive behavior on these online fora is documented over there, go read that. Next slide. 

All right. So this is now this new section, um, I changed the name of the subsection to mention "Chair Delegation". Um, and this text used to be in the Working Group Secretary subsection, so what I did is I moved it here and I added the sentence in the middle to say "this role is named working group secretary". So this is not any kind of normative text, it's just moving text around to make it easier to digest. Um, next slide, please. 

All right. Third part, um, this one is about um the uh role of the facilitator. Similarly, instead of being in the subsection title, it is now as a sentence in the middle of the paragraph, um, and also a reference for BCP 245 because that's where that is actually formally defined. Next slide, please. 

And then similarly, the working group consultant subsection, um, someone mentioned that we have technical advisors in our process supported by the datatracker. Um, it's not mentioned in 2418, uh, but it mentions a consultant and they're defined to be the exact same thing, so I just added a "hey by the way, we call this technical advisor sometimes" um since those roles are the same thing, to make it easier. Um, next slide, please. I think that was all of it... okay, yeah, and this is my summary slide for—you can go forward one, uh, because that's the overall summary for this. All right. Thoughts, comments? Deirdre. 

**Deirdre Connolly:** Deirdre Connolly. Uh, on the public fora, uh chats, etc., there are lots of chats that cannot have like a URL to a conversation that has happened somewhere sometime. That includes uh the official IETF Slack, that includes Zulip. Like maybe the URL exists for a certain period of time but I wouldn't be surprised if it went away. I might suggest cleaning up the specific language there because there's a difference between mailing lists hosted by the IETF, GitHub, and other places that feel public that are harder to be like "Yeah, we talked about it over here. Oh wait, uh, that—that got cleaned up by the tool and so..." We might need to clean that up a little bit. 

**David Schinazi:** So in terms of cleaning that up, I think all I'm doing here is kind of reusing text from 9945 which—that's kind of the normative reference for the chair—part of the chair's job is to moderate the GitHub, for example. Um, I think you're raising a good point which is that it might be hard for a chair to moderate something with disappearing messages, but I think that might be out of scope for what we're doing here because conceptually this is just pointers to already decided things. 

**Deirdre Connolly:** Yes, but uh for some of the consensus calls that we've just had, which not everything in every working group does a consensus call or whatever, but like being able to refer back with like a URL reference to such and such a thing that is like part of the debate and discussion of the working group was very, very important, and like the for us it was either if it did not go to the mailing list, which has a IETF operated mailing list and URL indexable reference to basically every message, uh, if not why not? Because having a URL to that discussion about the debate of the working group was very— was very important. Um, so not so much the moderation of the behavior, but like "Oh, why are you having an official working group conversation over there in a place where we don't have a record of it?" That's the vibe I'm trying to convey. So yes this is stuff that's already been decided somewhere else and we're just shuffling around the language but I'm new here, um, so I'm just noticing this for the first time. 

**David Schinazi:** Right, you're new, you've only been here for five years, it seems! Welcome to this working group! Um, I—so I think I agree with everything you said. I'm not sure it would lead to a change in this PR necessarily. Okay. No, but if you find some text that you think we should change if you can either send me a PR or an issue, I'm happy to— to look into it. It's just that I'm not sure like it might be a normative change that's outside of scope of this document because our—like our charter very much constrains what we're allowed to do. Cool. 

All right. Leslie. 

**Leslie Daigle:** Yeah, um, so a couple of things, I think my first comment may have been partly, may overlap somewhat with what Deirdre was saying, but I was distracted by the volume issue. Um, I don't think your text for the other fora stands as written because it's too—way too vague. Like, am I supposed to go off and find all the Facebook groups that happen to be talking about uh the Mops working group and make sure they're all talking nicely? There—there needs to be some way to scope it to blessed IETF fora. And I appreciate the desire to not just call it mailing list everywhere, but—but some scoping is necessary, I think. 

**David Schinazi:** But if we called it like IETF public fora and then as an example we mention mailing list and GitHub, would that be okay? 

**Leslie Daigle:** I think that's fine, but I think it's as I said it has to be blessed in some way, or even the—the fora as listed on the working group page for instance, right? Like we list the get—the GitHubs now. So. 

**David Schinazi:** All right, that makes a lot of sense. I—I want to make sure like we don't—we're not too prescriptive because like you know the working group page is a concept that's not in any of our documents. But I think that makes a lot of sense to scope it down. Yeah. I'll look at what 9945 said about it. 

**Leslie Daigle:** Then the other comment was on the um technical advisors for the working group. I think it would be cleaner just to say that area directors may also appoint named named roles um and and just leave it at that. The only thing that's important to note there is that they don't have any special role with regards to the working group process. And I'm saying it that way because I think technical advisors are—my other working group has one, um, I think that partly it's a means for the area director to get—to give them some status, for instance ability to uh approve approve uh content to the meeting working groups, but um but they aren't they aren't otherwise blessed as part of the process. And. 

**David Schinazi:** All right, yeah, no I—I think I agree with everything you said, but I might request an issue or PR just to make sure I get the— your change right, um, because part of the reason I added technical advisor as an example in there is that if someone is command F searching for it in the RFC they'll be able to find it, uh, and I felt like that wasn't being more prescriptive just to use as an example if anyone says "Well I'm the technical advisor, what does that mean?" you can search for it was kind of what I was going for. 

**Leslie Daigle:** Yeah. And— and it took some mailing list discussion to get us to remember that that was not in fact a working group chair devolved role. So I—I think it's fine to mention them, we just need to be a little bit careful. 

**Leslie Daigle:** Barry, we've got a request from remotes that if we could speak closer to the mic, which I'm clearly not doing, uh, apparently in-room voices are a little faint remotely. 

**Barry Leiba:** Okay, then we will blast out the room. Leslie, can you move back to part one slide? Uh, this is Barry Leiba. I— I think Leslie covered most of what I wanted to say about this. The uh general comment that I have to make uh related to that is that we want to keep to concepts and not be too specific about um implementation. So examples are fine, but trying to be too specific will lock us in unnecessarily. Uh, nit: please avoid constructs like such as etc. You don't need both. But um and I agree with what Deirdre said about um the ephemerality of some of these, so we might want to be careful about our um examples. Uh, next slide. The yes. Uh, editing working group documents is not a working group secretary thing. So that should be maybe managing working group documents is what you want, being able to change the datatracker stuff about that. Uh, but you're not talking about being the editor of a working group document, that's not a secretary role. 

**David Schinazi:** I agree with you, but that's what 2418 says. This like if you look at this text, 2418 has you delete "Chair Delegation", you put in "WG Secretary", and then you delete that yellow line at the bottom. That's what's in 2418 right now. 

**Barry Leiba:** Okay, then it's wrong relative to what we do now. The the editors of a particular working group document are assigned by the chairs and they are not any of these named roles. So. 

**David Schinazi:** I and the subsection right before this one or either right after is the one about working document editors. Uh, but I agree with you that it is weird then that editing working group documents is part of the working group secretary role. Uh, but I agree with you. Maybe if we replaced the word "editing" with "process managing" or some better word that would solve that. 

**Barry Leiba:** Yes. I— I think it probably means managing the working group documents as in uh dealing with the datatracker stuff. Uh, so we might want just— it may just be a tweak in the wording of this to make that clear. But um that's what stood out to me. 

**David Schinazi:** Yeah, I— I agree with you. Maybe if we replaced the word "editing" with "process managing" or some better word that would solve that. Yes. Thank you. Thanks. 

**Colin Perkins:** Hi, uh, Colin Perkins. Can you hear me? Maybe a little louder? And closer? A little bit closer. Just looking in here. Um, so I guess two things: on the um public fora, um I I don't know if we put requirements on those fora anywhere, but we maybe should be having requirements for archivability um and public, you know, record-keeping and so on for the types of fora a working group can officially use. And that was certainly the case with mailing lists, and I know it's the case with the the IETF provided chat and with the GitHub which are archived by the secretariat. But if we're expanding that out to other fora we maybe need to put a requirement that the group makes sure that records are kept. Um, the other thing I wanted to bring up: um I think the certainly the role of working group secretary as defined here is narrower than I have seen it used in some groups. And in some groups I've seen the secretary do things which are called the facilitator in the other slide. And maybe that's okay because it's you know that's just a you know the same person could be called two different things, but it's not quite representing what how it's been run in practice. Yeah I've seen um secretaries doing agenda management, for example. Yeah. 

**David Schinazi:** Clear. So on the on the first point, I think having limits on what public fora we can use makes sense, but I think it might be out of scope for our current charter. 

**Yari Arkko:** Yes, that's— that is definitely out of scope and I'm trust that the IETF when they pick a particular tool or fora they will think about this and do the right thing and um so we are only here to specify what the working group process is and the chairs are responsible for using the tools, the fora um blessed by the IETF and um IETF will will figure out which ones are those. 

**Colin Perkins:** Yeah so so so we need to make sure this document says these are blessed fora and not just any fora. 

**David Schinazi:** Yeah, so actually Roman put the text from 9945 in the chat. Uh, like working group selected online public fora or something like that, and so I think that's the extent to what is in scope for this PR conceptually. 

**Colin Perkins:** Yeah, if it just says select any fora it has to select one which is blessed by the. 

**David Schinazi:** Yes, no absolutely, and that's I will tweak that language to make sure that we reflect fora that are selected by the working group chairs um as official fora. Um, all right. Mirja. 

**Mirja Kühlewind:** Mirja Kühlewind. So again I understand the desire to document the things we're actually using and like define these terms somewhere because that's helpful. Um, but I think this document should really kind of focus on what is actually part of the process, um, because if you put it in the document, you know, it's written in stone and it's hard to change and it doesn't age very well. So whatever you put here you will have the same problem in like five to ten years. Um, and I think this is something we didn't get right all the time in the past. Um, so in this case I— I actually would like to see a lot of this text simply removed because it's really kind of inside baseball. Like what we need to say is I think this is in line with Leslie is that you can delegate and how you name that role, you know, that's basically usually somebody in who implements the datatracker who decides about the name or something like that or it comes up spontaneously. And like I think this is also the place where I think we need to document it, like if you see something in a datatracker and it doesn't have any explanation, I think that's a problem we have, but the RFC should really concentrate on the process and not more. 

**David Schinazi:** So, I agree with you from a conceptual standpoint, I say if we if we weren't um coerced by the charter, um, that's I think what would be the optimal outcome. But between the charter and the fact like— because we had a whole discussion in Montreal about: should we remove the working group facilitator role because we're not aware of anyone using it? And kind of the result of that conversation was that we don't—like it's not an an like editorial change and we should just leave it in. And then we realized on top of that that 9945 references the facilitator as a example of something. So if we remove it then we'll make that more confusing. Uh, so I totally agree with you. I can try to make this a bit more vague, but I think having the names in there we're kind of stuck with them to some extent. 

**Mirja Kühlewind:** I'm not sure if we're— um I mean maybe it's for the chairs to decide, but I— I'm not sure this is what the charter gives us because it's kind of still updating versus reality and if we think reality is that this is actually only internal process and doesn't need to be documented in an RFC, that's what we should do. 

**David Schinazi:** Okay. That's fair. Thanks. 

All right. Next slide, please. Actually let's get past the part four and then the summary and onto the next one. Uh, there we go, thanks. Virtual bofs. Um, so we talked a little bit about this in Montreal. Um, 2418 has text about bofs and has some pretty strict rules there as that you should have one bof and you might be allowed to have two, but three is right out. Um, and it explicitly says one slot at one IETF plenary meeting. Um, since then we've had virtual bofs, um, outside of plenary meetings, um, and so this kind of falls into our reflecting reality umbrella. Um, how do we want to fix that? Because right now what we're doing in practice goes against 2418. Um, another aspect um about this is that the limit of two is kind of useless anyway. Uh, I've seen the area director get a third bof, all they did was rename the working group, which then it became the first bof. Uh, so in practice this doesn't matter too much. My proposal is to just delete that parenthetical that says "one slot at one IETF plenary meeting" as the simplest way to resolve this. Lars. 

**Lars Eggert:** So I have two opinions, I agree and I disagree with you at the same time. So, uh, uh, I think it's useful for ADs to have flexibility here, um, and in practice, you know, they've been creative and that that's been great. Um, it's also very, very useful for ADs to have a piece of text in an RFC to point to to say "Sorry you can't have one" because if it's purely up to the AD, they will be flooded with "please, please, please, one more time, this time it'll be different" requests. And and while they can still decide to say no, it's going to make it a little bit more annoying. So I don't quite know how to thread this needle but um the leaving like having some text that says one or at most two is actually helpful. 

**David Schinazi:** I'm not suggesting we remove that text, that's the text in white that's not changing. 

**Lars Eggert:** Ah, okay, sorry then I misunderstood. 

**David Schinazi:** I'm just removing that it says that they have to be held at plenary meetings. 

**Lars Eggert:** Oh, okay. Yeah yeah, okay, sorry. 

**David Schinazi:** Cool, thanks. Uh, anyone else have opinions on this one? Roman? 

**Roman Danyliw:** Yes, so I just wanted to clarify the intent here. If we don't remove the text, what this is saying is you can hold an infinite number of virtual interims, but you only get up to two slots at the face-to-face meetings, right? Because to my knowledge, this has not been abused in the sense of I have no of no instance where you virtual boffed a lot of times but you didn't but you didn't but you didn't blow your cap of the two face-to-face. So I think what we're seeing here, you know, just to kind of finesse it a little bit, I think this is a hypothetical situation we're trying to mitigate. To my knowledge, this has not happened in the past. The idea of renaming bofs, more bofs, I'm setting that aside, you know, that's a different issue, but this finesse virtual kind of not. So I'm trying to understand: what are we trying to kind of really reconcile? You get two of any form or are we trying to kind of leave the virtual thing alone? 

**David Schinazi:** So, my thinking is that what we've been doing recently is in violation of 2418. Because 2418, based on that parenthetical to me reads as requiring bofs to happen at plenary meetings. Um, at the end of the day it doesn't matter that much because bofs are not a required part of our process, like the we have gates around working group chartering and approval of the charter by the IESG. The bofs is an optional step along the way. So it doesn't matter too much, but I think with the way we've been operating is in violation of this text, is kind of how I read it and what I'm trying to rectify. 

**Roman Danyliw:** So would we so so again in trying to understand what the end state is on deck: uh as I understand it we've actually only had less than a handful of virtual interims, and so what I'm hearing is we shouldn't have had those, those are not allowed by the RFC, and by making this text change you're saying we can now have them? 

**David Schinazi:** That's what I'm saying, yes. And then we are also making it clear that now those count towards your limit as well, uh, whereas before those were just not allowed. 

**Roman Danyliw:** Uh, so I guess I was asking that question wearing no no hat, like putting my hat on, if we are clarifying the existence or absence of virtual kind of interims as a thing, this now feels like it's up against the the charter scope. 

**David Schinazi:** We have a caveat in our charter about reflecting reality. Yeah right. Uh, I will also repeat what uh what Lars kind of said, which is this idea of having ADs having the ability to point to an RFC to say you don't get another one is very, very, very extremely helpful in all forms. I can't say that more strongly. 

**David Schinazi:** Yeah, and again, I'm not proposing to change that. Michael. 

**Leslie Daigle:** Just a programming note before we go further. I'm hoping to um have 30 minutes to go through Lars' document, so hopefully six minutes will be plenty of time to wrap up this discussion. Thanks. 

**David Schinazi:** Well, good news, this is my last slide. 

**Leslie Daigle:** I am aware. Michael, go ahead. 

**Michael Richardson:** So the situation that I would like clarity of on and I um have opinions about things, but I what you your red text is probably okay to deal things, is where we have had um call it uh side meetings, virtual side meetings in preparation for a bof um which would be at a plenary week and we have asked "Well we have issues with getting a proper record". This goes back to the previous conversation and what Deirdre brought up. "And could we please use MeetEcho because it's the best tool we have that everyone understands and gets us a good record um and is accessible actually through um from many places in China where quite a number of other things are not". And then the response was "Oh that will it's going to count as a your bof". So um I don't need to have more than one bof and the text there is not accurate about under unusual circumstances while we almost always get two, um so we could argue about that point, but um I think we are doing ourselves a disservice by not allowing people by forcing people to use unrecorded by IETF mechanisms to do their planning of the bof. That's all. I don't care how we solve that, whether we just say they are not bofs or we clarify something else, I don't care, but I think we're doing ourselves a disservice and not reflecting reality by doing that. And also accessibility to many people. 

**Eric Rescorla:** Well, I didn't know I was getting in line to disagree with MCR, but I guess I am. Um, and then I will say what I was going to say here. Um, like I think it's bad enough that we give people like rooms at IETF to have their side meetings and I certainly don't think we should provide video conference support for their side meetings. Um, that we need to draw a sharp distinction between things that are IETF activities and things that are not. Um, and things that are unofficial and do not have status are those things. Um, on this topic, um, it seems to me that um I see above that like Colin suggests that um he's not convinced virtual bofs are a good idea, I am also not convinced virtual bofs are a good idea, and um and I think that to the extent to which they're not allowed now, um rather than rather than um reflecting reality we should enforce this rule, not allow people to have them. So, I do not think we should make this change. Um, it seems to me we have a consensus document that says virtual bofs are illegal and we need consensus to change that and we shouldn't. 

**David Schinazi:** So, yeah, I mean so one of the interesting things about the way we operate is that the IESG is allowed to go against almost all of our rules if they call it an experiment, uh and I think that's how these virtual bofs have been run, um, and that's how we can kind of square that circle. Um, and so what you're saying is we shouldn't do that anymore. I That's one— 

**Eric Rescorla:** I don't think they could do it as an experiment. I'm not sure they can do it as an experiment with an RFC, can they? Like a consensus call? Which on pure discretion? I don't think so. 

**David Schinazi:** I it's how things have been operating for a while. Um, the fact for example to give you an example from 2418, uh working charters that have milestones without dates. Uh, that's something that goes that's a violation of 2418 that the IESG decided to have an experiment on that's been ongoing for 20 years, or maybe 15. Adam Roach started it, I forget when. 

**Eric Rescorla:** Um, well, in any case, um uh well I see Lars commenting here, um but I guess I just don't agree with you Lars. We can make exceptions when we need to, this is not a such a time. So um I I guess to the extent to which we're like actually asking for um for agreement with this, I disagree and I'm not down with that. 

**David Schinazi:** That's fair. I'm hoping that I don't have to open that can of worms and not the can of worms of side meetings, which is an evergreen topic at every IESG retreat that I've ever heard, but anyway. Sorry, Pete, go ahead. 

**Pete Resnick:** Yeah, um I get to disagree with both Ekr and uh Michael. Um, we should stay out of the side meetings issue um completely in this document, let's not, you know, it's a can of worms. Um, with regard to this, I think this is a match reality. Um, the idea of a virtual bof was nonexistent at the time this was written and we have virtual um working group interims, which were also nonexistent at the time of this document, um we probably need to say how they work. I think the important point here is a bof is a session where the IAB has gears that turn, where the IESG has gears that turn, um where people are expecting the formation the possible formation of a new working group whether as a result of that bof or down the line, um and we should include those because they do exist now as part of reality in the limit of they're held only once under unusual circumstances you get two, and even though reality is, um you can get more, um IESG members need to be very creative in order to pull that off, God bless. Um, I think Ekr's right though in the sense that the IESG being a little too creative over the years has been a repeated problem, they're not allowed to do some of these things. 

**Yari Arkko:** Yari Arkko, personal comment. I agree with Pete first of all and I think another way to describe this is that there's really two dimensions in the discussion here. One is the officialness um and and the other one is the the virtualness. So you we should totally ignore the things that are unofficial like side meetings. That's not matter for this this document, um and it is a reality alignment indeed that that things can happen either in person or in the virtual um domain and we should recognize that and otherwise this is not a change to the process in in my view at least. 

**Eric Rescorla:** Yes, so to clarify, my objection to the virtual bof is the following: that the plen— when the bof takes place at the plenary meeting, people look at the agenda and they say "This looks interesting, maybe it's important I'll show up" and and you and you get a broad cross-section of the community. In a virtual bof, what you get is the people reading the mailing list for the and therefore are proponents or strong opponents of the thing, and it's a completely different setting. And the purp— and the purpose of the bof is cross-area review and vetting and vetting of the of the proposal against the community as a whole. Um, and so it simply is not sufficient to say that virtual bof and in-person bof are the same thing. And so maybe it'd be a good idea to change that, um but um uh I agree with you Colin: like if the IETF were entirely virtual that'd be fine. Um, my obj— my objection is that it is not part of the plenary agenda, um and so um so I think that— that um so I think that in any case, I I see that we're gonna have to resolve this at some future point but I just wanted to get out why I'm objecting to this in the first place, I'm not just being grumpy. 

**David Schinazi:** Thanks, I think I guess this becomes a question for the chairs and our AD, which is do we think our role here in this room is to reflect reality in the document or to address this hot topic um and come to consensus on it one way or another? Um because just thinking through it, if we can't come to consensus, I don't know what we fall back to. Is it what the document says or what we've been doing? 

**Leslie Daigle:** Leslie Daigle speaking as chair. I think that um part of the challenge is that we're not even agreeing on what has has been practice, right? Uh, Roman in the chat is citing numbers suggesting there in fact haven't been a lot of virtual bofs. My suspicion is that there's a little bit of conflation between side meetings and virtual bofs even though we agreed that side meetings are something we shouldn't touch. So I think it might be appropriate to, you know, ask another question of the IESG in terms of what do they perceive the current reality to be and make sure that the text reflects that so that we can all live up to what we think the current reality is. But that's just a thought off the top of my head. Mirja. 

**Mirja Kühlewind:** So coming back to the point that really kind of focusing on what's actually mandatory process, this is all not useful because you don't need a bof at all. You can rename your bof or whatever. So this actually doesn't mean really that much in our process. Um, I understand the point and I think it's important point that Lars made that it's actually useful to have something to point to. So in that sense this is kind of like text that hopefully supports the work of the IESG, makes the life of the IESG a little bit easier. So I actually think it's a good idea to ask the IESG what they prefer. Um, in that sense, you know, keeping the text or removing the part in brackets both is fine for me. I'm slightly tending to actually removing this part in brackets because I think we are agreeing that like the plenary meeting and everything we do at the plenary meeting shouldn't have a special standing in our process and this is kind of conflicting with it. I understand that like the outcom— the output you get from a bof at a plenary meeting might be different from what you get at a virtual meeting. We understand this is all reality, but for our process, the decisions are made online and it shouldn't make a difference. 

**David Schinazi:** Thanks. Uh, so what do I go from here as an editor? 

**Roman Danyliw:** Yeah, I would say given that uh I at least quickly can't find any evidence beyond the one I held uh for GWP that this is something that reflects current practice if sample size equals one, uh so I think uh we can't invoke that in terms of the in terms of making that in charter. So we may have to defer this to another time to provide that clarity. And it may be an open question now whether it was even appropriate to have held that bof. 

**David Schinazi:** Yeah I don't think there were definitely no more than three and maybe it was just the one or two. I don't think any virtual bof turned into working groups. 

**Roman Danyliw:** Yeah I mean just kind of quickly I I feel like there was more than one but that's the only one I can quickly find. 

**David Schinazi:** I remember when we were researching um how to how to organize one, I was told that Francesca had pulled together the the justification for it and I think had held one. So we may be able to follow up from that. 

**Roman Danyliw:** Yeah I vaguely recollect this something around Tigress secret maybe? 

**David Schinazi:** Oh yeah, in transport area. Yeah. 

**Roman Danyliw:** Okay, but also given the time that it occurred, we could just say that that was a COVID era emergency. 

**Leslie Daigle:** I think this requires more research, more background research, and again we're talking to text on a slide as opposed to really grasping the whole issue. So I think we're— I think we've discussed this as much as is useful today. 

**David Schinazi:** Yep, that sounds good. I'll uh I can do a bit more research and present that as a proposal uh alongside a proposal which might be still this. Um, sounds good. 

**Leslie Daigle:** Yeah, no that would be great and and it sounds like Roman has some work to do to help you with that, Roman and Mike. All right. Colin, do you really, really needto jump in the queue or are we ready to move on?

**Colin Perkins:** He says no. So we can move on.

**Leslie Daigle:** Great. Thank you. All right, thanks David. Lars.

**Lars Eggert:** Right. Hello. So this is still a personal document which is for PROCON and we're also I don't think I need the time. Um, I know I'm going to eat those words in about 20 minutes, but I don't think I need the time. So so I wrote this draft when I was still chair or was getting out um because I sort of realized that there wasn't a lot of ability for the chair to actually delegate things, at least not officially, and I wanted to change that. Next slide.

Um, this is unchanged from last time. So the chair has many responsibilities. Um, you're not allowed to delegate, it can cause overload and for me it certainly has at times, and it sort of also limits your ability to sort of define the role. And and we can argue whether that's true. Um, so there's a little diagram down there and I think uh Ekr sent feedback that points out there's actually another arm that I'm missing, which is the special role of the chair in the appeals process, except I couldn't find a source for the diagram anymore so I didn't update it. Um, the other thing is that the IETF chair is a single point of failure. Um, there's no sort of defined way to have somebody else uh stand in if if the chair can't do the job. Um, the only option is a permanent replacement, um and there's this mid-term vacancy uh NomCom process. So there's basically these two motivations: one is, I think Yari in an email called it sort of a workload-caused uh desire to maybe uh delegate, and one is a sort of outside influences forced delegation because uh the chair is AWOL. Um, next slide.

The motivation was to sort of fix this. Um, I think the draft still looks at all the existing RFCs that have something to say about what the chair does and doesn't do, um and I sort of propose uh small tweaks that that gives sort of... the intent here is sort of maximum flexibility. Let the that the chair really um delegate all these different uh roles and sub-roles that are on the previous slide. And again I'm going to point forward in time to Ekr's uh comments: maybe we want to discuss if this maximum flexibility is actually something that is desirable or whether there's some packaging of of delegation or the ability to not delegate is something that we want. Um, but the draft at the moment still sort of allows the IETF chair to uh not also be the IESG chair, and it allows the IETF chair to not also be a member of the IAB, and it allows them to not also be the Gen-AD at the same time. Um, so that that is the sort of what I would call like workload overload uh fixes where you know a chair could say, um "I'm going to appoint this other person or other AD to be the uh IETF chair delegate on the IAB, for example."

Um, the other part was this what happens if the chair can't do the work for, you know, being hit by a bus or something else going on. Um, and that was the idea for this emergency stand-in. There's been a change at the moment. Uh, the the text says, and I stole this idea from Brian Carpenter, um that the chair basically picks another (in parentheses) willing area director as their stand-in immediately when the chair gets seated, um and at any time afterwards they can sort of change who that person is who that area director is. Um, and you know when something happens to the chair then that person is chair um either until the NomCom finishes the mid-term reappointment or the NomCom selected chair says "Hi, I'm back." Um and and uh, yeah, that's what the document says. Next.

Um, I got a bunch of feedback, so since the 00, Brian um sent some feedback. Uh, most the the most critical part here was this idea that was in 00 that um the IAB chair would be the stand-in. And Brian proposed to uh make it simpler because we had some discussions whether the IAB chair should really have a role in the standards process because the IAB doesn't. Um obviously the IAB chair is on the IESG, so there's you know an argument for and against, but I I personally liked the idea that you just name another AD uh better and since this is at this moment still my document I just stuck it in. And we can take it back out if the working group in the process of adoption finds that this is not what we want. And there were some editorial fixes because the document talked a lot about you know uh... it was written for being dispatched and now that it has been dispatched it it changes the wording a little bit. Next slide.

Um, Ekr sent a really useful review uh last week and I'm sorry that I haven't really replied to anybody on this. I was really busy, but I found it very helpful. Um, and and my attempt to sort of summarize this and Ekr's uh on the call so he can correct me and step in, um it was really this sort of separation of this emergency delegation from the workload-based delegation. I think maybe the draft should bring that out even more. Um, I think Ekr uh pointed out that he does not like the new text that says pick another AD, he liked the original IAB chair better, but there's also maybe another option we can discuss here in the group. Um, Ekr writes that the word "incapacitated" does a lot of heavy lifting, uh like who decides it and uh what does it mean? I agree, um I did not I didn't feel like writing a lot of text there um and and but yes we definitely definitely if we go this way uh need to basically say a little bit more about the conditions.

Um, as I mentioned, I sort of wrote this um with the intent of maximizing flexibility for the chair, um and Ekr says some of these functions shouldn't be delegatable and that is fair. Um, we should discuss which of those we do maybe want to give the ability for delegation to the chair and which of ones we don't. And I think a sub-clause of that Ekr raised is that the chair really can uh at least in practice delegate by simply like not showing up. Like you know if a chair felt the IAB was useless, um you know why do they dial into the calls and go to the retreat and stuff? And and you can make that argument, um but it's difficult for the chair to actually do so because you're making yourself very recallable at that moment. Because somebody can say "Hey, you know, he's supposed to be on the IAB uh but you never show up, so that's not being a really good IETF chair, is it?" Um, therefore I felt like having a uh explicit way for the chair to say, you know, "I am shaping the role this way and this role this sub-role on the IAB, for example, is being filled by this other person" would be cleaner.

And then um the special role the chair has in the appeals process and I think it was Yari who pointed out that um the text says this, but I don't think in practice we really the IESG that I'm not on anymore, so the IESG when I was on it at least did not necessarily handle appeals that way. Um, part of that was probably because the chair was already overloaded and so dealing with the few appeals that we had, by the way um, just to throw Roman under the bus a little bit, um the few appeals that we had at the time, I felt were already quite an additional workload and dealing with them as chair first rather than having the IESG as a whole jump on them uh was not the best way to deal with this. And I think that's my last slide and I have people in the queue, I'm sorry uh if you were going to comment on something earlier and I talked over you. Mirja.

**Mirja Kühlewind:** Mirja Kühlewind. I joined the queue early because I wanted to um make a point on the basically first or second slide. Um because yeah here you have you have these three different things here, which is the IESG chair, the Gen-AD and the IAB member. And these are not on the same level. So the IESG chair and the Gen-AD they um imply certain responsibilities like as AD you have to click the buttons and whatever and if you're not able to do it you have to find somebody to stand in for you to do that. But the IAB doesn't work this way. The IAB, the IETF chair is a member of the IAB and it's not like you are assigned a certain thing that somebody else needs to stand in for when you're falling off. And I think this is generally true for every IAB member: like if some of the IAB members becomes inactive for for for a reason it's not a problem we can compensate for that. And I think we should treat it the same thing: like the IETF chair is always the IAB member, you can't change that, uh and if it if you are not able to participate in the IAB, you know, not a big problem, it's sad but there's also the liaison so there's still some kind of um overlap in forth and back, so I think there's nothing you can do here.

**Lars Eggert:** Yes. That's true. I I do think it's a problem though if we have a bunch of RFCs that basically imply that the IETF chair is a full member on the IAB and then they're just not showing up.

**Mirja Kühlewind:** No I think it's not— it's not like... because the.

**Lars Eggert:** Well it's not— it might not be in practice but it if the role of the chair includes being a full member on the IAB and then the the a given chair is not fulfilling that role, you could you could argue whether that chair is actually fulfilling the role of the IETF chair as defined by current RFCs.

**Mirja Kühlewind:** I mean you always fulfill the role because you are a member you're just not doing a good job because you're not doing anything, right? But that also happens for other IAB members and we can cope with that.

**Lars Eggert:** Yes. I agree it is, right, but it would—

**Mirja Kühlewind:** And and I mean I mean like logically I think it's important to not exactly, I think should have it—

**Lars Eggert:** No, I think it's not— it's not like... because the.

**Mirja Kühlewind:** No I think also in the processes there's nothing like it can happen that somebody disappears kind of and we can handle the process around that. This is not special for the IETF chair compared to any other IAB member.

**Lars Eggert:** Okay. If if—

**Leslie Daigle:** I'll observe that there don't appear to be any text in any RFC that says that.

**Lars Eggert:** That basically—

**Leslie Daigle:** Lars, you may have not needed 30 minutes for this discussion but I was concerned the working group needed 30 minutes for this discussion or more. Okay. So I have at this point locked the queue because I think that we're going to run out of time. I don't mind other people joining at the end of the queue in case we do have time, uh but otherwise I think we need to move on through the queue.

**Mirja Kühlewind:** I had a second point on the next slide basically. I have an opinion here, but like my main point is I think this mechanism for emergency cases where you say I have to name and pick somebody and there's a process behind it, that's the wrong way to approach it. Like in emergency cases there should be one clear delegation without any action required at any point of time. And that's why I'm not happy that like you proposed that the chair needs to pick another AD.

**Lars Eggert:** No. The the picking of the other AD happens at the time the chair gets seated.

**Mirja Kühlewind:** I understand. I understand. It shouldn't be happen at the time where you fall away because that wouldn't work, but I think there shouldn't be any picking. Like there should always be a clear fallback path because if you forget to pick somebody or if nobody is willing or whatever, you know, then you have the same discussion again. And this is really just an emergency case. So let's make it easy and just like define it like this is the way it works and we're done.

**Lars Eggert:** Okay.

**Leslie Daigle:** Thank you. Ekr.

**Eric Rescorla:** Yeah I mean I so I think, you know, the underlying thrust of my comments was that the I is that the chair is picked by the NomCom, it is a singular role and there's an accountability structure where they're picked. Which does not apply and and so if you know if Roman decides to nominate, you know, you know the person who's just made, you know, some AD as as his, you know, vice chair, they were not picked by the NomCom for that role and and it and it would in as you see in the chat, that would really quite change the calculus of people who were chosen and it's not clear the accountability structures if they do a bad job. And so and you can say like "Well it's Roman's job to make sure they make sure they do you know a good job", but like why delegate the entire job of Gen-AD or IETF chair to this person? Like, you know, we Roman was picked because we wanted him to be IETF chair, not because we want him to hand it off. And and so I think basically like there are a number of things that like one can imagine doing here that like you know that I think do not really matter, like the like um you know um the RSAB and the LLC board and those things where you actually can just sort of be like "This person really reps the IESG rather than reps rather than reps the their chair specifically" and I think it'd be fine to like really hand those off, um and say like the IESG selects this person and and they can pick anyone they want. Um but I think that the notion that like um, you know, and I think, you know, when when Alissa was on leave I did actually kind of sit in the LLC for a while in her place. I'm not sure if that was even allowed but we just did it. Or not the LLC but I guess the I— you know I asked at that time. Um, um but like I'm not really comfortable basically very much delegation of the chair of like these really quite explicit roles for which which are chosen the chair was chosen for as opposed to the roles which are kind of incidental.

**Lars Eggert:** Right. So I I think I disagree on on the LLC board because I think that is actually the one role that I find very difficult to delegate, and that is already allowed, so which is why it isn't in the document other than saying that the IESG can already do that. Um, on the Gen-AD thing, um technically the IESG already has the ability to pick a Gen-AD because they can just empty out the Gen area, create Gen-2, uh tell the NomCom "Pick us an AD for Gen-2" uh and and uh the NomCom will have to do that. Uh and then the IETF chair is the Gen-AD with no with no working groups. I thought it would be cleaner to to make it clear that that we want to just give—

**Eric Rescorla:** Well I would note that would require the consent of the entire IESG, not the consent of the of the IETF chair.

**Lars Eggert:** Correct. But I—

**Eric Rescorla:** Well that's a very different situation.

**Lars Eggert:** So I doubt that the IESG would would disagree if the IETF chair says "I don't I don't want working groups in Gen."

**Eric Rescorla:** Well they should. Well they should. So um and if they're not doing the job then we should recall them. So and I don't think this is the same at all.

**Lars Eggert:** So if between these IAB, Gen and IESG chair roles are there any that you think are delegatable Ekr or do you think they're all inherent?

**Eric Rescorla:** The IAB one I think we should just I think I take Mirja's point, but I think we should just like say that say that like the I the I IETF chair can show up to the IAB or not as they please. I just don't think it matters very much, right? I basically like my view is it doesn't really matter whether they show up or not to the IAB. And and like frankly if they weren't ex-officio it would barely matter at all. Um so like I think we should just like say that that's like not a real responsibility and, you know, and and take the take the recall thing off the table. So yes, I think that's the one we should do. And again, I don't think it's a problem like, you know, if they do ask some other AD to pick up one of the working groups in Gen, but I think they're ultimately responsible for like the question of who do I go to to charter like my new working group that is like, you know, to rip out 2026 and replace it with like absolute dictatorship of, you know, um like, you know, it's the IETF chair. And I don't think that should be like a random person that that like the IETF chair delegated.

**Lars Eggert:** But it would be another AD and not a random person. But point taken.

**Eric Rescorla:** I hear you, but I think and I think it is really different to be like "They're responsible for the question of of whether working group's chartered" than the question of whether they're responsible for the working group once it has been chartered. I think those are quite different things. So I think that's the part that is inseparable. So, um, I guess I'd be happy to go through this in detail with you at some point if you want to have a call, but I think that like many of these I think I think the core thesis the core lens I'm looking at this through is what are the things that a NomCom thinks it's selecting this person to do and that and that they're accountable for. That's the lens I'm looking at this through.

**Lars Eggert:** Thanks. Yari.

**Mirja Kühlewind:** Mirja has a clarifying question for Eric.

**Mirja Kühlewind:** Yeah. So I mean a working group is chartered by the whole IESG, right? It's not the Gen-AD or what did you say?

**Eric Rescorla:** I I mean the Gen-AD is sponsoring it. If like if like... like it would be incredibly inappropriate for the security AD to sponsor a process document a document which was about which was about the management of the IETF. It'd be incredibly inappropriate.

**Mirja Kühlewind:** I disagree but anyway.

**Eric Rescorla:** Okay, well, um I'm not sure what to tell you.

**Mirja Kühlewind:** The whole point of areas is and why we haven't added a separate area—

**Eric Rescorla:** The whole point of area is having that having that separation.

**Yari Arkko:** And an individual... sorry did you want to continue?

**Yari Arkko:** Yeah, okay. So, um Yari Arkko speaking as individual for this topic, um maybe focusing a little bit more on what you guys agree than what you disagree about Lars and Ekr. I think obviously the everybody seems to be of the opinion that we do need an emergency stand-in capability and the differences are more in exactly who is that person, how that's selected and so on. Uh, I actually don't care personally super much what what the what the answer is. I have experience that both as IETF chair I would have known people in my team in the IESG that would be capable and maybe future candidates for uh IETF chairs themselves. Um I could have relied on them. I I would know that I can rely on the IAB chair and maybe for an emergency situation some number of weeks or a month or two would be okay. Um of course personal situations could be different for different people regardless of what we what we write in this future RFC. But um I I don't think that's totally impossible to decide. I think it would be quite okay. Ekr, you asked about the definition of incapacitation. I really don't think we should go into the definition of what constitutes incapacitation. I would rather that we focus on who decides that. And I guess Lars's document was on one extreme that "Okay, the delegate decides that now we have this situation." Uh the other option is that "Okay, we run through the recall process" and maybe there's a third alternative that the IESG decides that now we have this situation. Um I'm maybe more in the middle than than on the on the two extremes here. Um then on this workload-based delegation thing, obviously we need some more discussion but maybe it'd be useful to decide first what problem we are trying to address. Is this for a temporary situation that for three months we need to have somebody else do the Gen-AD job because of urgent stuff over there? Or is this for this person to be the IETF chair and for that they absolutely can't do the Gen-AD for the next four years? Or two years? We should decide that and then based on that we can figure out what solutions might be.

**Lars Eggert:** So my extreme view was to give the IETF chair maximal maximal flexibility. So I I wanted to let them be able to decide whether this would be a part like a fixed term or indefinite uh delegation of the role. Um the other thing I wanted to point out is at the moment these emergency and workload-based delegations are in one document simply because I felt like dealing with the boilerplate only once. Right? But the working group could decide to split this. But so so if we have consensus that we want to deal with the stand-in uh with the emergency one for example, right? I I have no problem having two short documents and one of them goes forward on a different timeline than the other one. Um that's a possibility as well.

**Leslie Daigle:** Um, so I apologize Colin, I don't think we're gonna have time to get to your contribution because we have three minutes left and my concern as chair is: where do we go from here? Um, I'm not sure that from the discussion today I feel like we've made progress on getting everybody lined up in the same direction of where we're going from here. Um, I'm looking at my co-chair and wondering if he agrees.

**Yari Arkko:** Yeah I think that's mostly true, but it's not maybe entirely true because we I think there's some agreement maybe potentially that we should split the two things from each other so that would be a helpful exercise and then then we know at least that we want to do the the emergency stand-in thing and then we have to figure out what the what the solution is. And then for the other thing, the workload, maybe maybe figuring out the list of problems that we want to address and then agree on that before fixing the solution.

**Leslie Daigle:** Yeah. I mean I think my chief criterion is um we don't want to be in Vienna sort of with the same "Here's a new proposal and here's a slightly different proposal and it doesn't address all these six different things that have already been discussed." I think the discussion today has been very useful, it's it's it's helped sort of shine light on some of the darker corners of of the overall issue space and I mean I sort of wonder if we shouldn't spend some time for some value of "we" being very crisp about which part of the problem we're trying to solve and getting working group agreement on that. And Lars I don't know how do you feel about how the discussion is going?

**Lars Eggert:** I think the discussion's fine. I mean this is not a super urgent document, right? And and so I can totally see the working group spending time elsewhere and that's fine, right? I don't need to finish this by Vienna or this year or ever frankly. Um I mean my motivation for this has slightly has slightly shifted.

**Leslie Daigle:** But the working group has a charter item that it has to address.

**Lars Eggert:** So, uh, you know, when the working group wants to like have a engaged discussion on this, I'm very happy to have it. But I can also see us prioritizing other things first.

**Leslie Daigle:** Well, I mean, obviously we have prioritized other things, but you know, hopefully we are near the end on on those things. Some things still to work on obviously as you've heard today but um you know we're gonna get there some at at some point. But rather than just put this whole thing aside is is maybe come up with a, you know, step one, what is the step one in in this um delegation topic? Um rather than figuring out the full answer.

**Lars Eggert:** Let me let me make a proposal and that is I'm going to split the document into an emergency one and into a workload-based one. For the emergency one, it seems like the only disagreement we really have is like who's the default and how do they get chosen, right? And it's not a small issue but I think that's the issue, the one issue we have there. And maybe we can put this to bed until Vienna. Um and the other one we will see what happens. That will take more discussion time, I think.

**Leslie Daigle:** All right. I'm gonna give him a minute to go for 30 seconds to Colin since he keeps working up behind me.

**Leslie Daigle:** All right, so uh Colin and Mirja and then and then I'm going to declare that uh we need to do some offline discussion about where from here and thank everybody for the thoughtful discussion that we've had. Uh, Colin.

**Colin Perkins:** Yeah, uh so thank you for that. I actually think there are three parts to this. There's the incapacity part, there's the um someone wishes to be IETF chair but realizes they cannot do the whole job at the point they are being appointed and needs to discuss with the NomCom, and there is um someone has already been appointed IETF chair and then needs to reduce their workload for some reason. And that might be a health issue, that might be maternity leave, that might be something else. And I think if we separate those three, it will be easier to make progress.

**Leslie Daigle:** Okay, thanks. Mirja.

**Mirja Kühlewind:** Mirja Kühlewind. I just quickly wanted to note that there might they might not be completely independent because if the chair is able to delegate then we can maybe pick a and this also means the stand-in emergency chair is able to delegate and that might mean we could pick a different person.

**Leslie Daigle:** Yeah, I sort of think doing the general case first might actually make more sense in that regard. But. Um, all right. I think that this it's going to take a little bit of thought about how to move forward with this. So thank you Lars for uh all the work here and thank you everybody for the thoughtful discussion around all the issues. I think we at least have made progress in understanding where some of the critters with teeth are in this in this space. Thank you.

**Yari Arkko:** Thanks.

**Leslie Daigle:** And with that we are done. Thank you.

**David Schinazi:** All right, bye everyone.

**Leslie Daigle:** Bye.

**Roman Danyliw:** Thank you Leslie and Yari for facilitating us through this. Bye.