IETF Meeting Minutes

Session Date/Time: 19 Mar 2026 08:30

Shuping Peng: Okay, so it's time now. Let's start.

Hello, everyone. Welcome to GENDISPATCH. I'm one of the co-chairs, Shuping. Here together with me is my co-chair, Martin, and also we have also got our AD, Roman, online.

And please keep in mind this session is being recorded.

And this is the Note Well. I won't go into the details and so probably one thing I want to say is about the behaviors. Please be kind and be friendly. Okay.

And this is some meeting tips. If you want to join the queue, please use the on-site tool. We have got remote participants. Please mute yourself unless you are speaking. Please use the headset. And please clearly state your name before you are talking.

This is the resources.

Okay, so this session is a dispatch session. And so please let's focus on answering the dispatch question. Here we have got a few options. So about each topic:

Should we direct the work to the existing working group?
Shall we propose a new one?
Or recommend to have a BOF?
Or this draft can be directly published as AD sponsored, and assuming our AD is willing to do so?
And also any more discussions needed or development?
Or this work is not appropriate for IETF?

And for people who wants to comment, please clearly state about the suggestion you want to give for the dispatch outcome first. Okay.

Here is our agenda and we have got three topics. And since we have one and a half an hour and we give 20 minutes for each, and 10 minutes for presentation and 10 minutes for community to give feedback.

So, any comments on the agenda? Anybody wants to adjust the agenda?

No? Okay. So now we can start. Adrian, please.

Adrian Farrel: Hi, I'm Adrian Farrel. I appear to be starting early. I don't think I'm going to need the full 20 minutes, and that's going to give us more time to debate whether or not we should ever hold IETF meetings in Ruritania.

So, reminder where this draft is coming from. What's an Experimental RFC? I would very much hope we all know this. It describes a protocol experiment or a process experiment within the IETF. We're only concerned in this document with the protocol experiments.

And our contention is that an experiment is an experiment. It's not a protocol spec by the back door. So an experiment needs to be properly scoped, amongst other things: what is the point of the experiment, how will we know if it's a success or failure, when do we stop?

And authors do not generally do a good job of describing these pieces of of the discussion because working groups don't give good advice, because maybe even the IESG don't push back. So stuff happens really late in the process, and quite often RFCs come out which really aren't describing experiments so much as just a stake in the ground.

So what we think is that the authors would do a better job if there was some overall guidance that we could all agree on so that when they come to write an experimental draft, they know what material to include to make their document better, not to force them through hoops, but to get a document that is is more valuable for the purpose that they wrote it.

So this draft, as I say, only concerned about protocol experiments. There are roughly 10 of these a year coming out. We're principally guiding IETF documents. Sure, if the IRTF or the ISE want to pick this up, that's great. But our focus is IETF. And that's roughly 50 to 75% of those experimental RFCs every year.

It's guidance. It's not hard rules. It's not "you must do this," "you must not do that." And I would hope that the IESG don't push back on authors in a way that says they must do stuff. The intention is you will make a better RFC if you follow guidance. And the document gives some examples as well, pointers to documents, other documents with a bit of commentary on what worked well, what didn't work well.

So previously, we've come along with a list of eight possible dispatch outcomes ranging from, "oh, you must have a working group to work on this" right the way down to "go and take a swim in a lake." We came to GENDISPATCH at IETF 120. And the minutes say dispatch result: BOF mailing list, more discussion, then perhaps AD sponsored.

So what happened after after a bit of a hiatus was we got a mailing list, "experiment-guidance." And that's been used a little bit. Not a huge amount, but there's been some debate, some useful pointers for extra material in the draft. And some discussion, some more discussion on sort of how we might finally dispatch this work, where I summarize this as: no need for a BOF, either AD sponsored or informational RFC, or make an IETF wiki page to keep this kind of a living piece of guidance, or maybe just fold it into the IETF web pages amongst the advice for authors.

We've been chatting with our AD about this, and he's a kind of summary of of how we've progressed, which is not very much. So where's the draft? We've been revising it. We revise it every, well, certainly every cycle, but a bit better than that based on discussions, private conversations. We've been reaching out to authors of experimental documents as they go through the process and looking back at experimental RFCs. We could always do more work and we're happy to have that conversation.

But if this is going nowhere, if it's going to /dev/null, then it would be really good to know that and then we could just stop. Strangely, there are other things we could be doing. So what are we asking for? We would like this group to re-decide on dispatch advice. And then we can move on. And that may be "stop." It might be "publish and go away." It might be "put it on a wiki." We have no strong preference, but we would like to know and not be left dangling.

That's all I have to say and now let us talk.

Shuping Peng: Thank you Adrian. Barry please.

Barry Leiba: Barry Leiba. I like this. I think there's a need for this. I think the fact that you don't want it to be hard advice leads us not to having an RFC because I think that regardless of what we want, if it goes and becomes an RFC with any kind of status, there will be pushback that you didn't do this.

So I think the ideal place for this is in a wiki or similar thing where it's "here's advice to authors" and specifically "this is advice if you're doing an informational RFC—an informational document—that has the advantage of being easily updatable as we get other thoughts and that sort of thing as well. So that would be my preference.

Adrian Farrel: Before you walk away, Barry, do you have a feeling on the balance between wiki, which is sort of more generally editable as people spot new things that could be said, or IETF webpage, which is much more under control of the Secretariat and the IESG?

Barry Leiba: Yeah, I'm kind of torn. I don't really have a preference. Yeah, let other people figure that part out.

Shuping Peng: Jonathan.

Jonathan Lennox: Jonathan Lennox. Yeah. Um, I'm going to be maybe a little bit explosive. I mean, I think you haven't argued why this is the case, which is to say it is clearly the revealed preference of the IETF that experimental can mean "we don't have consensus this is a good idea." And I think that's fine. I think having experimental mean "this might be a good idea, but we're not sure," or maybe "nobody wants this," you know, "this isn't good enough for proposed standard." I think that's fine. So I would say, send this to /dev/null.

Adrian Farrel: Okay, thanks. Um, I would say that the the document at the moment attempts to explain that if things are going to experimental, it should not be simply because we haven't got consensus to publish a standard. And therefore, if it is an experiment, it should describe what the experiment is.

Jonathan Lennox: Why?

Adrian Farrel: Why? Well, um. Sorry, English is my native language and I kind of believe that the word "experimental" means "experimental." If you want to rebrand it, you know, I have also read Wittgenstein. If you want to rebrand it as "experimental means—"

Jonathan Lennox: I mean, it's not a request for comment either.

Adrian Farrel: Doesn't stop us commenting.

Shuping Peng: Eric.

