**Session Date/Time:** 23 Jul 2026 12:00

[00:00:11] **Leslie Daigle**: No. Sorry. The complainer you was last night.

[00:00:47] **Pete Resnick**: An impressive number of those.

[00:00:50] **Yari Arkko**: That's a route route thing around obstacles. Right?

[00:00:53] **Pete Resnick**: No. They don't say mister president. I wish they did. Are

[00:00:57] **Mirja Kühlewind**: you in the moment?

[00:00:58] **Leslie Daigle**: You're not in room.

[00:00:59] **Rich Salz**: You should log in.

[00:01:06] **Lars Eggert**: I mean, if they knew what they were asking for.

[00:01:13] **Leslie Daigle**: So is that the opposite of dropping the mic? He shut the door. There

[00:01:19] **David Schinazi**: shall be no one else

[00:01:20] **Lars Eggert**: who will. Oh,

[00:01:27] **Yari Arkko**: no. I have something next week.

[00:01:31] **Lars Eggert**: Y'all need to go skiing.

[00:01:34] **Rich Salz**: Got a flight. I'm impressed by the small number.

[00:01:39] **Leslie Daigle**: Yeah. Well, I'm I'm impressed because it it looks like everyone was so convinced this room will be overrun. They decided to participate remotely.

[00:01:49] **David Schinazi**: Yeah. We have three people. Three remote participants.

[00:01:53] **Leslie Daigle**: Alright. So Yes. We are gonna get started soon. So if you are in the room, please do get in the room. Shall we?

[00:02:14] **Lars Eggert**: Alright.

[00:02:21] **Leslie Daigle**: Getting getting rolling here. This is the note well. By Thursday, you should have all noted the note well well. But as always, we aim to conduct our work professionally with courtesy, and you can dig in for more details about the anti harassment procedures and as well as the IPR rights to which your contributions are subjected, some meeting tips, and this session is being recorded. Some resources for IETF 116 in Vienna. And I should say, I'm Leslie Daigle, one of your co chairs for today.

[00:03:00] **Yari Arkko**: And my name is Yari Arkko, the other co chair.

[00:03:04] **Leslie Daigle**: Alright. So we have an agenda. Go us. There is a there's an an adjustment to the agenda from what was first published. So we're going to actually start off by talking about getting clarity about the the scope of the working group. And if there are no other batches to the agenda, I suggest we just launch into that. Okay. Okay. Do you wanna walk through this? Or

[00:03:38] **Yari Arkko**: Alright.

[00:03:43] **Rich Salz**: So

[00:03:47] **Yari Arkko**: our focus has been on creating the best documents that accurately and clearly document what the current process is and how it's been agreed already with the IETf community. Constructive clarifications have been included in in some cases, and it's been clear that extensions and changes and innovation in process space has not been part of the current exercise. That's deferred for future work or possibly other working groups. Next slide. And then we've had some discussion in the last two months or so on this. And there's a question of how do we actually interpret the charter. And if you take a very strict interpretation of the charter, that means that editorial fixes and alignment with reality are out of scope. So this would potentially exclude changes like details that have changed, for instance, email addresses, and maybe those addresses shouldn't have been in the document to begin with in 2026, the classic one, because things just tend to change. In addition to email address, there's also been a lot of references to technologies, FTP and code for anybody. And so, obviously, that that's kind of out of date, so we'd like to change that. And if there's been other documented changes in the IETF that we'd like to not disagree with or use the new terminology, then that's not necessarily easy unless there was an explicit updates 2026 or updates 2418 in in those documents. But that's not the case for everything we believe. And we might end up producing somewhat misleading documents, nothing, you fundamentally wrong, but doesn't feel right necessarily either. And our interpretation working with our AD here is that the current drafts are not in alignment with the strictest in the interpretation of the charter. Next slide. Oh, yeah. There we go. So we have a couple of options in front of us depending on what the ADM working group wants to do, and we've had some discussions among the chairs and AD and our editors. We have a proposal. So the option one is revise the documents to be in compliance with the strict interpretation, or two, update the charter to properly capture the intention of creating and update usable process documentation that matches current reality but doesn't do any future innovation. Yeah. And this is this is what we are recommending. And and on the next slide, we have a proposal. So just for your memory, the current specifications that says that we will merge all documents with update these RFCs that we are having a BIS document on and any associated or verified errata. What we're proposing is to add the blue statement at the bottom. So reading that aloud, the outcome document shall document current policy accurately to support this alignment, the working groups can integrate RFCs and ISG statements that document the process of the IETF as well as tooling changes that have been introduced where it influences text that was already in RFC twenty twenty six or twenty four eighteen. So we're not calling for importing lots of things that are haven't been in 2026 and and the other document previously, but we're trying to make sure that the things that are there, we can update them to the current state. I see we have a queue. Do Lisa, you wanna add something at this point? Or

[00:07:46] **Leslie Daigle**: Yeah. I just I think that in in reality, what we're proposing is to update the charter to better reflect what we thought we were doing, and I'll leave it at that. So there is a queue. So, Robert, do you wanna start?

[00:08:05] **Robert Sparks**: Yep. Robert Sparks. I'm very much in support of accepting the proposed change and taking option two from what the previous slide said. The text as written has a, small catch point for me. I trust the authors to do the right thing, so I'm not really going to try to wordsmith it. But I will point out that we've been very careful to avoid tooling details. So where it talks here about, you know, capturing tooling changes, we want to consider whether or not we need defense against other people coming in and saying, oh, but you need to put this piece of mechanical information into this document right now. And we say, no. That's not what we're doing.

[00:09:02] **Yari Arkko**: I think that's right. And, I mean, the thirty years of experience from 2026 says that not everything survives at that level. I mean, it's rather document the policy than the implementation as a URL or email address or a name of a tool.

[00:09:19] **Leslie Daigle**: And and I'll observe that a previous overly verbose version of the proposed text pointed out that what we're aiming to do is make the text tool agnostic, implementation agnostic. But so we're on the same page. Pete. Please, if people could introduce themselves at the mic.

[00:09:38] **Pete Resnick**: Yes. This is Pete Resnick. My one concern here, and it starts a little bit from where Robert is, I I want to be real clear about what is what happens to be now versus what is really existing policy now. So for instance, there were tool changes that were made because that's the way the this IESG happens to work or one twenty years ago happened to work and wasn't really a policy change on the community's part. It was just that's within policy and perfectly reasonable for them to do. I I'm most worried about things that are fully against what 2026 says, and there's no documentation anywhere that says that this is the way we do things now. I like some sort of really controversial stuff circuit breaker in here. And, yep, to an extent, I trust these document editors, but we need something to bop people on the nose who so we can say, no. That's not it.

[00:10:53] **Yari Arkko**: So so, Pete, not just the document editors, but ourselves also because the working crew will will review. And I'll give you maybe you'll now go back to the mic and answer a question, Pete. One example, not documented in an RFC that I know of. There's one sort of vague IST statement that kind of talks about a side issue relevant to this, but IT expiration and documents on on the, you know, on the web page. 2026 is pretty clear. Decades of current practice is we we hold them.

[00:11:31] **Pete Resnick**: Yeah. I and, I mean, that one, I wanna say enough things have shifted document wise where I think we could collectively say we're doing something different than what's in 2026, and maybe we can call up some text. Maybe we can't. The one that I was most worried about was the 2418one, which was mentioned at some point, which I would love to get rid of the 51% isn't consensus and 99% definitely is, but we haven't documented that yet. It's sort of why Mark and I started a draft. Right. So, you know, coming up with some sort of balance and coming up with some way to say, yes, that is, no, that isn't, would be good.

[00:12:19] **Leslie Daigle**: I I agree with that it would be good. I'll observe that the first sentence in blue is the outcome documents shall document current policy accurately. And and I appreciate that doesn't catch the corner cases where things have been done differently. But so that's the target outcome. Somebody's got words to capture the concept, like, if you put your fence into the common area 10 feet, and after after so and so many years, you now own that property, if you've got words for that, please suggest them. I think we would very much like to leave this room feeling like we have solid text to send to the ISG as a proposed charter change. So we're in alignment. We need text. David.

[00:13:00] **David Schinazi**: David Skenazi. Yeah. A process enthusiast. It's not funny if I do it every time, Jay. And it's still yeah. Yeah.

[00:13:11] **Leslie Daigle**: Not sounding so enthusiastic today.

[00:13:15] **David Schinazi**: Yeah. Give me a few more meetings, maybe not. So I'll start off by saying I agree with everything that's been said in terms of the goals. And but, you know, then I'm gonna nitpick about the details because that's where all why we're all here for. Because I totally agree that I'm gonna be writing some text in 2418bis, and Pete's gonna boot me on the nose, and then I'm gonna back out the text. So we're aligned on something fine. And then, hopefully, that doesn't hurt too bad, and we'll all be happy. But no. So more seriously, the I think, to Robert's point, instead of saying as well as tooling changes, I think we can wordsmith that to say updating tooling references to reference the underlying policy. That's my I'm sure someone in the were in the room can find better text, but I think that's what we're trying to get at is that those documents made the mistake of focusing on tooling details, which, like, for example, you know, if the agenda needs to be posted is the concept that should remain and not it needs to be emailed at agenda@atf.org, which goes nowhere now, I think. Things like that. So I think there to Pete's other point, I think as an editor, there have been some changes that I would consider editorial. Like, one example is the text said the I s e g. I think we all agreed it was I e s g. Another example that's a bit more subtle is the text said amongst senior members of the community. Someone suggested replacing that amongst experienced members of the community. I think that's a better word for it. I would like, as an editor, to be able to make these kinds of changes because our role here is to make a better document. My proposal, and I don't know exactly how to put that in a charter, is to say that edit purely editorial changes are allowed. And if it's anyone kind of objects to something being editorial and we can't resolve that through discussion, then it is not editorial and has to be backed up. Would but, again, I don't know how to put that in Charter. I

[00:15:29] **Leslie Daigle**: is complaining.

[00:15:30] **Yari Arkko**: Yeah. I I I think that that's a valid request, and I would support that personally at least unless Roman is jumping up and down, and he's in that moment.

[00:15:40] **David Schinazi**: Long as we're on the same page I've not ever seen an ITF working group that couldn't make editorial changes to documents. So as long as we're on the same page that that's what we're doing, then that's totally fine by me.

[00:15:52] **Leslie Daigle**: Yeah. I think we're gonna need a comment from Roman on that because, I think that there were concerns that that might not be adequate.

[00:16:09] **Roman Danyliw**: Having reflected on all this, I think we all want the same thing, which is the middle sentence. The outcome document the outcome documents shall document current policy accurately. I would like some bounds on that.

[00:16:25] **Yari Arkko**: You know, part of

[00:16:26] **Roman Danyliw**: it is part of why I've been treating this as such a key gating function is so just so we finish. Because if we continuously kind of polish, the the line between editorial and wanting new work becomes kind of attention. So I was aspiring for us to get to the finish line on something pure editorial to get us to getting the substantive changes, which I think is what everyone ultimately wants to kinda get to. Though the new words there, I was quite happy kinda with those new words. Let's continue to iterate over those words such that we can insert in all the changes that we think we need. I have done a prepublication review. I have not yet received the document for I haven't reviewed 2418bis. I haven't officially gotten 2026. I have reviewed everything we did in 2026, and I'm comfortable with that scope. We'll cover everything we did in in 2026. I just haven't looked at 2418bis. Yeah. I I'll take I mean, I trust your judgment. I was just wanting to convey to the working I have looked at this charter scope and what is in the current 2026 would be captured here. Yeah.

[00:17:31] **Leslie Daigle**: So I'm I'm pretty eager to do as much as we can to get an update agreed on in this context so that the we'll have some momentum coming out of this room. So I'm not clear from what you just said, Roman, if you would be happy with dropping everything after the outcome documents, shell document current policy accurately. Accurately. No. Yeah. Yeah. I and and I get where David's coming from. I do. But but this is the difference is it all comes down to one's comfort in dealing in uncertainties, how I've framed it. Right? And I think Roman would like more certainty. Sorry. Go ahead, Rich.

[00:18:16] **Rich Salz**: Yeah. Hi, Rich Sauls. No surprise. Fully support this. Thank you. I think when we were starting off with the draft, you know, we the charter, we were really concerned about opening up a huge can of options, and we we overly constrained it. So that it was kind of a mistake. Also, I think we realized far along into the process that putting out something that did just strictly merging the editorial, we thought that would be good, and it turned out not to be good because it would give we published new RFC that we knew was wrong, and nobody wants to do that. So, yeah, I I support this, and I don't care too much about that little wording. If David said he's fine with it and it's gonna and this meets the changes that he's seen so far, great.

[00:19:12] **Lars Eggert**: Hi. Lars, I get Mozilla. I also fully agree and wanna argue. Sorry. I I so, specifically, looking at the blue text, the the thing that gives me pause is the mention of ISG statements because, at least in my understanding so the the the RFCs the process RFCs give the policy, and the IT ISG is able to move inside that policy and as are the chairs. ISG statements are statements by the ISG that sort of interpret their current application of a process inside this policy envelope. Right? And and to me, at least, I I can read the blue text as if we now make them we bake them in, and we take away the flexibility of a future ISG to say, you know, the world has changed, and we're gonna within the framework of the of the process slash policy documents, we're gonna apply the policy differently. And and and I think I hope we don't want that, and and I maybe we can make it clear that that's not what we want. So so I I actually don't know why ISG settings are in there at all. Draft expiry. Draft expiry?

[00:20:29] **Roman Danyliw**: Yeah. Draft expiration. Yeah.

[00:20:33] **David Schinazi**: Can I

[00:20:34] **Lars Eggert**: Okay? So then let's be specific. If that's the only thing, then because there's a lot of other stuff in ISG statements that I think we

[00:20:40] **Yari Arkko**: don't Yeah. I I can explain. It's probably there because I asked it to be there, and that was my interpretation at the time that an ISG statement actually talks about the expiry. On reflection, I'm not no longer exactly sure because it actually talks about another topic and sort of passingly refers to the expiry stuff. So if you can handle, I draft expiry in some other fashion, for instance, by referring to the what the tools do today or even removing the whole statement about expiry and, you know, ITF tools will display drafts in some fashion. That's their problem. Then we clear. We could delete that part. Sure.

[00:21:22] **Roman Danyliw**: Alright. So hearing the iteration and seeing the difficulty we are my desire to match moving to closure on the kind of on the issue. At the same time, realizing we have a crisp policy statement, I am willing to say my I would be comfortable with clipping everything after policy accurately. I don't know what that changes in those perspectives. Because I

[00:21:48] **Lars Eggert**: I mean,

[00:21:49] **Roman Danyliw**: I wanted a list of what I would say authorized sources, which is a list of things that are triggered. But, mean, I I I feel like we are kinda having a lot of difficulty in in coming in coming to it. If we have a scoping statement that we can check whether it accurately reflects things, that would be enough then.

[00:22:08] **Murray Kucherawy**: So that changes entirely what I was about to say.

[00:22:12] **Leslie Daigle**: And you are?

[00:22:12] **Murray Kucherawy**: As Murray, agree with the with the proposed amendment. With that change even is fine. I guess I would just say that we should take this the ICD should take this as an opportunity to clean up any other statements that we don't care about anymore because there's a lot of stuff in there sometimes that's just old and forgotten. So that's just a housekeeping thing rather than a chartering thing at this point.

[00:22:35] **Mirja Kühlewind**: Yeah. It could've been. When I joined the queue, I was I wanted to ask why do we have all these constraints and we got a little bit over this. I totally understand initially when we created the group, we wouldn't we didn't want to make it too big. We wanted to do this one thing we wanted to do and go for it. But now we spend actually much more time in this group to discuss about things that we can't do than the things we wanna do. So I would be in for kind of removing most of those constraints and really just, like, spelling the goal we wanna achieve because I think nobody in the room actually wants to boil the ocean. We just want to publish an ROC at the end that actually makes sense and is accurate.

[00:23:10] **Yari Arkko**: Eckert?

[00:23:13] **Eric Rescorla**: Yeah. I I largely agree with what Maria just said. I mean, the purpose this is with the charter, not about the document. And the purpose of the charter is to both empower and constrain the group. And I think that the empowerment piece is the, you know, is document current policy accurately, and that's also the constraint piece. Namely, it says, like, dude, you're not supposed to, like, craft entirely new policy. You're supposed to, like, push, like, take things that are current policy and write them down. And I think that, you know, that certainly that could be used as as as suggested to take things which were, you know, within which were previously when the policy envelope and the ISG wrote a statement about and ossify them. And the group shouldn't do those things, but I don't need to preclude it from doing the right chart or they shouldn't do things that are foolish. And we can decide that with the usual process. So I think that, like, I think I'd be I'm fine with this text, but I'll be fine with striking out, you know, everything after accurately.

[00:24:02] **Leslie Daigle**: Thank you.

[00:24:03] **Colin Perkins**: Hi. Colin Perkins. Just in terms of helping manage the process, I wonder if it would be useful for the group to collect all of the updates to 2026 that have been published, put them into one document. Do a consensus call to say, do we agree that this accurately reflects all of the updates with the editorial things? Get agreements on that, and then move on to do the the new things, which which is a lot of work. But having that agreed point might be a useful step. And I don't know whether that's feasible, but that might be a useful process step.

[00:24:45] **Leslie Daigle**: So I think part of the problem there is that that that essentially has been done and it creates, like, a nonviable document. It's like, you can't not have the conversation of, yes. But

[00:24:56] **Colin Perkins**: Yeah. I'm I'm not saying we should agree that this is done and we should publish it.

[00:25:00] **Leslie Daigle**: I'm saying we should agree that this wraps up And and I think everybody in this room today understands that. And I think when we circulate it on the mailing list, we won't understand that.

[00:25:08] **Colin Perkins**: Yeah. Possibly. Yeah. Okay. On the Internet draft expiry, I was a little confused because I thought that was in r c twenty twenty six. Okay. Yeah. Because I mean, I have the text and it seems to say that the expiry is after six months is in that. So But maybe that's a different question. Yeah.

[00:25:28] **David Schinazi**: Just to to answer as a clarifying point, I just pulled up 2026 in the diffs. 2026 said that the draft expire after six months and then are deleted and no longer visible. The change in policy is that they're still visible. They still expire.

[00:25:45] **Pete Resnick**: Oh,

[00:25:49] **Leslie Daigle**: look. That's me. So a couple of points. One, we have plenty of buffer in our time slot to be spending time on this topic, but I don't want us to just spend the whole meeting on this topic. Wanted it early in the meeting just because it does frame where do we go from here. I'm going to remind everybody that part of why we're even having this discussion and when it seems so obvious to the people who are in this current discussion that the what the goal outcome is and what the rational things to do are to get there, that this came up because there was some pretty strident pushback on some changes on the mailing list on the argument that we were not chartered to do anything other than doing strictly updates from putting together the mechanical updates from twenty twenty six bis and twenty fourteen eighteen bis. So if we're gonna make sure we're all comfortable when, you know, we move forward from here, either we update the charters so that we feel like we've got an answer to that question and still are able to reach the the the goal of of the documents, or we need to be comfortable with a different way of pushing back on that kind of pushback.

[00:27:04] **David Schinazi**: Thanks, Dave Scorazi. Teamed me up perfectly. I think listening to this conversation, I'm now pretty firmly convinced that we should just add that first blue sentence and not the rest. And then we rely on the ATF consensus process to keep us in check. If, let's say, I make a diff to the document and says to remove the expiration of Internet drafts, which I think is something that I would like to happen, y'all will remind me that we don't have consensus to make this change, and that change won't happen. And, similarly, there are some topics like appeals that we might not have consensus to change how we discuss them. And we've done this before. We'll do this again. Our consensus process works. I think this is just the escape hatch to allow us to make the changes that we've been meaning to make, and the boop on the nose that Pete has described is the we don't have consensus to make this change. I think that's enough for us to get the outcome we want.

[00:28:11] **Rich Salz**: Rick Stall's still too short. I would as the editor or author or whatever the term is, I I'm not comfortable with striking everything after this that first blue sentence. I would strike the positive that says IESG statements that document the processes. And we can defer to the fact that the tooling changed because things are different, but I'd really like to see that kept just because I've had enough arrows in my back.

[00:28:43] **Leslie Daigle**: So you're saying you want to keep to support this alignment, the the the working group can integrate RFCs as well as tooling changes that have been introduced where it influences

[00:28:51] **Rich Salz**: the text? Exactly.

[00:28:52] **David Schinazi**: Okay. Why?