Eric Rescorla: Yes. I roughly— someone needs to fix the echo. Okay. Are we better? No. (It works). I'm getting an enormous amount of echo on my— oh good, thank you. So I roughly agree with Jonathan here. What in practice experimental often means is "the experiment is: does anybody want this?" And if it does, then we promote it to, you know, RFC, to proposed standard. And if we don't, then we let it linger. And ironically, that is what has happened here, which is nobody seems to want this very much and it has lingered. And as with those other documents, people should get the message. And the message here is the same here, which is just going to /dev/null.

And just to be a little less— to be to be into details for a second, this document is actually full of like normative stuff. Um, so maybe you say it's not normative, but it's full of normative stuff. And I think that the main thesis of the document is simply wrong.

Adrian Farrel: Gotcha.

Shuping Peng: Rich.

Rich Salz: Yeah, hi. Rich Salz. Um, okay. Good. Um, I certainly empathize with the feelings expressed on the last two couple slides there. I think, however, there is a place for this, which is on the IETF pages where we discuss new work and bringing work to the IETF. Um, we can have some guidance about, well, if, you know, we have the tracks— or we should— and say, "and if you're looking to write an experimental thing, here are some things you may want to consider." So I think Ecker's right: tone down no 2119 language, but have it at the place where we talk about soliciting new work on the IETF web pages.

Shuping Peng: Colin.

Colin Perkins: Hi, Colin Perkins. Um, so I like this. I think it describes effectively how experimental RFCs should work. And I think if we are going to keep having experimental RFCs, we need some sort of guidance like this. So I would support it being published. Thank you.

Shuping Peng: Andrew.

Andrew Campling: Hi, Andrew Campling. Yes, broadly agree with what Colin just said. Maybe publish it as informational. I think would be helpful. But I think having some guidance is a good thing and not just using experimental as a sort of "well, we couldn't get consensus, but we're doing this thing anyway" and slipping it through a different channel. Thanks.

Shuping Peng: Roman.

Roman Danyliw: Afternoon, Adrian. So I want to make two statements. One as an AD and one kind of personally. So first, you summarized our interaction on this kind of correctly. I do apologize that I went dark on you. So to the community, that timeline is accurate. So with my AD hat on, the setup of this was: show interest on the mailing list that there's broad support for that, and that might motivate me to kind of AD sponsor. I have not seen evidence of that broad interest really wanting that. So that is why I've not taken a big step to kind of push this forward to make that investment.

I think from my perspective, I think the course of action here is going to be kind of one of two things. I agree with you on this idea that experiments are kind of under-specified. There's late-stage surprise. The IESG kind of gets that. What I don't understand, and why personally I have a challenge here, is that this doesn't change the state of affairs. This doesn't bind a working group to do anything with experimental status documents. This doesn't give the IESG the ability to kind of change the state of play because, again, while it's BCP, it doesn't require anything. So in the big scheme of things, I'm not sure how this shifts anything. If we wanted to change what experimental status means, we can absolutely do that. And to me, that would be a PROCON activity.

Shuping Peng: Pete.

Pete Resnick: I'm going to try switching hats here. So no hat on first. Um, I would really prefer this to be BCP and I would really prefer it to strictly limit what kinds of documents the IESG would let through. I don't think it's going to get consensus.

I would be okay if the IESG came out with an IESG statement and said, "we're not going to pass through experimental documents—no one is going to sponsor one—sorry, if they do not meet this particular form." I think that would be okay, too. I don't think any IESG I have been on has had a sufficient number of people who agree with this who are willing to do it. I think it's the right thing to do. I don't think people will do it. Um, you know, the problem with Ecker's position is that it just increases the workload on the IESG, and the IESG seems incapable of lowering its own workload. It doesn't like doing it ever.

If you want to try and redefine what an experimental document is, however, switching hats, I don't think this is a PROCON thing. I think this is probably an RSWG thing because streams other than the IETF stream use experimental, the IRTF in particular. And I think you're going to have to have cross-stream buy-in to redefine what experimental means. So that all stinks. I mean, I really like this document. I understand that what motivated Ron to a certain extent was the harmless-but-useless repetitive thing that our IESG got into. I wish we could fix it. I'm not convinced we can, at least in this form.

Shuping Peng: Roman, you want to comment?

Roman Danyliw: Yeah, I got back in the queue largely to respond to the two points that Pete was making. I think the IESG cannot release a statement on this. RFC 2026 provides significant latitude on experimental status documents and the IESG deciding that it's a lot narrower than it's allowed by 2026 with a statement, I think would be highly appealable and I would not be supportive of the IESG for us to issue such a statement.

Two, on the idea that this is a cross-stream issue. I mean, subject to community discussion, but while other streams could certainly use the experimental status, the IETF stream can decide on how it interprets that status for itself by changing 2026. So it wouldn't need to be a cross-stream activity in my opinion.

Shuping Peng: Lars.

Lars Eggert: Hi, Lars Eggert. So I think I actively don't see the need for this, or I actually think we shouldn't be doing this. And the reason is that a) we're not publishing hundreds of them, we're publishing a small number, as you said, right? And it has been useful to have ambiguity about what experimental means. It's a feature that gets us out of a pickle. And if we over-standardize on it, right, we lose that flexibility and that means we're going to have a lot more discussions about things. It's a kind of similar safety valve than the independent stream, just within the IETF context. So unless there's some huge issues with experimental RFCs that we haven't had for the last 40 years, or maybe we now have, I don't see the value in pursuing this. I think it's actually going to constrain us. Thanks.

Shuping Peng: Stephen, please.

Stephen Farrell: Hi. I guess I just postpose Lars. I think while this is worthy, I think if that text turned into an RFC, it would become a blocker to various pieces of work. So I think this is better not done.

Shuping Peng: Colin.

Colin Perkins: Hi. Colin Perkins. I think responding to Pete, I would strongly argue that the types of experiments that a research group might do are, or at least should be, different to the types of experiments a working group might be doing. And so that we would need to do this differently for the IETF and the IRTF streams and it shouldn't be something the RSWG should take up. Thank you.

Shuping Peng: Ketan, please.

Ketan Talaulikar: Hi, thanks. No hats here. As Roman mentioned, 2026 does not restrict experimental to only documenting experiments. It leaves things open. Several working groups and different areas have been going about experimental in different ways. In routing, we have had a working group which was chartered to only do experimental and they were all protocol specs. We have another working group that is still doing experimental, and as they mature, get more deployment experience, they are turned into standards track. Sometimes it is because there is not enough operational experience. There are n number of reasons. And I think we should allow the community, the working group, to have this flexibility. And of course, all of this passes through working group last call and IETF last call which provides the community the ability to speak up if there are— something is being misused or abused.