[00:28:54] **Rich Salz**: Because I don't wanna get nasty email from Dan telling me that I'm off the reservation and my draft should be thrown out and and burned. It it would it won't stop him from saying that, but then it will the chairs can go, oh, no. We're allowed to incorporate tooling changes. Alright.

[00:29:15] **Leslie Daigle**: So so Robert is gonna wanna get in queue. Yes. Thank you. Mary, I think you're next.

[00:29:23] **Mirja Kühlewind**: Yeah. Cool. And are we cycling in the same order through the queue? I wanted to add to my previous comment that so I I don't think it's useful to talk about tooling or ISG statements here. These are both very specific points, which shouldn't be in the charter. The charter should really help us to do our work and not stop us doing our work. I think we got a good work mode of working here that we can make progress. I'm not worried about that. I just wanted to add to my previous comment that I think the only constraint that I could see is that the only thing we shouldn't do is really inventing completely new policy that is addressing a problem that wasn't addressed at all yet. But anything else we should, like we we honor we think it's the right thing

[00:30:06] **Leslie Daigle**: to do. We should do it. Thank you, Pete.

[00:30:14] **Pete Resnick**: So, Pete Resnick, I agree with Myriad on the basis here. I want more that the chairs and the AD and maybe the editors feel empowered to push back at the appropriate things. So if they're all okay, if you all are fine with removing the rest, I'm fine with removing the rest and leaving just that first sentence in blue. If you need additional, you know, then you do wanna open it up to purely editorial changes, which this doesn't specifically say. There's a little concern about current policy accurately. I do not want to get into any of the clarifying what documented means at the bottom of the whole public record section. I I I think that's just opening cans of forms. So delete the rest. That's good. So long as you feel like you've got enough tools to push back on silliness.

[00:31:21] **Leslie Daigle**: Thanks. And I've locked the queue at this point in the hopes that Roman at the end of it, we will reach some level of conclusion. If not, I'll unlock it. Eric?

[00:31:34] **Eric Rescorla**: Yeah. So I think, as I said, I don't actually care much about whether things, go after accurately, but I think that the problem with this, like, next sentence is that input that I would read this as if it's exclusive, as if these are the only things that you could you could bring in. And I don't think that's what you we were trying

[00:31:52] **Yari Arkko**: to say.

[00:31:54] **Eric Rescorla**: What do you mean?

[00:31:55] **Leslie Daigle**: Insert such as.

[00:31:57] **Eric Rescorla**: Yeah. Yeah. Yeah. Yeah. That'd be that'd be great. That'd great. Yeah. Yeah. Yeah. I absolutely. I'm I'm just saying it was not it was not create a new box for ourselves, Mary was saying. That's all I'm endorsing.

[00:32:13] **Yari Arkko**: So

[00:32:23] **Robert Sparks**: Rich just offered to withdraw his discomfort. So I guess I will this is Robert Sparks. I'll I'll I'll I'll say a couple of things quickly. First, arrows of the kind that Rich referred to are not going to stop. Other sources will launch them, and I don't think that the Charter text will affect that really. Second, if we want to have these notional things that we can change reflecting that it's such as, and there is discomfort around the specificity of tooling changes, consider saying instead updating artifacts such as, and I'm sorry, this is long, Such as email addresses or references to specific operational realizations of so that it's tied into something that's very clearly not policy. It was very clearly implementation, but doesn't say specifically try try to call in that we're going to try to bake those things back in, that we're only updating the references to the the the existing references to them. So

[00:33:47] **Leslie Daigle**: Thank you. Lars?

[00:33:49] **Lars Eggert**: Yeah. Lars, I got I think I was gonna say the exact same thing. So in my mind, we want to remove those or change those bits of the existing texts that were implement implementation changes at the time crept into the text, and they're no longer accurate because the the implementation side has moved forward. And and maybe we wanna capture the the effects or implications of those that those tooling changes sort of expressed in in more general terms Mhmm. And make them too but make them tooling independent going forward. Mhmm. That's sort of how I think about this. Right? Sort of somebody wrote text. It was a little bit sloppy. They talked about, like, an email list because, you know, that was all they had back then, and now we don't use an email list anymore. But I think David made an example, right, about announcing something that the the in announcing or the posting of the agenda is the important thing, not the how it's supposed to just because, you know, documents as email. Yeah.

[00:34:50] **Leslie Daigle**: The doc the outcome document shall document current policy accurately and is in of specific possibly changeable implementation mechanisms as possible. Too many possibles, but that drift?

[00:35:04] **Rich Salz**: It doesn't need to be a charter.

[00:35:06] **Lars Eggert**: Yes.

[00:35:09] **Roman Danyliw**: It's it's

[00:35:11] **Lars Eggert**: it's not quite it's that, but also I think it's important to realize that there might be text that is expressed in terms of a tool and how it's used that is actually setting a policy or has been, in the meantime, understood to be setting the policy, and now we are implementing that same policy with a different tooling mechanism. And I think we wanna extract the policy that is in the original tooling specific text and generalize it into words that are not about tools anymore.

[00:35:41] **Rich Salz**: Yeah.

[00:35:43] **Yari Arkko**: And the final word from our lady.

[00:35:48] **Roman Danyliw**: Great. Oh, good. So I I actually had an adjacent issue to whatever we decide for the blue text. I looked at it for the first time in the context of everything else. And if the notional bar for success given some version of this refinement is shall document current policy accurately as the bounding kind of the success criteria, we might wanna remove some of the more confusing stuff that's later of because previously, the text talked this notional idea of editorial and non editorial changes. So I might suggest there's a sentence that says, additionally, the working group may consider revised procedures in in in these documents, parenthetical, non editorial changes around, I would suggest we remove that parenthetical. So we're just basically talking about existing policy and kind of new policy, and then it might be CRISPR in a self consistent way.

[00:36:36] **David Schinazi**: So

[00:36:38] **Roman Danyliw**: But you wanted me to answer something else, maybe?

[00:36:40] **Leslie Daigle**: No. I think it's the where from here question at this point, in my opinion. I I'm I'm good with that as long as, know, by next week and the week after that and the week after that, we still agree that the current documents as as they stand are on the correct trajectory and will be supported in moving forward. We started this week where it sounded like we were going to have to rip the guts out of existing Internet drafts because of a strict interpretation of the charter. So all I want as a working group chair is confidence that we have enough that you've got whatever air cover you need to support us on the current trajectory.

[00:37:22] **Roman Danyliw**: I think as I said before, I have not dived into the diffs on twenty four eighteen. I have dived into the diffs of 2026, and I am confident that the first sentence now hearing kind of this discussion with potentially some caveats. I I don't know how we were gonna modify the infrastructure kind of whatever would cover us.

[00:37:45] **Leslie Daigle**: Okay. Thank you for speaking into the microphone. Okay. So I think with that, we have approximately enough to move on. Let's do that. Thank you everyone for the robust discussion. I remember to share slides. If you yeah. I do.

[00:38:13] **Pete Resnick**: Yes.

[00:38:24] **Leslie Daigle**: Okay. Yeah.

[00:38:28] **Rich Salz**: Still Rich Saul, still too short, still not Scott Bradner.

[00:38:31] **Leslie Daigle**: Nah. The microphones are all set too high.

[00:38:33] **Rich Salz**: Yeah. There we go. Okay. Talk about changes in 2026. Drafts since the last time we met. Bunch of drafts have been published. Draft six, typo fixes, editorial fixes for the BCP's STD subseries numbering contents, shuffle text about when the IETF evaluation IESG evaluation happens versus the IATF last call. I tried to make it chronological. It didn't work. Pete helped fix that. Draft seven, there's some other follow on changes. Didn't get it all right. Pete still helped fix that. Added a reference, and so on. Change the RFC editor link. I'll bring that up in the open issues. And the other the other major semantic change in draft eight was that standards action requires IESG approval because well, it does. Interestingly, historic and or coincidentally or providentially, historic and expire historic and obsolete, whatever the two things that aren't standards track designations, proposed standard and Internet standard, those are also described as, standards track levels / standards levels. So those also therefore need IESG approval. I didn't wanna become an originalist interpreter of the constitution, but so it happened. Okay. So draft nine was a special isolated draft. It removed text to clarify things, that weren't part of the updating documents. Dan Bernstein identified them, confirmed by Roman. We had some discussions. Turns out it was wrong. Twenty twenty six actually does identify the minimal set of things that are in the public record, and it does not mandate that all discussions happen publicly. Only maybe the first email that says, let's meet to talk about this, and then that's no longer required to be part of the record. So we can revert nine. Oh, I thought it was a question. Okay. So draft 10. This was the start of the ones that addressed the working group last call issues. Huge thanks to Yari for reviewing and summarizing the the changes, categorizing them. That was used as the basis for my draft. It used as the basis for Roman's review. A whole bunch of editorial changes. I'm not gonna list them here. One of the things it did is it changed the way we do the I do the change log so that we describe the rationale so that we never have to do this again. John, you wanna talk now or wait till the end?

[00:41:21] **John Klensin**: Sorry. Now is fine because this is a very quick comment. Using I I haven't studied this text since you've got it. But using Unicode instead of ASCII is not a small editorial change. It's a big deal requiring a lot of qualification. Well because it's a member, you know

[00:41:40] **Rich Salz**: No. What it's used is as an example to say we can reference an external standard. And so the previous version said, for example, it's okay for standards track documents to reference certain known external standards such as ASCII, and it had a reference to US ASCII. Now it just says, it's okay to reference external SDO based standards such as Unicode. That's all it does. It doesn't change the content of the RFC

[00:42:06] **John Klensin**: at all. We're lucky to okay.

[00:42:08] **Rich Salz**: Okay. Alright. I knew I knew mentioning Unicode would be a way to summon him.

[00:42:17] **Pete Resnick**: Wake everybody up.

[00:42:18] **Rich Salz**: Alright. Draft 11. It was called working group last call number three. There is no rule six. I mean, sorry. Working group last call number two, it wasn't there. Revised the wording to say these nonstandard track material maturity levels follow this process in editorial eight. That's that's a editorial thing. There was an issue Brian most of these were things Brian Carpenter found. We you know, some some TS state technical specs use the word elective, some use the word optional. So now we can when you're writing a spec, you can elect to use the word optional or optionally use the word elective. Uh-huh. Yeah. It was it late. And we also would add a we thank Dan Bernstein for his feedback. I hope he chokes on Now. Sorry. No. We do. Because he it was useful. Right? It got us to this point today. Okay. Forthcoming. These are now a little outdated given what we've had. Yeah. But they'll be simple. Draft 10 missed one instance of nonpublic discussion that you already found. Tweaked the wording about the IATF last call. He said, you know, all the anyhow, it's a really minor editorial change. It says, except as described below, and that has to do with the BCP getting reviewed. Okay. So this is the interesting thing. Open issues deferred, from Yari's summary. Who now it's not probably no longer deferred, but these are things we want to address in a future draft. Who determines the IETF consensus? Everybody knows. So when you publish when the ISG sends it out to, you know, the last call mailing list or informs people of the last call, shall we say, who determines whether what the IETF consensus is? The documented the draft that says you must do that doesn't say who does it, but we all understand it's the IETF. So I'm tending to say who you know, anything published on the IETF stream must have IETF last call, comma, as determined by the IASG. Use inactive and not expired again because the tooling changed, there was a statement that told them to make the tooling, so things are there. Didn't not actually saying yeah. Brian withdrew his request to make this change and say, use inactive and not expired. Massive tooling change. Don't wanna do it. We've discussed this before a couple of times. There have been dispatch gen dispatch proposals to say they don't expire, but okay. Also, this so I guess two out of the three are deferred. Incorporate 1311, which isn't as simple as we first thought it looked. It that's the one that defines I forget. STD. Yes. Thank you. It defines the STD sub stream. We're not gonna we're not gonna do that. That'll wait for a more substantive change. Although, now that we have authority, maybe we will. Yeah. Maybe. Okay. So here's here's the real open issues. Referencing RFC editor referencing RFC editorial links. I've tried to minimize the external links and just point people to, like, oh, you can find them on the RFC editor page, for example. I don't know if we wanna if people have a concern or a policy or a preference about that. Do we reference the RFC style guide in the author's page, or do we reference the RFC the IETF's author style guides or or pointers to it, and not just the formal RFC publications? So I'm curious what opinions people have.

[00:46:07] **Yari Arkko**: Yeah. Yeah. Riakou speaking. It's just a personal opinion. Observation from looking at the things that need to be changed from 2026 is that almost nothing of the references survive when they point to particular identifiers such as emails or URLs or or technology. So what does that tell you?

[00:46:30] **Rich Salz**: Okay. Yep.

[00:46:33] **David Schinazi**: Plus one. If you're looking for something, use your favorite search engine and actually don't do that. Maybe you're a search agent. Who knows? Yeah. No links. None of this. People can find stuff. Regarding the style guide, we've already removed it from 2418bis. Similarly, I don't that is guidance. It is not process mandate. So that would be my recommendation to remove all this.

[00:46:58] **Rich Salz**: Okay. Anybody feel otherwise? So my takeaway is we can point to, like, the site.

[00:47:07] **Leslie Daigle**: Gene, did you wanna get in on that?

[00:47:14] **Jean Mahoney**: Jean Mahoney, RFC Production Center. Yes. Higher level is better. Of course, rfceditor.org is going to be here for the long term. URLs change. We do put in redirects. But for instance, instead of saying seventy three twenty two for style guide, say, look for the style guide on the RFC editor website.

[00:47:37] **Rich Salz**: Okay. Great. Thank you. I hope I can read that tomorrow. Began. Alright. Sequencing for 2418bis, that there is some overlap between the interlock between the two documents. Leave that to the chairs to lead how we wanna do that.

[00:48:01] **Leslie Daigle**: Yeah. I think that's gonna wind up being a question. So that was something that came up on the mailing list when we put twenty 2026bis out for a working group last call, and a couple people said they really wanted it to be in sync with 2418bis going out for working group last call. At the time, they seem to be on a different time course. I don't know if they're close enough at this point that that's an easily solvable problem.

[00:48:27] **David Schinazi**: David Skenazi, editor of 24 eighteenbis. You will see in the next presentation that I think we only have one open issue left on that one. I'm sure there will be a bit more, but I think we're much closer there than we just initially thought. So I'd say hold that thought until after my presentation perhaps.

[00:48:45] **Leslie Daigle**: Thanks. Okay.

[00:48:45] **Rich Salz**: Yeah. And the justification was remove remove text from one to the other. I don't remember what direction. So okay. Next steps, this is a little outdated because there's a few more changes to make, so there'll be at least one more new draft incorporating the things I intend to yeah. Well, like, it's you want a milestone?

[00:49:07] **Lars Eggert**: No. How fast do

[00:49:09] **Pete Resnick**: I need to get the the review of the comments?

[00:49:12] **Rich Salz**: Oh, yeah. No. I'm there's I think we have how do I say this, much more relaxed about this process now. So I'm not gonna

[00:49:26] **Pete Resnick**: Not days.

[00:49:27] **David Schinazi**: Yeah. No. It wouldn't

[00:49:28] **Rich Salz**: be it's certainly not hours, not days. But, you know, I I expect at least two weeks between between drafts and for every draft for people to review it. Like anything else, when you're editorial when you're making editorial changes, you catch it earlier, it's better off. So, yeah, these next steps are wrong. We'll confirm consensus on the list for all the changes. And the change log, as I said, will have generally pointers to where what the authority is that said we can do this, or it'll just, you know, have some kind of text. So thank you very much. I think I'm done.

[00:50:04] **Leslie Daigle**: Any general questions for Rich in the document?

[00:50:10] **Rich Salz**: Cool. Thanks.

[00:50:11] **Leslie Daigle**: Thank you. Thanks, Rich. Alright.

[00:50:21] **David Schinazi**: Hey. It's me again, David Skenazi. So the other document, 2418, and I'm starting to regret having put that font on my first version of these slides because I'm never gonna change it. Next slide, please. Oh, thank you. Alright. For I mean, everyone in this room has been in this room, so this is kind of useless, but we've been working on this document for a while. And we got a bunch of discussion at the last IETF meeting, and we're gonna go over the change that have been made since then. So one of the there was a cluster of issues around the working group roles that, like, a working group chair can delegate, such as a coordinator and this and that and a consultant that some of these haven't been used in 12. We landed a change to kinda consolidate these into one paragraph that is now on the screen, that is intentionally vague because all of those that text was also intentionally vague in the original document. And the idea is if some future area director wants to come up with a new role because it'll be very useful to this working group, that's fine. So this is just kind of a vague thing. I'm not gonna read it, but it is you can name someone anything you want so that that can help the working group. That doesn't change the roles of the working group, period. Any questions, or should I move on? Alright. Then I shall wait. Hi,

[00:52:04] **Lars Eggert**: Lars. Remind me if there's any text that actually defines where those roles come from.

[00:52:12] **David Schinazi**: There isn't. Okay. And there wasn't.

[00:52:16] **Lars Eggert**: That's my original document.

[00:52:18] **Yari Arkko**: That's what

[00:52:18] **Lars Eggert**: I thought. So so I I don't know if that's a hole that needs to be filled, but at least sort of because if especially if you're listing Yeah. Like So

[00:52:29] **David Schinazi**: so Like where they're defined. Yeah. So no. And I think the key here is Could it

[00:52:37] **Lars Eggert**: be a working group cheerleader, for example? Like, if if

[00:52:39] **Leslie Daigle**: you need a point in yeah.

[00:52:44] **David Schinazi**: So my take on this is that the role of this document is to kinda lay down the law of what can be done. And all of these were already examples, and I don't think we need to define examples. We could go a step further and remove these, but I think because some of them are used, that might be a step too far in my personal opinion.

[00:53:05] **Lars Eggert**: So so I think I recall them all coming from area directors. And

[00:53:13] **David Schinazi**: but if there is another part. I forget.

[00:53:22] **Lars Eggert**: So I think I think my my my fix would be to stick a sentence somewhere that says, the ISG may define these support roles to help working groups in their deliberations such as blah blah blah blah blah. Just so that because it's it's if it's not defined anywhere, I don't I don't remember, and I guess you don't remember either, it it feels like, you know, we we might wanna address that.

[00:53:46] **David Schinazi**: Okay. I'll I'll take a stab at polishing that. Thanks.

[00:53:50] **Yari Arkko**: Yeah. Yadak. So first, sort of a chair comment that I I feel like the working group cheerleader falls under the new no new process clause. Therefore, we can't add that.

[00:54:03] **David Schinazi**: And and

[00:54:03] **Yari Arkko**: secondly, personal opinion, I think this strikes a decent balance. Like, the the original document had, like, subsections and made it look like very official that we have these things, but, again, didn't define anything. Here, we have sort of clumped them together. There's clearly two categories. Working group chairs can do some things, invent these roles, and then ADs can invent some roles. And, yes, AD inventing a role may come from an ISTD system. We don't need to talk about that necessarily here. I I also agree that we perhaps don't wanna entirely remove that, although that would also be a, you know, a potential rational action. Other than that, this is a good balance, my opinion.

[00:54:46] **David Schinazi**: Thank you.

[00:54:54] **Andrew Campling**: Andrew Campling. I know it's implied, but since people might be picky, the second sentence where it talks about what the area directors may appoint, It doesn't say roles such as before those two. Some people may take that. I know it has an etcetera after, but it but so does the previous sentence. So you may want to consider. Yep. Happy to do that. Yeah.

[00:55:28] **David Schinazi**: Because Lars, actually, now I'm seeing it. The kind of a lot of these roles have their own sections, and some of them were appointed by working groups. And so I think that's what we landed on is the first sentence has all the ones that were appointed by working chairs, and the second one had all the ones appointed by ADs. But you're right. Let's put such as in both sentences and call it a day. Ecker?

[00:55:51] **Eric Rescorla**: Oh, well, before we talk about wordsmithing, wanna know what this is trying to say. So do you believe that the do you believe that the the what you're trying to say is that the working group chairs may not appoint technical advisers?

[00:56:05] **Yari Arkko**: I am not in no. That is not the intention.

[00:56:09] **Eric Rescorla**: Okay. Do you believe it?

[00:56:10] **Leslie Daigle**: Do you believe it? The part part

[00:56:12] **Mirja Kühlewind**: of the problem

[00:56:13] **Leslie Daigle**: is that technical advisers act there is a definition at least in somebody's head, and they do get listed on working group charter pages. So there is little you can appointed little t, little a technical adviser all all day long, but there are roles with some specific expectations.

[00:56:34] **Eric Rescorla**: I'm I'm sorry. Is is that in the document somewhere or is that just for practice?