So my thing is, document it as a wiki, more like an instruction. Some of the things are really good, like whether this can be done over the internet or is it within a certain domain? Some of these things are really good but better on a wiki.

Shuping Peng: Martin.

Martin Duke: Martin Duke, Google. This maybe overlaps a little bit with what Ketan said, but in the particular case of CCWG, RFC 5743, which sets out standards for congestion control documents, talks a lot about what are the thresholds for a congestion control RFC to be experimental versus proposed standard. So I don't know if there are other examples of this across the IETF, but I think if we were to produce a document in this space, there would be a risk of some collision with whatever else has come out organically out of working groups. Thanks.

Adrian Farrel: Okay, that looks like an empty queue. I think I hear "take your windmill away and leave us in peace."

Shuping Peng: So to summarize, I think we have like three opinions here. One is informational drafts, and to create a wiki web page, or we stop this work. So, maybe we can take this to the mailing list and more discussion? How do you think?

Adrian Farrel: Yeah, so from the authors' point of view, if people want to build a wiki or a webpage, the material is there in a draft, they can use it. But I think the authors will no longer update this document.

Shuping Peng: Okay, thank you Adrian.

Shuping Peng: Brian, please.

Brian Carpenter: Okay, thank you. And I'm Brian and this is about anachronisms in the IETF process documents. Actually, not all the things I've identified are strictly speaking anachronisms, but it's a word you don't often see in the titles of drafts, so I thought it was a good one.

So the problem statement behind this draft is fairly simple. The PROCON working group is chartered to revise our principal process RFCs by incorporating approved updates and errata and in a few cases alignment with reality when we're actually doing something a little bit different. And there are some other specific items in the charter of PROCON. But this will leave a large number of anachronisms in the many, many IETF process documents untouched. And the question before the house is whether we care about that.

So I don't want to go into details of each item because otherwise we'd be here all night. But here are some examples of what I'm talking about. Firstly, internet drafts do not actually expire, although their front page says they do. They simply go into the archive. Secondly, if you actually read the rule about citing IDs as work in progress, there is at least one sentence in the rule that makes no sense. Now that particular thing may get fixed by the PROCON documents anyway, but it's the sort of thing that's concerning me. The third example here is that viewed from any reasonable distance, the process for raising a document to internet standard is so similar to the process for approving a proposed standard that there is almost no practical difference. Again, we could go into a lot of detail about that, but just accept my assertion for the moment.

Another three examples: the current practice about the number of BOFs allowed on the same topic is inconsistent with the rules. Again, it's possible PROCON will sort that out, but it might also be something that people thought was outside charter for PROCON. The current practice about AD sponsoring non-working group drafts is not properly described in the rules. We noticed recently that the question "what is the IETF?" is answered differently in two different BCPs. And one that came up sometime this week was noticing that nowhere in our rules is there any clause which an insurance company would call the Force Majeure clause, which says that when something happens that's utterly outside our control, we can break our own rules. And of course we did that during COVID because we had to, but it was completely outside the rules. And I have no doubt that there are others which if we had a discussion on this would crop up and which would not, according to the PROCON charter, be fixed by the current updates to the two basic process documents.

So that's my problem statement, and I have three questions to this meeting. Do we care? Is there energy to do anything about it? And if the answer to both those questions is yes, one option would be to extend the PROCON charter, obviously after its current work is done, in order to fix these issues. And you know there's places you can go to look for lists of all the process documents if you want to discover for yourself other little inconsistencies between the documents and what we do. So those are my three questions, and that's all I have to say.

Shuping Peng: Thank you Brian. I lost my connect here. People, you can see your queue, please start. John.

John Klensin: Yeah, I think this is work worthy of discussion. I don't know if PROCON is the right place to have that discussion as distinct from fixing things after its work is finished and we decide what we want to do. I do think we care, or should, even if we don't. I have doubts about the energy on some of the topics but not others. And my reading of Brian's list is that different interpretations of that list could take us in multiple different directions. And again, that's justification for discussion. In particular, the description of the process for approving proposed versus internet standards is probably correct, but the language we use to describe all over the place the difference between the two is actually still quite different. And that's another thing. I'm not trying to debate the issues, I'm just trying to point out that a round of refinement on this list is probably in order someplace.

Shuping Peng: Thank you John. Leslie.

Leslie Daigle: Leslie Daigle, co-chair of the PROCON working group. Um, I think these are all important to discuss and largely I agree with what John Klensin had to say. Um, I do not think that the PROCON charter should be extended. We had the discussion in July at the July meeting about we're going to focus on the things that are editorial and cleanup issues in the drafts now. After that's done, one can consider extending the charter of PROCON. Doing it now would be a mess. So I think in any case it would be helpful to get one set of documents that describe current reality settled before talking about the issues that remain, because I agree there will be many, many issues that remain.

Brian Carpenter: Yeah, I spoke carelessly. I completely agree with you Leslie. My implication is "should the PROCON charter be extended later?"

Shuping Peng: Roman.

Roman Danyliw: Hello everyone. I got in line wearing my AD hat to repeat what largely Leslie said and to reiterate what I've previously said to the community. I believe I said this to John when we were chartering and at least a few times in PROCON, which is: largely what you're presenting here, Brian, is absolutely a number of rough edges in our documents. This is great. It's a great start to a list. I know PROCON has a number of things as you know in GitHub of other kind of sharp edges which are not in charter. These to me are very cross-cutting and to do anything to as kind of AD sponsored or in any other way I think would be problematic. We want a working group. As Leslie said, all of these are currently out of scope because the project management approach was: let's document reality first. So if you're collecting a list of things we could work on in the future, I absolutely think that PROCON could be re-chartered. I think we promised to re-charter PROCON for some of the rough edges we've already found. I see no reason why we couldn't put these on the list, if they're not already on the list, for future work. But it would require us to first finish the current work items. So again, thanks for making the list. That's great. I think this could be a PROCON re-charter to do that.

Shuping Peng: Eric.

Eric Rescorla: Hi Brian. As I said on the list, I think this is a great list of things that are messed up that we should attempt to fix. You know, we've survived this long, you know, within this way, so probably we can survive until PROCON, you know, finishes its first round of things, though I also wouldn't object to forming a new working group called like PROFIX to do it right now. It's probably a little easier to do that once PROCON completes the so I think, as I said, we survived this long, so I think we could make it a little longer. Um, but I do think it's important we do these things. Some of these things actually are legitimate problems that are not just sort of like, "oh, it's textual and annoying," but actually like, you know, but is causing real problems.

Shuping Peng: Colin.