[00:56:39] **Leslie Daigle**: I'm just telling you the way it lives in the data tracker.

[00:56:42] **Eric Rescorla**: That that that has no normative force as far as I'm concerned. So, like, I guess I I I'm just trying to understand what this is trying to say because, like, we have these two lists. Right? And one might one might read this, and I would ordinarily read this as saying that, like, the the the the the implication would be that, like, the the the the working group chairs can can do anything on their list, and the and the eighties with anything on the list, but not the other way around. And but that both the either one can invent entirely new roles that don't currently exist and put them on either list. Right? And so, like, what is it trying to actually say? And let's say that.

[00:57:21] **David Schinazi**: So so taking a step back, the previous document had all of these defined very loosely defined all these roles. And some of them, like, really apart from, like, this is a person is the only amount of definition there appeared to be, and who can appoint them? A lot of them are used in practice, so I wouldn't recommend completely removing it. I think if what you're saying occurs that, like, this seems like it's dismissing one way or any other, how about we rephrase it to say, working group leadership, parenthesis, chairs an area director, can, nominate participants to these roles so that they can help, such as blah blah blah, etcetera.

[00:58:06] **Eric Rescorla**: So so so let me let me try to suggest what I think what I think what I think you're trying to say this this means we talked to wordsmithing in a second. I think what you're trying to say is that that that that either the ADs or the chairs may appoint, may appoint or dismiss people out of the following list of things or may invent new things that they can may appoint or dismiss them to. Is that what this is trying to say? And and the powers of the ADs and the chairs are coextensive, although, of course, the the ADs supervise the chairs. Is that is that is that it? Okay.

[00:58:35] **David Schinazi**: That's right. And I think the most important sentence of this of this paragraph is the last one, which means that can appoint all you want. You don't get to change the roles.

[00:58:45] **Eric Rescorla**: Yep. I have no problem with that, and I'd be happy to attempt to help help create work. So I guess I guess I would I would ask anybody that's way it shouldn't be, and if so, argue for that. And if if not, we can try to make the worst of those things.

[00:58:58] **David Schinazi**: I think we're on the same page.

[00:59:01] **Eric Rescorla**: I think so too. I'm just saying, like, I'm just saying rather than, like like, rather than trying to refine the words, maybe you could try and make sure you know what it's trying to say, then we can come back with words that say the same same thing without having to, like, try to edit it, right, like, in this meeting. Right?

[00:59:13] **David Schinazi**: Okay. You know, that's fair. So I in terms of wordsmithing, I will do that on a PR and send it to the list. We don't need to do it at the mic. You're absolutely right. And the idea is that it will be chairs and ADs can do these sets. Can anyone That's

[00:59:28] **Eric Rescorla**: just fine to me. If anybody abject that, I'd, of course, like to hear it.

[00:59:30] **David Schinazi**: Alright.

[00:59:35] **Mirja Kühlewind**: Yeah. Could've been I felt the question was a little bit, can chairs make up a point or create new roles, is the word, without the AD approving it?

[00:59:44] **David Schinazi**: I Yes, that's that was already the case in the founding documents.

[00:59:47] **Mirja Kühlewind**: Yeah. I actually, I think I don't care. We don't have to specify it because if my AD does weird stuff and doesn't talk to me and whatever, can fire them. Okay. My booking group share. Right? So this is how the process works.

[00:59:58] **David Schinazi**: Sure. But because these roles already exist, having a mention of them in the documents so that when you search for it, you land on a paragraph that tells you this is a role that is somewhat made up that doesn't change the it's really that land sentence that carries weight. And that way, you can command f to find it. That's why it exists.

[01:00:17] **Mirja Kühlewind**: I agree to that part. But, like, initially, last question was, like, can just anybody make up new roles? Right?

[01:00:24] **David Schinazi**: And that's already the case, and the answer is yes. As long as the the new roles don't change the roles.

[01:00:30] **Mirja Kühlewind**: Yes. And I don't think you I I'm just saying we don't have to add anything more because that's already how it works. Yes.

[01:00:36] **David Schinazi**: Okay. I I think we're all on the same page here. Great. If if you're in line to tell me I'm wrong, please stay in line. If you're in line to agree, maybe don't. I'm gonna get booped on the nose again. So

[01:00:57] **Pete Resnick**: I just wanna be clear that we're not changing actual process. So for instance, working group consultants, the definition currently in 2418 sounds like working group technical advisers. We change the name at some point. It is an area director appointed thing. So if we want to change the title of that section and reserve working group technical advisers to the AD. Or if we wanna say no actual practices that could be assigned by anybody, if that's what the ISG is gonna tell you, the actual practice is anybody. It doesn't have to be the AD. You can do that too. I will note that facilitator occurs elsewhere in the document helpfully. And so there's references that need to be cleaned. Right. I let's be careful that we don't eliminate anything that is an actual process by making this would be a change if we're eliminating something that is an actual process. I worry about technical adviser in particular.

[01:02:15] **David Schinazi**: Thanks. Alright. I'll go back and double check.

[01:02:24] **Colin Perkins**: Hi. Colin Perkins. The I just slightly I I don't try I'm not sure quite how to phrase this. The the the way the starting text is phrased with you, appointing people to support roles, followed by do not alter the process and so on at the end. Is is the intent that the working group chair, for example, delegate parts of their role to these people but retains the authority themselves and takes ultimate responsibility? Or does the working group chair keep keep that authority themselves and appoint someone to help with the management? And I don't know if it matters, but the phrasing of the two parts don't quite seem to align.

[01:03:17] **David Schinazi**: I feel like I missed the nuance of the either or that you described. Can you try that again? It is the intent

[01:03:24] **Colin Perkins**: here that the working group chair delegates part of their authority to somebody to perform part of their role, or is the intent that the working group chair keeps that authority, and then this is just a some post management technique for helping the group work. I see what you're saying. That matters, but it's not quite clear from the text.

[01:03:47] **David Schinazi**: Okay. I yeah. To to pick a practical example, the do they ask someone to moderate the list, or do they hand over moderating the list and they don't do it anymore? To pick a bad example. I see what you're saying. I I think the nuance isn't crisp in the original documents.

[01:04:08] **Colin Perkins**: I suspect that's true. Yeah. I mean, I think what is happening is that the chair is delegating part of their role temporarily, but retaining the ultimate authority.

[01:04:17] **David Schinazi**: Yes. No. The I'm not sure that's correct. Accountability and yeah. Okay. Alright. I I'm gonna go back to the drawing board on this one.

[01:04:25] **Colin Perkins**: I I think the intent is good. I'm just not quite sure

[01:04:28] **Rich Salz**: the phrase Yeah.

[01:04:28] **David Schinazi**: Yeah. It Yeah. Sounds like we're all in agreement on the intent module, making sure that we don't mess up some roles that were reserved to ADs perhaps.

[01:04:38] **Robert Sparks**: Robert Sparks, when you go back to that drawing board and you feel the urge to start listing examples, check yourself and just don't.

[01:04:47] **David Schinazi**: Fair. Yeah. Yeah. That'll simplify things. So will I'll start off by checking the rest of the document for the ones that are mentioned in other places. Alright.

[01:04:58] **Leslie Daigle**: I put myself in queue just because I have a dim recollection from mailing list discussion that there was particular concern that the eighties are still able to create new roles on the fly. Still subject to the, you know, responsibility is not they retain original responsibility. But just don't break that is kinda what

[01:05:18] **David Schinazi**: I'm getting. No. No. Absolutely. I think that is the core bit of this that we need to maintain. Alright. And I thought that was gonna be the easy one. Alright. So the another one on the topic of tools and focusing on elements of technology. The pre the original document talk about moderating the mailing list. It turns out that we don't just use mailing list now. We have GitHub and whatnot. I had a proposed PR at the last IETF that mentioned GitHub. People are like, don't mention GitHub. So it says public fora and gives a few examples, like the list, chat groups, collaborative tools. And then in the second to these four, that was the list. And then it adds a small reference to ninety nine forty five ModPod.

[01:06:13] **Colin Perkins**: K.

[01:06:14] **Yari Arkko**: Awesome. Alright.

[01:06:17] **David Schinazi**: Then, ah, this is the fun one. So the 2418 had text that mentioned that fifty one percent ninety nine percent can be consensus. I knew this would give Pete some joy. So the proposal last time was to remove that and instead put in a reference on 7282, which was an informational document that just talked about consensus. It was brought up at the meeting that that document didn't have consensus. The irony is not lost on me, and so we shouldn't even reference it here as an example. So we backed that out. The what we kept in here as a difference from 2418 is the removal of that sentence. I consider that to be editorial because I I find that note to be confusing, like that 99% isn't necessarily consensus and 51% there. So I think we're better served by not having it there, and I really hope that we will have a document like the one perhaps that Pete and Mark are working on that'll clarify that separately. But if there's not consensus that this is editorial, I'd be removed, then let me know, and I'll put it back. Yari.

[01:07:36] **Yari Arkko**: Yari, go on personal opinion. So not losing sleep either way on what we do here, but just my personal thought is that among the three choices, all of them are sort of in imperfect. If we can't get consensus on Pete's document, then the other stuff is not not great. But among those three choices, maybe keeping the text as as it was in the original document is is my favorite.

[01:08:07] **David Schinazi**: Okay. What does everyone else think?

[01:08:15] **Pete Resnick**: Pete Resnick. So first choice, last choice are what I would prefer, which is to say, it is a procedural change. It's not just an editorial change, but I'm not sure it reflects reality of process. I don't think anybody is actually saying, well, 99%, therefore, it must be consensus. So I think it is okay to remove it. I would not wanna reference the 7282. If a miracle occurs and the document Mark and I are working on somehow gets published before this one does, fine. Refer to it. Don't hold your breath. Yeah.

[01:08:59] **David Schinazi**: I would not wait on that.

[01:09:01] **Pete Resnick**: So if if we can defend it as accurately removing the sentence accurately reflects the process, let's remove it. Leaving it in will just make me weep a little. That's all.

[01:09:19] **David Schinazi**: But you feel that it accurately removing the sentence accurately represents current process. Okay. Thumbs up from Pete and from Ron.

[01:09:30] **Yari Arkko**: Colin.

[01:09:31] **Colin Perkins**: Hi. Colin Perkins. So I I agree the 5199% stuff is just not correct. It doesn't reflect the process. I I do not think it's editorial. I think it's just not reflecting the process. I would be unsurprised if there were not strong objections to removing that text when we get to the last call. So it may be procedurally and, you know, for for the health of the organization better to leave that text in and produce the other document that discusses this issue in a lot more detail and have have an update to this in a year or so when the document is done.

[01:10:15] **David Schinazi**: So my personal opinion is that I'd rather not live in fear of someone hypothetically disagreeing with something. Because if a bunch of people say, we're better off removing this sentence, but someone might disagree, then I much would rather remove that sentence and wait for someone to disagree, and then I'll put it back the second they show up. But I don't know if that person exists, and I'd rather aim to make the best document we can until then. Like, there are some topics that are landmines, like appeals. That's a different story, and I agree with your point about the health of the organization. I do not think this is a landmine,

[01:10:57] **Yari Arkko**: and you can told me I told

[01:10:59] **David Schinazi**: you so if I blow my foot off.

[01:11:00] **Colin Perkins**: I disagree on the nature of the landmine.

[01:11:03] **David Schinazi**: But Okay. No. That's I mean, if the rest of the room thinks this is a landmine, then I can back that out. I just don't want us to proactively if we think it's a hypothetical landmine.

[01:11:13] **Colin Perkins**: I have seen this thing being quoted in ways which make me think this is a landmine too often

[01:11:19] **David Schinazi**: Okay. Recently. Alright. Because I have not seen it quoted. That's fair.

[01:11:22] **Colin Perkins**: It has been mentioned on social media a number of times, specifically this text.

[01:11:27] **David Schinazi**: And I'm seeing nods.

[01:11:31] **Harald Alvestrand**: Harold? And I don't understand. I'm one of the ones that have mentioned it in various for I mean, it's a I think it's conformant. The that I think the sentence is actually conformant with current practice in that any consensus process will for any further definition of rough consensus will fit somewhere within the 51 to 99 range. And so I don't think it's false. And I found it didactically useful in explaining how things work. But I would definitely want to be happy if it was clearly stated as as, what is it, informative reference?

[01:12:29] **David Schinazi**: Sorry. That what would be refer used as an informative reference?

[01:12:33] **Harald Alvestrand**: No. It what we explained through a text rather than than anything that people would cite as normative.

[01:12:42] **David Schinazi**: Oh, taking that sentence. I mean, I I don't have it top of mind if someone's in front of their laptop. I I think it's described as, for example, comma.

[01:12:52] **Pete Resnick**: It doesn't say Yeah.

[01:12:53] **David Schinazi**: It does not say that. My memory is failing me. Note that. Okay. So then

[01:12:59] **Pete Resnick**: 51% does not.

[01:13:01] **David Schinazi**: Oh, okay. Alright. Well, that's why I'm completely mistaken. Alright. It sounds like I should revert the change, leave it back in, and then leave this to a different document that might update this one.

[01:13:13] **Harald Alvestrand**: Sounds good to me.

[01:13:15] **David Schinazi**: Alright. Ron?

[01:13:16] **Ron Bonica**: I'm standing up to argue the opposite of that. I think fifty one and ninety nine are attractive to rules lawyers, and rules lawyers are detrimental to the IATF process. And having it in there encourages rules lawyering in a way that is not good for us. I would prefer to have the people who want it there have to stand up and justify their reasoning for wanting it in there and why they think that that is good for the IATF. So I would prefer to remove it. And then if it gets to the point that people object to that, have them justify themselves.

[01:13:55] **David Schinazi**: It's bold statement to make in a room full of rules lawyers. I I'm hearing good points on both sides here. I'm kind of at a loss.

[01:14:07] **Leslie Daigle**: It seems like 51% split.

[01:14:13] **Mirja Kühlewind**: So we could even also stand up to argue that I think taking it out is a better option, but I don't have a strong opinion, so I will not. But I think this text has proven to be problematic enough in the past that it's better to take it out, I also read the whole text. It still talks about volume and persistence is not something to determine consensus on. So I think the text as it without the sentence is actually very good and clear. So

[01:14:37] **David Schinazi**: I'm gonna leave it to the chairs, but my gut feeling if if from standing here is that I'm hearing good arguments on both sides of this, which tells me that we do not have consensus to make the change, and I think our default mindset is to not make changes if we don't have consensus. Even if I I there there's a reason if I removed it from there in the first place. So that would be the failure mode of leave it as is or resolution mode rather.

[01:15:09] **Colin Perkins**: Yeah. I I mean, I I think we can make a strong argument that this text is incorrect. And, you know, if if if you wanna remove it, I think there is a strong argument because, you know, 99% of people can be saying, yes, approve the document. And one one person could be saying, no, this document is fatally flawed and has good technical reasons why it is fatally flawed. And that even if it's nine 99 out of a 100, doesn't mean it gets approved. So it's clearly you know, there's clearly cases where this text is wrong. So if you want a technical argument to remove it, we can do that.

[01:15:43] **David Schinazi**: So I agree with everything you just said, but I thought you wanted me to leave this back in and now you're telling me to take

[01:15:50] **Yari Arkko**: it out.

[01:15:50] **Colin Perkins**: I'm confused. I I I think this text is wrong. Right? I I think, you know, I I think I I'm making a procedural argument in terms of legitimacy of the process. But, yeah, I think this text is wrong.

[01:16:04] **David Schinazi**: So but if we all agree that it's wrong, should we take it out then? Yes? Alright. Then should we leave it out like it is right now? Goin, wine, screen twice. Alright. Next slide. Thank you very much.

[01:16:21] **Mirja Kühlewind**: Still in the queue apparently. I I really would like to have a correct document at the end. That's the goal, isn't it?

[01:16:27] **Eric Rescorla**: We all agreed. We all agreed. Alright.

[01:16:32] **David Schinazi**: Quit while you're ahead.

[01:16:33] **Colin Perkins**: But take it out because it's wrong, not because it's not tutorial change.

[01:16:36] **David Schinazi**: Yep. No. No. I was I will admit that I was absolutely wrong. I remembered it as being a for example clause, which it was not.

[01:16:43] **Leslie Daigle**: Okay. I'm just gonna pause for a minute. I don't like the fact that when a timer runs out, it disappears.

[01:16:50] **Lars Eggert**: It's to the speaker. Right?

[01:16:51] **David Schinazi**: Yeah. It covers the slides.

[01:16:53] **Mirja Kühlewind**: And and Oh.

[01:16:55] **Leslie Daigle**: Yeah. And and I appreciate that you have a few more issues to get through. So I'm gonna set a new timer for the rest of the wiggle room we have in the session.

[01:17:04] **Lars Eggert**: Got

[01:17:04] **David Schinazi**: it. Alright. I will pick up the pace. No.

[01:17:07] **Leslie Daigle**: It's it's I it's I'm saying it out loud because it says much to everybody that, you know, we should

[01:17:11] **David Schinazi**: mean, I if they all just agree with me, it'll go a lot faster.

[01:17:14] **Leslie Daigle**: And I think we're doing very well with the fact that that we don't all agree. So let's let's keep it going.

[01:17:21] **David Schinazi**: So speaking of not agreeing, so one of the elements that was explicitly in charter was discussing draft adoption by working groups. So I wrote some text last time about what it meant to adopt a draft, I phrased it in terms of handing over change control to the working group, and I was told by many people that was a terrible idea. So I tried something else. And, again, kinda try to distill in as few words as possible what it means and not adding any process, I landed on this small paragraph as the addition. And it just says, well, you can adopt a thing, and it just means that it's the basis for the for the for the work. Folks requested addition of a note that adoption does not indicate that the working group agrees with everything because I there's been a lot of confusion on that point. I've seen it in many working groups, so I think it makes sense to add this note. And the third bit is actually something that was slightly mentioned in the documents somewhere else, which is working group documents have editors, and their job is to document the consensus. So it kinda ties this all together. Lars?

[01:18:35] **Lars Eggert**: Lars, I heard. So I would avoid the word agrees here instead of talk about consensus. And, specifically, I would be stronger, and I would say that unless a consensus call has been issued, that there's no no statement can be made about the the like, I'm gonna use

[01:18:51] **Colin Perkins**: the word agreement now. Agreement of the group to

[01:18:53] **Lars Eggert**: the to the content. Because you remember in quick, we did a process where we actually did consensus calls on individual numbered versions of an inner draft, which we called the implementation drafts. And and, basically, for those drafts, we were able to say, you know, 17 has consensus. Everything in 17 has consensus. And then 18, we didn't do the call, and so we we didn't. And I think that would be helpful here. So maybe if you remove the the stuff in parentheses and put something at the end and say, I'm not gonna work with this.

[01:19:26] **David Schinazi**: No. We know. Yeah. I see what you're saying. What you're saying is that until there's been a working group last call or some other form of consensus call on the content, it has not gotten consensus. And an adoption call is not a consensus call on the content.

[01:19:41] **Lars Eggert**: Yeah. Content that hasn't been consensus called has no statement as to whether it has consensus in the group. And so, like, the example of a quicker, the text in 17 had consensus. The diff between seventeen and eighteen did not. But, obviously, the text that was unchanged from seventeen and eighteen still had consensus. Yes.

[01:20:00] **David Schinazi**: Alright. I agree with you that I'm not going to attempt to wordsmith this here, but I think the con do we agree on that concept that it's not just the adoption? It's that the the lack of consensus carries forward until you actually do a consensus call on the content, which is generally done in a Workgroup class call.

[01:20:19] **Leslie Daigle**: Correct. Think the fewer words you use, the better off you'll be. And the words that the words that I heard Lars say were that a a call for adoption is not a consensus call, period.

[01:20:29] **David Schinazi**: True. They that except we don't define what a consensus call is.

[01:20:33] **Mirja Kühlewind**: Yeah.

[01:20:34] **David Schinazi**: Because an adoption call is a consensus is a call

[01:20:37] **Yari Arkko**: of consensus on the adoption.

[01:20:38] **Leslie Daigle**: I'll stop trying to help. And and I'm and I'm going to observe there are two more issues and few more minutes.

[01:20:45] **Yari Arkko**: Yeah. So adoption and content are different things.

[01:20:49] **David Schinazi**: Yeah. I I think we all agree on what the concept is.

[01:20:53] **Colin Perkins**: Colin Burkins, I'll try to be brief. Agree adoption does not indicate everyone agrees. It is it worth also saying it doesn't commit to the working group to to keep working on it and eventually push this to publication. Because a group can adopt something and then say, we we don't want to proceed with this any further.