Colin Perkins: Hi, Colin Perkins. So I don't agree that these are all problems, but I certainly agree that these are all things which are worth discussing. And I think some of the recent issues we have had demonstrates that it is important that we fix our process documents. So do we care? I certainly think we ought to. Do we have energy? I don't know. Should it go to PROCON? Yes, but only once the existing work is finished. Thank you.

Shuping Peng: Rich Salz.

Rich Salz: Yeah, hi. Rich Salz. Um, yeah. I think we seem to be pretty unanimous in that it should go to something like PROCON after the current drafts are done. My concern is that we don't want to re-open everything, the whole process, and come up with, you know, internet standards process v4. We really want, you know, v3 plus some fixes or clarifications. So the charter and discussion area should probably be constrained. That might mean a different working group, whether it ends up being PROFIX as Ecker said, that's fine, but I'm just concerned about that we don't open the whole can of worms up. We just want to fix the things that are still wrong. But I'm in favor of making a working group or re-chartering PROCON once we're done with the first round of stuff.

Shuping Peng: John.

John Klensin: Let me make a quick suggestion which is not on Brian's list. Um, would it make sense to recommend a BOF at our next meeting, not with the usual purpose for BOFs, but with the purpose of having an open discussion and refining this list to the point that we could figure out which of these items might belong in PROCON-bis or which of these items might belong in, for example, Newtrack-bis, which is to say almost indistinguishable from /dev/null but not quite. Just a thought.

Brian Carpenter: I'll mention that we do have a hold for future work topic in the GitHub thing, so we can open issues and record them there in PROCON for each of the 2026 and 2048—2418 drafts. So we can have that discussion and a place to record things. I think Brian's omnibus needs to be obviously broken down into finer grain.

John Klensin: The disadvantage of that is I was hoping to draw potentially a somewhat broader or at least different audience from the audience which is working on the PROCON documents currently under the current PROCON charter. But maybe that's too fine a point.

Brian Carpenter: Yeah, and you know, I don't know if we'd actually need a BOF or whether we can achieve the same thing, you know, with this old-fashioned thing called email or this modern thing called GitHub. But I think you're right, it's not something that we should be out of our minds even if it's on the back burner until PROCON has done its work.

Shuping Peng: Okay, so I think we're in agreement.

Brian Carpenter: Yeah, it takes some time. So I think John's suggestion to spend some time working on setting a scope for this thing is I think good, but I think I'll probably push back on a complete re-architecture of the process at this stage. I think what we've done in the current PROCON work is very small editorial fixes just to deal with the fact that time has moved on. What Brian is suggesting here is a series of smaller fixes which I think modernize the process and sort of probably I would say align what the documents say with what we do more than anything else. And I would suggest a requirements gathering phase that looks at things in that vein as the next phase of things to do. And any major re-architecting in the sense of newtrack or any of those sorts of things may be things to be deferred to the phase after that rather than sort of try to to open the patient fully. Try to patch the wounds first.

Shuping Peng: Okay, so we have cleared the queue. And Brian, do you have any responses?

Brian Carpenter: Well, you know, I think what was said is much like what's in my head. So I think I'll keep the draft alive and I'll have a look to see if the existing PROCON issues list is the right place to keep a memo of all these things. And I think, you know, if people care to discuss the draft informally, you know, we can regard that as preparation for the next stage when PROCON has finished its current job.

Shuping Peng: Yes, and to record the issues in the GitHub and make sure everything is recorded.

Brian Carpenter: Exactly.

Shuping Peng: Okay. So we move to the next. Martin, can you take over? My computer still is not working. Martin.

Martin Duke: Yes. Give me a sec. Theoretically I've pressed the request slides button. More than theoretically I've pressed it. There we go.

Roman Danyliw: To the chairs, I granted it since I also have permission since we're swapping between many laptops and I'm online.

Shuping Peng: Yeah, that's good. Thank you.

Martin Duke: Okay. Thank you. Fantastic. So this draft was inspired by the current situation, namely that we had some very new and I think not fantastic requirements announced for how the IETF network should be performed at the very last minute due to regulatory changes. Those requirements have I think a substantially negative impact on user privacy. And while it's true that, you know, the privacy of open IP networks has never been fantastic, having everybody's identity recorded and matched to their IP address and shared with the authorities or at least the upstream carrier with the intention of being shared with the authorities who then also have a separate map of where every IP address goes on the internet due to a border monitor has really quite negative impacts on privacy.

However, this is actually perfectly consistent with the venue requirements document that we presently have, which does not say anything in this area. So the four of us sat down sort of motivated by this and said, well, you know, what requirement should be in for the IETF network. And I think that the general thesis is that consistent with RFC 7258, you know, we ought to be attempting to have the network consistent with the privacy technologies and the security technologies that we are attempting to deploy number one, and that light actually not act to negatively impact user privacy number two.

So this basically adds two new requirements to the venue requirements selection. The first is the one I just indicated, namely that, you know, we're developing a bunch of privacy technologies, things like mask, ECH, you know, DNSSEC etc., and that the network must actually be compatible with them and not block them, screw them up, etc. So that's the first new requirement.

And the second new requirement is that the information that is gathered by the network— so I think that's pretty straightforward. Second new requirement is the information that's gathered by the network must be minimal and must not include people's direct identities. So I think this is designed, you know, in really two parts. The first is like data minimization, namely we shouldn't be collecting a lot of information and when we do it shouldn't be disseminated beyond the very narrow operational needs and must be deleted. And then the second point is that is specific: it must not be allowed to collect the user identity and associate it with their network identity at all.

I think this, you know, this does allow— I think the thing that happened in Bangkok or— the last China where there was, you know, a bunch of like codes in a in a pot you could pick up, but like it doesn't allow the collection of the identity directly associated with registration.

One question that came up on— Brun, do you want to cut in now or are you just getting in line for the future? Okay, I'll assume future. One thing—

Brun: I just had to make a move to the— oh please, yes. I basically spent the entire week on VPN connections. So in theory, this network only knows that I spent the time on VPN connections. I don't know whether that's something we need to take into account in there as well, whether allowing you to VPN out to somewhere else and hide from the network has any value or whether it's a consideration.

Martin Duke: Right, that was intended to be the first— the first slide here was intended to capture that you had to be allowed to do that. However, I do not think it's reasonable to insist people do that. That does not provide the privacy properties that we're attempting to capture here.

Speaker 1: Yeah, I just want to second what Eric just said. Like, I think the requirement here is that you be able to use your VPNs. That's part of the security that you expect to get your work done. We should not require that— the VPN— that people can use a VPN is not a substitute for having secure and open access.

Eric Rescorla: Oh, Martin, please.