[01:21:15] **David Schinazi**: So I absolutely agree with you that that's a fact. I don't know if that fact needs to live in the document.

[01:21:22] **Lars Eggert**: Yeah. If if the inbound lives in the document, then I'll launch it too. Because otherwise

[01:21:27] **Mirja Kühlewind**: Oh, no. No. No.

[01:21:28] **Colin Perkins**: Over here doesn't say we can unadopt.

[01:21:30] **David Schinazi**: Oh, no. You're abs okay. What Lars said was that if you can adopt a document, you can also unadopt it, which I that's a good point. And I think that catches what you're going for.

[01:21:40] **Colin Perkins**: Yeah. I mean, I probably just say adoption does not indicate that working group agrees with everything in the documents and does not commit the working group to eventually progressing it.

[01:21:49] **David Schinazi**: Great. Thanks. Rich?

[01:21:57] **Rich Salz**: I'm not question or something to consider, when the working group adopts a document, you're also the authors are also granting rights to the IATF, and I'm not sure if it's elsewhere

[01:22:07] **David Schinazi**: That's incorrect.

[01:22:10] **Rich Salz**: They do it at the okay. Submission? Okay. Yep. You did better.

[01:22:14] **David Schinazi**: No. No. And and I had mentioned that in terms of change control, and I was Yeah. Explained to that I was wrong. John.

[01:22:25] **John Klensin**: I'm gonna call attention to last sentence and suggest that it, opens a can of worms with regard to the role of the editors in determining that consensus, which they have traditionally no role in at all, although they've been accused of it often. And I wonder if we even need that sentence.

[01:22:47] **David Schinazi**: That's fair. I think that part came from other parts of the document, which is but you're right. That doesn't add that confusion because they document the consensus they're working with best determined by the chairs, making that sentence longer does not help.

[01:23:02] **Lars Eggert**: So Replace consensus with outcomes of the deliberations. Oh.

[01:23:08] **Andrew Campling**: Alright. Great. Andrew? Yep. Andrew Capling. Without wordsmithing it, don't care how it's put specifically, but the things you've currently got in the brackets, it does need to say explicitly somewhere in here what those words are saying even if you phrase it differently because other that was quite contentious at some point in some of the discussions.

[01:23:33] **David Schinazi**: You know, keeping that concept in, but, like yeah. No. That's I I agree. Robert?

[01:23:44] **Yari Arkko**: I'm a try to do

[01:23:45] **Robert Sparks**: this very quickly. I'm sorry that I'm going to go in several different directions at once. Just try to hold on for the ride. I heard in this discussion a point that please keep in your mind as you're looking through the rest of this with considering this bit about the content of the document at adoption time not being a consensus product of the working group. There is a very related concept that I've seen many working groups have tension with with whether or not any version of a draft, like an editor working on a draft, if the editor has is creating an error if he puts something in the draft that doesn't already have working group consensus. So watch for opportunities to talk about that or not. And not trying to roll us all the way back to having an argument about the change control stuff. Again, I will just note that an individual an author can put an individual submission in that that offers no change control. A working group cannot adopt such a document. So that's the change control gate. I the IETF stream will not accept a document that does not give the IETF change control. That's the

[01:25:22] **David Schinazi**: I see what you're saying, but I don't think we should get into that level of nuance there because that's the giant can of worms. And

[01:25:28] **Robert Sparks**: I'm keeping it up. But there there was confusion in the mic line here. Yeah.

[01:25:36] **David Schinazi**: Alright. Thank you, everyone. I will give that another pass. Design teams, similarly, added some text last time, got told it was wrong, deleted most of it here. Now this is the only edition from 2418. Like, before we had text about IPR or about the per people in there, and this just we had resolved an issue where people were worried about, oh, could submarine patents and design team this, to me, was the shortest way we could state the obvious. I got through one. I got through one. Alright. Milestones. That one, the text the text got it was an editorial change from the text that we had last time. I removed the email address, isgsecretary@itf.org. I've never personally seen that used in a decade. And just the rest is kind of what we agreed on back in my individual draft that got kinda

[01:26:44] **Lars Eggert**: put in the charter. Last second, just wanna editorialize it. Enable or disable is a data tracker action, and you wanna talk about, like, choose to use or something like that instead. Great.

[01:26:56] **David Schinazi**: Will do. Thanks. And then yeah. This was just we've talked about this at in the charter discussion. It was in case we needed that. So I I did a review of the document to see what we changed,

[01:27:08] **Colin Perkins**: and that's not particularly interesting. Sorry. On the previous one, I just wasn't quick enough to get into the mic. Updates and milestones and the renegotiate with the area that's working group chairs can at least somewhat change milestones without approval. Right?

[01:27:24] **David Schinazi**: The and that is I think there might be another paragraph there. And, yes, that was the intent. 2418 didn't allow that, and that was one of the things, especially in our charter, to change. Yep. And that is the intent. I think that's covered by a different paragraph. I think that's it for me.

[01:27:47] **Leslie Daigle**: Alright. Thank you, David.

[01:27:50] **Yari Arkko**: And before we let Lars on stage, Rich, did you wanna say something?

[01:27:59] **Rich Salz**: Yeah. Thanks. I I made a few impolite rude comments talking about arrows in my back and muttering about somebody choking on words, and I wanna apologize for that in case anybody plays this transcript later on. Robert pointed it out to me. Wasn't worth the group. Wasn't worth me. I just, I'll claim, you know, being tired in Thursday, the IETF week. So thank you.

[01:28:25] **Yari Arkko**: Thank you, Rich. And then Lars.

[01:28:34] **Lars Eggert**: Hey, Lars Eggert. I'm too cool to make slides or too unorganized to take your pick. So so I had a document that talked about allowing the IETF chair the freedom to delegate various parts of the role. The it's not adopted by the working group. The feedback at the last meeting was to mostly see if I can split the two aspects that were rolled in this one document out. So there's now two documents. One document is the very simple definition of an emergency stand in for the ITF chair. The if I recall correctly, what the draft currently says is that the air director, when they get seated at the IETF chair, when they get seated and at any time of their choosing, appoints another willing area director as their stand in, and that is announced. And in case the I t f j becomes it used to say incapacitated and we changed the word. I don't know what we changed it to. It becomes unable to fulfill the role. The stand in will sort of temporarily take over. And I think there's no text based on a previous suggestion that says that if there's any controversial or important decisions that are being made during a temporary absence, maybe they can be postponed until the, quote, unquote, real ITF chair is back, something along those lines. But the the basic premise is that, you know, chair designates a stand in, announces it, and that's how that's handled, and they can change their mind about who to stand in this at any given time. So that's one document. The other document is the bigger one, which was the my little homework exercise of looking at all the existing process RFCs and what they say about what the ITF chair must do and then figuring out which of those things are tied to the role at the moment and which are not. And for those that are tied to the role, basically, say, the ITF chair can name somebody else as a as holding that role for them. And we had a discussion about if there's any inalienable, Is that a word? I think, basically, if there's any inherent parts of the role that that we want don't want the chair to delegate. And I at the moment, I went for maximum flexibility. So I basically went with the chair can decide to, you know, delegate the ISG chair role, delegate the I the gen area chair role, the the whatever. We probably wanna have a discussion if this gets adopted, what parts we consider core and which parts we consider delegatable. I know Edgar has some thoughts here that he shared. And the one other thing that came up, Mirja pointed out that the IAB membership of the chair is actually written in an IAB document that is also an ITF BCP. And so if we wanted to allow the ITF chair to delegate their IAB membership, the IAB would need to first agree with that, and then we would need to run a BCP on it. So so if we wanted to do that, that that would be the process. Apparently, the current IAB thinks that's just something that is you know, the the the the chair can already reduce their effort to the level that they think is suitable because there's already liaisons about directions. I I still prefer the option of delegation because, you know, somebody might say, it's part of the role and the chair doesn't do it. That's an appealable offense or but but we can have discussion. But, basically, these are both individual documents at the moment. My motivation for working on them is is quickly diminishing as long as they remain unadopted. That isn't to say that we need to adopt them. It just means if we decide that we don't want them, I'm happily stop working on them. And I think that's sort of my summary of where we are here.

[01:32:34] **Mirja Kühlewind**: I'm I think we should adopt it, and you did good work there. And the I think the change the difference of my understanding and your understanding is that I think you cannot really delegate a role. You can delegate some tasks or responsibilities in that role, but the role still sits with the chair, even if the chair isn't fulfilling the role, which, like, for me also means in the IAB case that the I that the chair the IETF chair always remains being the IAB member, but the chair can, of course, say, I don't wanna go there. You go and you do this or whatever. The so that's my difference of understanding. And, particularly, that means that I don't think it would be a good idea to transfer the voting, right, from the IETF chair to somebody else.

[01:33:17] **Lars Eggert**: So I think that's that's sort of the core because I I think it's not enough to just have, like, a stand in because, like, what about executive session or or voting, for example, on on the IB or ISG? Because if if if the chair would need to do that, they would need to participate at a level to let them, like, do do that. Right? And and the whole point is then you can't really delegate it if you're still, like, expected to be up to speed with things enough to be able to vote. And and and, you know, maybe this is a stupid idea, this whole delegation thing. Right? I'm I'm I can be convinced of that. But at least at the time I wrote this, I felt that there there were many things associated with the chair role that, you know, made it a a a full time position in in in a in a bit of bad situation for the org more than full time position. And I was thinking, can we, like, reduce the the load?

[01:34:13] **Mirja Kühlewind**: Yeah. I mean, particularly about the IAB. I think the IAB is always set up and particularly about voting, it's always set up such that it doesn't depend on a single person because other people might disappear. And it's like because the ISG, you have a specific role, you always have a certain responsibility, but it's different on the IAB. Right? I mean, having the IETF chair on the IAB, I think, is very useful, but it it there's no dependencies to it. So I don't feel like transferring the voting rights is the right thing to do. And but, like, executive sessions or whatever, they can still decide whatever they want. Right? So I don't see a real problem there. And I'm just saying, like, that might be a separation if you really want to transfer the role or if you transfer some responsibilities, and that's something we need to decide on.

[01:34:54] **Lars Eggert**: I mean, IAB, at least during my time as chair a few years ago, wasn't the the sinkhole of time. Right? But it has been in the past. Like, I can and Ayana transition and so on. Right? And so so