Martin Duke: Martin Duke, Google. Um, maybe try say this then, and then we can do it? Or do you want to do it?

Eric Rescorla: Yeah, go ahead.

Martin Duke: Yeah. So the topic came up on discussion about like this was obviously a last minute change and so even if we had this requirement it would not have actually been impactful for this IETF. That is a true— that is true and nevertheless is a generic problem. There are lots of things that can change the last minute, for instance visa requirements change the last minute. So I think we probably need a separate draft that describes what happens when, you know, a venue requirement that was a mandatory venue requirement is no longer complied to, complied with, but like too— but like after the venue is selected. I've been working on such a draft but it's not quite baked yet so I'd be happy to chat with people about that. But I think that should be separate from here because it's not a requirement that's about this.

Eric Rescorla: Okay, I'll talk now. So we actually have an RFC about late-breaking changes that we published a few years ago post-COVID, when we found that because of late— like because of war happens or something, that or there's an earthquake or whatever, that a venue's no longer viable. So essentially the IESG and LLC can decide to just cancel the meeting or postpone it or move it online or whatever, which is of course what we did in COVID. And I think if this becomes a hard and fast requirement for a meeting and late-breaking changes cause us to no longer meet those requirements, then that process would sort of automatically be invoked. In my interpretation of this would automatically be invoked and the LLC and IESG would have a number of options on what to do rather than have the meeting in its venue.

Martin Duke: I was unaware of that RFC. I think that would be a desirable outcome, however.

Eric Rescorla: Okay, super. Thanks.

Martin Duke: Andrew.

Andrew Campling: Yeah, sorry. Um, I think the issue here is we're contracting with a hotel or conference venue, not with a government. I think the musts in this are a bit pointless because the venue doesn't have any control over these things. And also I just question why we think we're so special that we need this. As was said at the mic, most people will use VPNs anyway. So I'm not convinced this is solving a worthwhile problem. And also, you know, we're contracting with the wrong party that would have power to adhere to this anyway, so it would be pointless to put it as a contractual requirement. Thanks.

Martin Duke: I'm not intending to be a contractual requirement, by the way. I'm intending it to be a selection requirement. And so you would look at the regulatory situation at the moment, and if you couldn't comply with this then you would not pick that venue. Just as if the just as if the visa requirements, for instance, forbid people from a large number of jurisdictions from entering the country.

Andrew Campling: I mean, to take it to its extreme, some of the things that you specified as musts would rule out most countries. Many countries do block access to some services, some sites. I used the soft example of CSAM, there would be other things. But I think if we said—

Martin Duke: That's— well, that's actually not— if you're reading the text that way, I think it needs adjustment because that's not what this text is intended to say. It's intended to say security technologies. There actually are separate requirements about accessibility that Jay's been discussing privately. But this— none of this text would require you to not block any particular content site. It would require you to not block like VPN sites.

Andrew Campling: Okay. Well, I read the text differently, so maybe that's just—

Martin Duke: Thank you for that comment. I'll see what I can do to fix it.

Andrew Campling: Okay.

Shuping Peng: So Eric, do you want to finish?

Eric Rescorla: Oh sure. Yeah. The chairs are in charge. Um, so like next steps. I think this is too small for a working group. Maybe people disagree. If there's no support, obviously we can do nothing in consistent with my previous thesis. Um, if there is support, I think we could refine the text a little bit on this list and eventually AD sponsorship. I'm like willing to do a working group if you want, but I just think it's kind of silly.

Shuping Peng: Okay, thank you Eric. I see a lot of discussions here, and let's focus on dispatching.

Eric Rescorla: Yeah, I forgot to remove myself from the queue, but just to follow up, it is RFC 9137 that covers the cancellation. I think it dovetails nicely with this. I don't have a strong— I would like to see this work progress. I don't know what the right venue is. Thanks.

Shuping Peng: Thank you. Stephen.

Stephen Farrell: Hi. So I also like this work. I think AD sponsorship after some discussion on some mailing list would be good. As to the question of this being us claiming that we're special, I don't think that's actually valid. I think what this is aiming to do is something that we think should be normal for networks including ours. So I don't think this is us trying to privilege ourselves. It's us trying to say how we think networks should generally be operated. And I think that's good. So AD sponsorship would be my favorite as an idea. Small working group if necessary, but hopefully not.

Shuping Peng: Jean.

Jean-Philippe Vasseur: So following what was just being said, I think the main core of the issue here is whether the IETF wants to subscribe to a number of principles and stick to them whereas that may or may not have impact say in the venues that we are going to be having. And I'm not specifically leaning to any direction at the moment because I'm not 100% sure that I can evaluate the consequences of that. I'm just feeling that it's a principles problem. When it comes to the VPN side— so on the principles what I mean to say is that it would be good of those who are going to be positioning themselves think about whether we want to still defend an open internet no matter what, regardless of the consequences for the venues, or we want to bend to the sovereign decisions of countries and just play along and decide. Now when it comes to the VPNs, my personal experience is that it has been quite different depending on which network I was connecting myself. So when it comes to the IETF, my VPN worked very well. When I connect to the Wi-Fi on my hotel, which is not the venue, it does not work at all. And because I have a SIM card that I purchased abroad, it would appear that even if it is a local operator, my VPN does work. And so I don't know if those requirements as to say that the VPN has to apply or work would also have to be specific to the IETF network because otherwise they may not work big time in the host. So it's well very well known that China bans most VPNs and it's kind of a race to figure out which one is going to work next month. Um, so I don't think it's just that the fact that the VPN has to work in the country, but the fact that it will have to work in the IETF network, which may be against regulatory applicable regulations in the country.

Martin Duke: Just to clarify, the sense of this text is supposed to be— is supposed to be that it works in the IETF network. You know, there could be no internet in the country as far as this draft is concerned, though of course that would not be a desirable place to thin generally.

Shuping Peng: Martin.

Martin Duke: Martin Duke, Google. Um, this may overlap a little bit with what Ketan said, but in particular case of CCWG, RFC 9743, which sets out standards for congestion control documents, talks a lot about what are the thresholds for a congestion control RFC to be experimental versus proposed standard. So I don't know if there are other examples of this across the IETF, but I think if we were to produce a document in this space, there would be a risk of some collision with whatever else has come out organically out of working groups. Thanks.

Shuping Peng: Okay, thank you Adrian. I think we have cleared the queue. And Brian, do you have any responses?

Shuping Peng: Yes, and to record the issues in the GitHub and make sure everything is recorded.

Brian Carpenter: Exactly.

Shuping Peng: Okay. So we move to the next. Martin, can you take over? My computer still is not working. Martin.

Martin Duke: Yes. Give me a sec. Theoretically I've pressed the request slides button. More than theoretically I've pressed it. There we go.

Roman Danyliw: To the chairs, I granted it since I also have permission since we're swapping between many laptops and I'm online.

Shuping Peng: Yeah, that's good. Thank you.

One question that came up on— Brun, do you want to cut in now or are you just getting in line for the future? Okay, I'll assume future. One thing—

Eric Rescorla: Oh, Martin, please.

Martin Duke: Martin Duke, Google. Um, maybe try say this then, and then we can do it? Or do you want to do it?

Eric Rescorla: Yeah, go ahead.

Martin Duke: I was unaware of that RFC. I think that would be a desirable outcome, however.

Eric Rescorla: Okay, super. Thanks.

Martin Duke: Andrew.

Andrew Campling: Okay. Well, I read the text differently, so maybe that's just—

Martin Duke: Thank you for that comment. I'll see what I can do to fix it.

Andrew Campling: Okay.

Shuping Peng: So Eric, do you want to finish?

Shuping Peng: Okay, thank you Eric. I see a lot of discussions here, and let's focus on dispatching.

Shuping Peng: Thank you. Stephen.

Shuping Peng: Jean.

Shuping Peng: Martin.

Shuping Peng: Okay, thank you Adrian. I think we have cleared the queue. And Brian, do you have any responses?

Shuping Peng: Yes, and to record the issues in the GitHub and make sure everything is recorded.

Brian Carpenter: Exactly.

Shuping Peng: Okay. So we move to the next. Martin, can you take over? My computer still is not working. Martin.

Martin Duke: Yes. Give me a sec. Theoretically I've pressed the request slides button. More than theoretically I've pressed it. There we go.

Roman Danyliw: To the chairs, I granted it since I also have permission since we're swapping between many laptops and I'm online.

Shuping Peng: Yeah, that's good. Thank you.

One question that came up on— Brun, do you want to cut in now or are you just getting in line for the future? Okay, I'll assume future. One thing—

Eric Rescorla: Oh, Martin, please.

Martin Duke: Martin Duke, Google. Um, maybe try say this then, and then we can do it? Or do you want to do it?

Eric Rescorla: Yeah, go ahead.

Martin Duke: I was unaware of that RFC. I think that would be a desirable outcome, however.

Eric Rescorla: Okay, super. Thanks.

Martin Duke: Andrew.

Andrew Campling: Okay. Well, I read the text differently, so maybe that's just—

Martin Duke: Thank you for that comment. I'll see what I can do to fix it.

Andrew Campling: Okay.

Shuping Peng: So Eric, do you want to finish?

Shuping Peng: Okay, thank you Eric. I see a lot of discussions here, and let's focus on dispatching.

Shuping Peng: Thank you. Stephen.

Shuping Peng: Jean.

Shuping Peng: Martin.

Shuping Peng: Okay, thank you Adrian. I think we have cleared the queue. And Brian, do you have any responses?

Shuping Peng: Yes, and to record the issues in the GitHub and make sure everything is recorded.

Brian Carpenter: Exactly.

Shuping Peng: Okay. So we move to the next. Martin, can you take over? My computer still is not working. Martin.

Martin Duke: Yes. Give me a sec. Theoretically I've pressed the request slides button. More than theoretically I've pressed it. There we go.

Roman Danyliw: To the chairs, I granted it since I also have permission since we're swapping between many laptops and I'm online.

Shuping Peng: Yeah, that's good. Thank you.

One question that came up on— Brun, do you want to cut in now or are you just getting in line for the future? Okay, I'll assume future. One thing—

Eric Rescorla: Oh, Martin, please.

Martin Duke: Martin Duke, Google. Um, maybe try say this then, and then we can do it? Or do you want to do it?

Eric Rescorla: Yeah, go ahead.

Martin Duke: I was unaware of that RFC. I think that would be a desirable outcome, however.

Eric Rescorla: Okay, super. Thanks.

Martin Duke: Andrew.

Andrew Campling: Okay. Well, I read the text differently, so maybe that's just—

Martin Duke: Thank you for that comment. I'll see what I can do to fix it.

Andrew Campling: Okay.

Shuping Peng: So Eric, do you want to finish?

Eric Rescorla: Oh sure. Yeah. The chairs are in charge. Um, so like next steps. I think this is too small for a working group. Maybe people disagree. If there is no support, obviously we can do nothing in consistent with my previous thesis. Um, if there is support, I think we could refine the text a little bit on this list and eventually AD sponsorship. I'm like willing to do a working group if you want, but I just think it's kind of silly.

Shuping Peng: Okay, thank you Eric. I see a lot of discussions here, and let's focus on dispatching.

Shuping Peng: Thank you. Stephen.

Shuping Peng: Jean.

Shuping Peng: Martin.

Shuping Peng: Okay, thank you Adrian. I think we have cleared the queue. And Brian, do you have any responses?

Shuping Peng: Yes, and to record the issues in the GitHub and make sure everything is recorded.

Brian Carpenter: Exactly.

Shuping Peng: Okay. So we move to the next. Martin, can you take over? My computer still is not working. Martin.

Martin Duke: Yes. Give me a sec. Theoretically I've pressed the request slides button. More than theoretically I've pressed it. There we go.

Roman Danyliw: To the chairs, I granted it since I also have permission since we're swapping between many laptops and I'm online.

Shuping Peng: Yeah, that's good. Thank you.

One question that came up on— Brun, do you want to cut in now or are you just getting in line for the future? Okay, I'll assume future. One thing—

Brun: I just had to make a move to the— oh please, yes. I basically spent the entire week on VPN connections. So in theory, this network only knows that I spent the time on VPN connections. I don't know whetherthat's something we need to take into account in there as well, whether allowing you to VPN out to somewhere else and hide from the network has any value or whether it's a consideration.

Martin Duke: Right. That was intended to be the first— the first slide here was intended to capture that you had to be allowed to do that. However, I do not think it's reasonable to insist people do that. That does not provide the privacy properties that we're attempting to capture here.

Tommy Pauly: Yeah, I just want to second what Eric just said. Like, I think the requirement here is that you be able to use your VPNs. That's part of the security that you expect to get your work done. We should not require that— the fact that people can use a VPN is not a substitute for having secure and open and anonymous access.

Martin Duke: Oh, Martin, please.

Martin Duke: Martin Duke, Google. Um, well, actually I want to talk about late-breaking changes. So I'm— maybe try say this then, and then we can do it? Or do you want to do it?

Eric Rescorla: Yeah, go ahead.