[01:35:08] **Colin Perkins**: it it at the moment, I feel at

[01:35:11] **Lars Eggert**: the moment, I feel like I I I don't think I don't think it's very important to be able to delegate the IAB membership. But there might be a time when it is because, you know, what if, you know, a an ITF working group and ICANN is on fire at the same time?

[01:35:26] **Mirja Kühlewind**: So but I always thought that it was a choice of the ITF chair to put the time in because they did occur. If they didn't, it wouldn't, like, break.

[01:35:34] **Lars Eggert**: Yeah. It's it's a choice, but it's expected by the community because the the documents say that the the I the iTEF chair is supposed to do this. And if you don't so so I personally would have not felt comfortable to basically say, I'm not showing up at the IV for two years Because I I and and, you know, I was also interested in what the IV is doing. But, basically, somebody the community could rightfully go to the plenary and say, you know, you haven't dialed into an IV telethernet in, like, two years. What's going on? You know, it's part of your job.

[01:36:04] **Leslie Daigle**: Yeah. So I think I've put myself in the queue to have some personal opinions. Largely, agree with Myriad that you can't delegate a role. You can delegate a function. I think that the the IAB gets to say that they want the IETF chair to be participant in its processes. And and I was gonna bring up the fact that, no, the the IETF chair is a is a voting is is an ex official position, but it's voting, if I recall correctly, as opposed to liaison, which is not. But then as chair, I wanted to point out it.

[01:36:39] **Lars Eggert**: I don't think it's ex official. It's a full member.

[01:36:41] **David Schinazi**: Just simply means.

[01:36:43] **Leslie Daigle**: Yes. Exactly.

[01:36:44] **Lars Eggert**: But there is an ex official, which is the IRTF chair,

[01:36:47] **Leslie Daigle**: which is No.

[01:36:47] **Yari Arkko**: No. No.

[01:36:48] **Leslie Daigle**: The IETF chair is is on the IAB by dint of being the IETF chair, which means they're ex official on anyway, the the bulk of this, I think, is good substance to talk through when we work on the working group as a working group on the document. I think it's I think it's I think it's a good existence proof. Sorry. David.

[01:37:12] **David Schinazi**: David Skenazi. I am the one who changed the IB voting rules was Myria when Myria was IB chair and Lars was IETF chair. We've had a lot of conversations about this. It was great. Oh, you changed it back?

[01:37:24] **Lars Eggert**: You can sit

[01:37:25] **Rich Salz**: down. I

[01:37:26] **Harald Alvestrand**: leave for two years.

[01:37:27] **David Schinazi**: Ugh. Alright. There's still time. I can put my name into the

[01:37:30] **Lars Eggert**: Don't don't get me started on on that topic.

[01:37:32] **David Schinazi**: Okay. What I actually got up to say is that, I think this topic is important. I think it is interesting. I would like us to adopt it. I disagree with a lot of the things that Miriam said, but I would like us to adopt it so I can have that conversation with Miriam because I don't think maybe today is the right time to have it.

[01:37:54] **Leslie Daigle**: I'll observe that it's actually part of our charter. So we will be having this discussion. And part of the question is, do we start from these documents? And if we don't say we wanna start from these documents, we have to figure out what we're starting from.

[01:38:09] **David Schinazi**: Then I think these documents are a good starting point. And as we just discussed, that doesn't mean we agree with everything that's in them. And I'm very happy to, like,

[01:38:19] **Lars Eggert**: not be the editor here too when this is a working group. And when I I I this is this sounds like a good opportunity for somebody else to take the pen.

[01:38:32] **Yari Arkko**: Well, yeah. Yeah. So last week, we're not letting you off the hook so easily. But so I came to the mic to say a few things. One is that I I agree that we should adopt both of the documents. They are important, and they are a good starting point. And I also don't agree with everything that's that's in them. I think I actually agree with with the stand in one more or less. There's probably more room for discussion on the other one. My experience with the IATF chair participating in the IAB is similar to what Miriam was explaining that the I IATF chair is not critical in in order for the IAB to do its stuff. One person can be missing, and that that's alright. And, yes, the liaisons and so on are not exact replacements. They help in some situations. The rest of the IAB members will pitch in in other circumstances. So I think that's fine. If the group's consensus here is that we, you know, we don't need that part to be delegated, then that that that's fine. So we should prepare for the possibility that your your 10 items of, you know, ITF chair tasks.

[01:39:45] **Lars Eggert**: Yeah.

[01:39:46] **Yari Arkko**: Some of them can be delegated and some of them cannot be. So I think that's one of

[01:39:50] **Lars Eggert**: the as I said, right, I went for the maximum, like, possibility.

[01:39:54] **Yari Arkko**: And and it's a good starting point because then we have a list and you have a, you know, description of what these things are, and then then we can decide this is in, that's out, and so on.

[01:40:04] **Leslie Daigle**: So while Elliot's coming up to the mic, I would like to do a show of hands on adoption. To do it formally, we, of course, would take it to the mailing list. But just as a heads up, I'm I'm gonna run a poll, Elliot. Unless you don't wanna run a poll. Yeah.

[01:40:21] **Lars Eggert**: You she said Elliot.

[01:40:22] **Eliot Lear**: Okay. Sorry. Thank you, and good afternoon. So two things. I was gonna actually say, I I I think I understand the the the stand in document well, and, I I certainly support that adoption. I'm a little less comfortable with adoption of the other. As a matter of history, from my perspective at least, the example was given about the Ianna transition. Most of the much of that was actually delegated. Alyssa took on a lot of work when she was not IETF chair. She she actually served as a representative over in ICANN and elsewhere, and I wrote a document, or edited the document. So Andrew, at the time, was pulled into various things by Fadi, which was his choice, really. Andrew's choice as chair. It wasn't a formal responsibility. So what I I I think the principle there to capture is things that we require the IAB chair and the IETF chair to do, and then realize this is just focusing on the I IETF chair, Things that we require them to do, we really ought to think about, you know, not not necessarily allowing the delegation when we think it's important. But it's important to also recognize that there are things that they can delegate that are not written as, you know, that very informal, but we need a, you know, we need a figurehead or whatever. That stuff absolutely can be delegated.

[01:42:04] **Lars Eggert**: Yeah. I

[01:42:05] **Leslie Daigle**: agree. But that sounds like it's substance of delegation issues, not should we adopt the documents as a starting point, reminding you that we have an have a charter item to produce a BCP on the topic.

[01:42:17] **Eliot Lear**: Right. I'm just saying I'm not sure that I'm not I if I go through the list, what I what I come up thinking is no. No. No.

[01:42:26] **Yari Arkko**: No to what to be

[01:42:27] **Eliot Lear**: To to, like, the delegate in terms of delegation on, you know Yeah.

[01:42:30] **Leslie Daigle**: But, again, that sounds like substance, not an issue with starting from this document.

[01:42:35] **Eliot Lear**: Right. The reason I said I'm not sure about it is I don't know if there's enough yes in there.

[01:42:39] **Lars Eggert**: Okay. So that's I mean, that would be basically arguing for a recharter to to drop that, which is a fine, like, stance to have. Right? And and it it might well be the consensus. Who knows? Right? The the I I do agree with you that there are obviously aspects that where the chair already has the freedom to have somebody else, like, be in the discussion. Right? The the point here was to list the ones that are that are, at least based on my read of the RFCs, are inherent with the chair role.

[01:43:06] **Colin Perkins**: I'm sorry. Leslie,

[01:43:08] **Eliot Lear**: could you please split the question between the two documents?

[01:43:12] **Leslie Daigle**: So I actually deliberately put both in because I wanna see if if there's general support for doing both of them, then we're done. And and I understand your question. But I think that to acquit our working group obligation, the spent these are the starting documents as we have them. Trying to see. We've got 29 participants, and we've got 13 14 answers so far. I think the chairs aren't maybe Ari's voting.

[01:43:51] **David Schinazi**: I'm not voting.

[01:43:52] **Yari Arkko**: I would like to.

[01:43:55] **Lars Eggert**: But, I mean, we we also just discussed that adopting something doesn't mean it it needs to stay adopted. Right? So Elliot's outcome is not precluded by this.

[01:44:03] **Leslie Daigle**: I'm in no way, Elliot, saying, I disagree with you or that we won't get there.

[01:44:09] **Harald Alvestrand**: K.

[01:44:09] **Lars Eggert**: Anybody wanna be a co editor?

[01:44:14] **David Schinazi**: Yes.

[01:44:16] **Yari Arkko**: I I think this is tentatively looking like this. This this this support for this in the in the room, and we'll go to the mailing list. Thanks.

[01:44:26] **Leslie Daigle**: Yeah. I think that's fair. I'm gonna give five second rule here if you are if you would like to vote in the room for three, two, one. Now we know how many people are sleeping. Thank you. So I agree with Yari. I think there's support in the room. We will take it to the mailing list and determine where from here. I did hear Lars ask if there was anyone interested in being a coeditor. I think it would be good if we can find a coeditor or two. So it would be delightful if somebody would like to volunteer now. But if not, we will take that to the mailing list as well.

[01:45:11] **David Schinazi**: Someone in the community who's not in the room right now.

[01:45:13] **Leslie Daigle**: Exactly. Okay.

[01:45:23] **David Schinazi**: But

[01:45:36] **Leslie Daigle**: at the same time at the same time, we we we never mind. Self edit. Anything else?

[01:45:49] **Yari Arkko**: No. I think we're wrapping up. And I guess the next steps, you will see some traffic on the list with with the charter text and that process going forward. You will see or hear from our editors on the documents. You will revise according to what we just discussed. We will start that option. Call also, and then we'll take that forward. And if anybody's interested in co editing those with Lars, then let us know. Lars? Yes. We will also work on the charter.

[01:46:30] **Leslie Daigle**: And you will see notes that look suspiciously like Eric's automated notes since I utterly fell down on responsibility of finding a note taker at the beginning of this session.

[01:46:41] **Yari Arkko**: Exactly.

[01:46:42] **Leslie Daigle**: That's that's that's what I said.

[01:46:44] **Lars Eggert**: AI agents out there. Alright. Yes.

[01:46:50] **Leslie Daigle**: Alright. Anyway, with that, thank you everybody for your contributions and participation today. I think we have made good progress. Thank you.

[01:47:33] **Lars Eggert**: You know, the