Martin Duke: Yeah. So the topic came up on discussion about like this was obviously a last minute change and so even if we had this requirement it would not have actually been impactful for this IETF. That is a true— that is true and nevertheless is a generic problem. There are lots of things that can change at the last minute, for instance visa requirements change at the last minute. So I think we probably need a separate draft that describes what happens when, you know, a venue requirement that was a mandatory venue requirement is no longer complied to— complied with, but like too— but like after the venue's selected. I've been working on such a draft but it's not quite baked yet, so I'd be happy to chat with people about that. But I think that should be separate from here because it's not a requirement that's about this.

Eric Rescorla: Okay, I'll talk now. So we actually have an RFC about late-breaking changes, um, that we published a few years ago post-COVID, um, when we found that because of late— like because of war happens or something, that or there's an earthquake or whatever, that a venue's no longer viable. So essentially the IESG and LLC can decide to just cancel the meeting or postpone it or move it online or whatever, which is of course what we did in COVID. And I think if this becomes a hard and fast requirement for a meeting and late-breaking changes cause us to no longer meet those requirements, then that process would sort of automatically be invoked. In my interpretation, this would automatically be invoked and the LLC and IESG would have a number of options on what to do rather than have the meeting in its venue.

Martin Duke: I was unaware of that RFC. I think that would be a desirable outcome, however.

Eric Rescorla: Um, I said I was unaware of that RFC, but I think that would be a desirable outcome. Okay, super. Thanks.

Andrew Campling: Yeah, sorry. Um, I think the issue here is we're contracting with a hotel or conference venue, not with a government. Um, I I I think the musts in this are a bit pointless because the venue doesn't have any control over these things. Um, and also I just question why we think we're so special that we need this, um, as was said at the mic, you know, most people will use VPNs anyway. Um, so I I'm not convinced this is solving a worthwhile problem and also, you know, we're contracting with the wrong party that would have power to adhere to this anyway, so it would be pointless to put it as a contractual requirement. Thanks.

Eric Rescorla: I'm not intending it to be a contractual requirement, by the way. I'm intending it to be a selection requirement. Um, and so you would look at the regulatory situation at the moment and if you couldn't comply with this then you would— then you would not pick the venue, just as if the— just as if the visa requirements, for instance, forbid people from a large number of jurisdictions from entering the country.

Andrew Campling: I mean, to take it to its extreme, some of the things that you specified as musts would rule out most countries. Um, yeah, many countries do block access to some services, some sites. I use the soft example of CSAM, there would be other things, but you know, I I think if we're saying—

Eric Rescorla: Well, that's actually not— if you're reading the text that way, um, I think then the text needs adjustment because that's not what this text is intended to say. Um, it's intended to target security technologies. Um, there actually are separate requirements about accessibility that Jay's been discussing privately, but this— none of this text would require you to not block any particular content site. It would require you to— to not block like VPN sites.

Andrew Campling: Okay. Well, I read the text differently, so maybe that's just—

Eric Rescorla: Well, thank— thank you for that comment. I'll see what I can do to fix it.

Andrew Campling: Okay.

Shuping Peng: So, Eric, do you want to finish?

Eric Rescorla: Oh sure. Yeah, yeah. The chairs— the chairs are in charge. Um, so, um, like next steps, I think this is like too small for a working group, maybe people disagree. Um, if there is no support, obviously we can do nothing, in— in consistent with my previous thesis. Um, if there is support, I think we could refine the text a little bit on this list and eventually AD sponsorship. Um, I'm like willing to do a working group if you want, but I just think it's kind of silly.

Shuping Peng: Okay, thank you Eric. I see a lot of discussions here and uh, let's focus on dispatching.

Martin Duke: Yeah, I I just forgot to remove myself from the queue, but just to follow up, it is RFC 9137 that covers the cancellation. I think it dovetails nicely with this. I don't have a strong— I would like to see this work progress. I don't know what the right venue is. Thanks.

Shuping Peng: Thank you. Stephen.

Stephen Farrell: Hi, uh, I guess I can just postpose Lars. Um, I think while this is worthy, I think if that text turned into an RFC it would become a blocker to various pieces of work. So I think this is better not done.

I also like this work. Um, I think AD sponsorship after some discussion on some mailing list would be good. As to the question of this being us pretending— claiming that we're special, I don't think that's actually valid. I think what this is aiming to do is something that we think should be normal for networks including ours. So I don't think this is us trying to privilege ourselves, it's— this is us trying to say how we think networks should generally be operated. And I think that's good. So, AD sponsorship would be my favorite. AD small working group if necessary, but hopefully not.

Jean-Philippe Vasseur: Jean-Philippe Vasseur. Um, so following what's just been said, I think the main core of the issue here is whether the IETF wants to subscribe to a number of principles and stick to them, whereas that may or may not have impact in the venues that we are going to be having. And I'm not specifically leaning to any direction at the moment because I'm not 100% sure that I can evaluate the consequences of that, I'm just feeling that it's a principles problem. Um, when it comes to the VPN side— so on the principles what I mean to say is that it would be good of those who are going to be positioning themselves think about whether we want to still defend an open internet, no matter what, regardless of the consequences for the venues, or we want to bend to the sovereign decisions of countries and just play along and decide. Now when it comes to the VPNs, my personal experience is that it has been quite different depending on which network I was connecting myself. So when it comes to the IETF, my VPN worked very well. When I connect to the Wi-Fi on my hotel, um, which is not the venue, it does not work at all. And because I have a SIM card that I purchased abroad, it would appear that even if it is a local operator, my VPN does work. And so I don't know if those requirements as to say that the VPN has to apply or work would also have to be specific to the IETF network because otherwise they may not work big time in the host. So it's well— very well known that China bans most VPNs and it's kind of a race to figure out which one is going to work next month. Um, so I don't think it's just the fact that the VPN has to work in the country, but the fact that it will have to work in the IETF network, which may be against regulatory— applicable regulations in the country.

Eric Rescorla: Just to clarify, the sense of this text is supposed to be— is supposed to be that it works in the IETF network. Um, you know, there could be no internet in the country as far as this draft is concerned, though of course that would not be a desirable place to thin generally.

Shuping Peng: Martin speaking as chair, very rapidly. Please stick to the dispatch questions as much as possible and not discuss too much the contents of the draft, unless for clarification. Thanks.

So, uh, speaking as an individual, clarifying question. Does your intended scope include not just security protocols but other protocols we typically experiment with? Like for example, 464XLAT not being supported in some venues?

Eric Rescorla: Um, it doesn't. I can imagine expanding the scope, but I think we were trying to keep it a little narrow. Um, I think my— my sense is— my sense is those is— is some of those protocols you might imagine putting in the scope and some in— in some cases, the experiment might actually be whether those protocols actually work in the— the wider internet, right? I mean like, you know, QUIC doesn't work in like 3 or 5% of networks, right? So, you know, um, so I think, you know, we'd be um— in some cases you might actually want to be exposed to the— the real world.

Martin Duke: Fair enough. Um, well then, uh, Tommy Jensen, IntAD. If that's the dispatch decision that the group comes to, I would be happy to volunteer to sponsor this.

Tommy Pauly: All right, here's the other Tommy. Um, so I'm a co-author on this and so I clearly support it. I just wanted to highlight, kind of for some of the conversation here, how the— it was the network requirements changing last minute that highlighted that there's a gap in our documentation for what to check on venues. Um, and you know, even if people don't agree with all the details that are listed here right now or think certain things should be added or removed, we really should be writing down what our expectations are as a way to guide the venue selection. Because if we're not doing that, then we're kind of having this uh, unfair relationship with the community and the LLC having to pick the venues. Um, if there are things that we expect, then we should have that written down and if uh, those expectations are not really the community's consensus, then we should update those expectations to match that. So I do think AD sponsorship makes a lot of sense here. Uh, I think we'd need sufficient discussion opportunities to make sure that we get the right list of things in here, but it also shouldn't grow too large. I don't think it needs a whole working group.

Colin Perkins: Hi, uh, Colin Perkins. Um, so I agree with Tommy that we should document the expectations. Um, I disagree that this should be AD sponsored. I think um, there is more debate required than that. Um, looking at the text as written, I believe my home network and my work network would not meet these requirements and I believe the networks we have had at a large number of previous IETFs would not meet these requirements. So I think uh, if— if we're gonna have these requirements, we should um— have a— a much more careful discussion about what— how to phrase it, and I think it does need something more than uh, AD sponsored, uh a bigger venue for discussion. Thank you.

Lars Eggert: Uh, I don't think it should be AD sponsored. I think it's important to have an open discussion about all the concerns when choosing a venue. I think there's a lot of important issues like cost and people getting visas, and I think checking social media when you enter a country is actually more privacy invasive than having to register your— your name when you log in to the Wi-Fi. Yeah.

Lars Eggert, NetApp. I agree with what Colin said. Um, in general, so documenting expectations is fine, but— but I hesitate to put any onus on the LLC or the IESG here because we already have a way too long list of uh, requirements that we have for the venue. Um, and especially the way the world is going, that means we rapidly only gonna meet in a few European countries, which is fine for me, but not great for diversity. Um, and— and it's good that we're taking out the last minute aspect of this because that is opening up a whole can of worms, but we really need to understand that we live in a world where not everybody's going to be able to come to every meeting for a number of reasons. Unfortunately. It sucks, but that's— that's where we are. And nothing we write down is going to change that.

Roman Danyliw: So I got on the mic line to say last time we made changes to the venue requirements with RFC 971— 9712 if I have the— the number right, we did that with Gen area and with the Meeting Venue mailing list, uh with AD sponsorship. Uh, so I am willing to AD sponsor if we want to— if we want to rev those meeting venue kind of requirements. Uh, and I think we should use probably that as a starting point for— for kind of how we launch. If this somehow turns into something kind of very massive, uh we want to open the box a lot more as was mentioned with scope, as mentioned with others, I would probably caution us against that. Uh, I think we should work this as kind of narrow topics uh on venue, but we'll see kind of how that goes. But I would think the starting position is let's take it to the mailing list we know has been successful in minting a broader scope uh and uh, you know, I could AD sponsor it if that's where we find con— if we find consensus there. So let's use the— the mechanism we have in place.

Rich Salz: Uh, yeah. Um, I was skeptical that uh, an AD sponsored would have enough broad discussion across the IETF to address the concerns and be a really strong statement of consensus. Um, I'm a little less skeptical given some people talking about how we did it okay before, so I guess I'm okay with AD sponsored but would prefer that we had an organized discussion forum that was well known, showed up in the agenda and things like that so that everybody, you know, there'd be no excuse not to know that this was happening.

David Schinazi: Hi everyone, David Schinazi, process enthusiast. So as much as I welcome the opportunity to test whether MASQUE gets through some various censorship regimes, I think, uh unsurprisingly, I'm supportive of this draft which, I mean, I'm a co-author, so that shouldn't shock anyone. I think uh, plus one to what Roman said, the Meeting Venue system worked last time in term— so I would prefer uh, AD sponsorship for this as well.

Pete Resnick: Yeah, this is Pete. Um, I think Roman's exactly right. Start it in Meeting Venue, announce it well, but the text that's in this document is short enough that if we stick to it, um, this is fine for AD sponsorship. Um, if we stick— Roman always has, and I hope he exercises the ability to say it's getting too big or there's more topics flooding in and says no, I'm going to charter a working group. The dispatch decision is only a recommendation and I think we should recommend AD sponsorship and discussion on the Meeting Venue list. One of the things I wanted to respond to Lars about is remember that there's only two requirements in 9712, the rest of them are shoulds and that the— you know, the LLC is supposed to do their best to meet those. Um, which of the things in this document end up on which list is part of the discussion to be had. I think it would be fine. Um, so I don't think we're making the list of requirements so long that we get to not meet anywhere just by introducing these three few and maybe one ends up in the should list if— you know, or two, either way I think is fine.

Shuping Peng: Okay, so we have cleared the queue. And we heard about AD sponsored, and we also found ADs who are willing to, but we also heard that people say no about the AD sponsor. And there are a few opinions on that. And so probably for now, we uh uh discuss more in the mailing list and then progress a bit. Yeah. Any more comments?

Eric Rescorla: I was just going to say thank you for your attention, but Richard may want to talk.

Rich Salz: Well, I— I was going to push back a little bit on that resolution because I uh, I don't know how a resolution gets made, um you know, in the next four months uh, if we don't make one now.

Shuping Peng: Yeah, and I was going to ask, did you mean when you say the mailing list, do you mean GENDISPATCH or Meeting Venue?

Roman Danyliw: Meeting Venue. Okay. Meeting Venue. Okay, thanks.

Rich Salz: Hi, I— I just wanted to say I I thought the outcome was a little more positive than the summary sounded. Um, discuss on Meeting Venue and AD sponsored as a goal seems perfectly good.

Roman Danyliw: Okay. Yeah, again, from my perspective, let's take it to Meeting Venue, let's polish based on some of that feedback. If we— if we find that we're in a place where it's— where it's ready to take to the larger community for consensus, I will AD sponsor it.

Shuping Peng: Okay, clear. And uh, this it. We finished all the presentations for today's session. Okay, thank you and uh, that's it.