Session Date/Time: 22 Jul 2026 10:45
[00:03:41] Chairperson: Okay. Alright. If we can come in and get settled, please. Maybe close the doors to the hallway. Hello? Hello? Hello? Okay. Great. Thank you. We could get go ahead and get started. If we can get quiet, please. And maybe somebody in the back can close the doors. Thank you. Okay. Alright. So welcome to the working group chairs forum at IETF 120. Apologies again for the late agenda but it's there now. This is an official meeting of the IETF. This is the IETF note well. You all have been displaying it to your working groups all week and you have agreed to abide by these rules. If you have any questions talk to any of the leadership. These are the meeting tips that IESG, that the LLC provides in their default slides if you use those, which is what I tend to do. And these are some resources. So with that we have a, depending on how the second half goes, a pretty full agenda today. Is there any agenda bashing? No? There is a notes page linked from the agenda if you want to help contribute to the notes or we could use the AI tool provided by Ecker. So with that, the first is David. As you come up, I'll get your slide up.
[00:05:56] David Skenazi: Hey, everyone. My name is David Skenazi. I just I'm one of the member four members of the Ombuds team, and I just wanted to very briefly provide kind of a reminder for working group chairs. So the Ombuds team is a team within the ITF whose role is to, if you ever witness any kind of harassment or someone talks to you by harassment, you can come and talk to us. We have a very confidential process to handle this, and our mission is to prevent it from happening. So we have tools at our disposal to make sure that if there was harassment, we talk to the people needed so that it doesn't happen again. Harassment is defined in an IESG statement there. I'm not gonna read the whole thing. But, conceptually, if someone is treating someone differently about a property of themselves that they can't change, that might be harassment. But one of the things that I wanted to remind the working group chairs group, because we've been getting a few requests recently is that not all code of conduct violations are harassment. Like, the main example is if someone is rude on a mailing list, that might not be harassment. That's just them being rude, and that still sucks. That's still something that needs to be dealt with by leadership, at which I mean you. Your job as working group chairs is to moderate your own working group chair working group lists. And if you want advice, please do come to us. We're happy to offer advice, but we're not gonna do your job for you. If someone, like, is having is is making ad hominem attacks, for example, that might just fall under the code of conduct clause that requires ITF discussions to be impersonal. So you can act on that as working group chairs, and you have tools at your disposal to moderate this person if talking to them privately doesn't solve the issue. So just wanted to kinda handle a reminder here and also remind you that we all exist, that we're here to help. That's it. Any questions? Alright. Thanks, everyone.
[00:08:41] Jean Mahoney: Hello. I'm Jean Mahoney. I'm, the director of communications and strategy at the RFC Production Center, and I wanted to give y'all an update. I'd like to talk about the new queue.rfc-editor.org website, give an update on the GitHub and markdown pilot programs we've been running. And also, since AI is a hot topic, just briefly describe some of the exploration we've done with that. Alright. We have a new queue site. So May 20, we launched the new RFC editor website. In addition, we launched a dedicated site to provide information about documents that are in the queue with better labels, more information about what is happening with the documents, and more information about clusters. So this is probably hard to read. I encourage everybody to check out the website itself. You will see that we have labels for documents. Some of these were automatically generated when a document comes into the queue. It's missing a reference. It gets a label. The RPC also adds labels, so you'll see, labels for this document as part of the markdown pilot program. Or we've identified that the formatting in this document looks like it's going to lead but there's a lot of formatting work to do, so we'll get a formatting label. We also have more information about the the status of the document. I'll get into that a a bit later. Here, for the documents that are in clusters, that is that they've got normative references to Internet drafts, We now have diagrams that can show documents that can move through the queue without hindrance. That's blue. They themselves are not pointing to any Internet drafts. And, those that are green can also move because all of their references are in the queue. Now the pink one has references that are not yet in the queue, and that's shown, with the orange. Carsten.
[00:11:21] Carsten Bormann: Yeah. I didn't want to interrupt you, but now that you have called me up. This page and and these graphics are really useful. However, very different events are put together under the label blocked. And it's very hard to find out whether something is blocked because it's in the intake process, which usually takes a week or so. Is it blocked because there there is a technical issue that that needs to be fixed and so on? I don't know if it's easy to refine this, but if you find any opportunity to refine the label blocked, I would be very grateful. Yes.
[00:12:06] Jean Mahoney: We've got an issue open on the data tracker to show more information on the data tracker itself for, you know, a document is waiting for author input or a document is missing a reference. So we we are working on making that information more clear. So with the the queue, we've got two big states, main states that's in progress, which means the RPC can can work on it or is working on it. And then blocked, as, Karsten mentioned. And I want to clarify, when something says blocked, the RPC is not blocking a document. The RPC is blocked from working on a document. Wow. So our in progress states, replace the, former state's edit RFC editor in auth forty eight. So we now can show when a document is sitting waiting for an editor to pick it up. So we have 11 editors, and we have four more documents in the queue. So now you can see it's waiting for a first editor. It's waiting for a second editor. I had a question about, well, what does a first editor do? And that is the first pass of copyediting. And a second editor looks more closely at some of the more difficult sections in an RFC to ensure that things are in good shape. So they look at IANA consideration sections and ensure that they align with the the registry. They do source code validation, cleaning up, like, descriptions and yang modules and ensuring that the references are referenced consistently within the YANG modules. We also are now highlighting when a document is being formatted and when the references are being checked. Blocked state. We used to have fairly obscure labels like off t I, so we've expanded this. So this should be clearer when you go to the queue site, and we will make this information clearer on data tracker that, you know, we're waiting for author input. We're this document doesn't have all its references, so it's blocked. We can't work on it until all of its affirmative references are in the queue. Also, instead of IESG state, which we had to apply to even things in IRTF if, like, the the stream came to us and said, could could you put a hold on that? So now we have a label stream hold. And instead of the really obscure TI tools issue, we haven't had to apply that to a document in a really long time, but that's if we have, an issue with the ability to produce the document, like xml2rfc is not doing quite the right thing, that's when that label will be applied. Alright. So one of the things we did, we got rid of the label auth 48, which but it is an obsolete term. We have not held anybody. So I I and maybe people don't know where this came from, but a long time ago, the RFC editor would make a document available, tell the authors, you've got forty eight hours to take a look at this and let me know if it's ready to go. But if I haven't heard from you, I'm publishing it anyway. We do not do this. But, however, the our our database was so crunchy and old, and we couldn't update it. We couldn't change this label. So new label, but the processes have not changed. So a a little bit a change, though, with just identifying action holders, and this is going to help us provide more information to data tracker in a subsequent release that this will help us build the the AD dashboards that the tools team has been requested to develop. So action holders are are called out on the individual pages for final reviews and will eventually show more clearly on data tracker. Rowan.
[00:16:56] Rowan May: I I just think that in ten years, we're gonna be looking at final review and saying, what a what an anachronism an opaque anachronism that is. Anyway Oh. It's better. Thank you.
[00:17:08] Jean Mahoney: Thank you. Alright. So moving on to our, pilot programs, we've got, we support editing in markdown and also holding final review in GitHub. So some stats here. We are limiting this to five documents a month, but if it's the end of the month, be sure to look at the intake form to see if you have the question. Hey. Do you wanna participate? Because the spots don't get taken immediately. So there's usually some room at the end of the month also. And wanted to point out that 28 of the documents currently in the queue are participating in one or more of these programs. And another thing to point out, when we started this, people were saying that people who went to work in Markdown also went to work in GitHub, and GitHub means markdown. However, we find people some authors just want to work in markdown, and they don't want to participate in the GitHub program. Others want to participate in the both GitHub with markdown documents and also with, the the XML. So I had also heard comments about, oh, nobody editing in XML will want to work in GitHub, but we we're seeing people do. Alright. So, some small issues, with GitHub. So and regarding notifications. So we invite people to, join the repo as a collaborator. Need to accept that invitation. You also need to set your notifications so you know what's going on. We can't set those notifications for you when we add you as a collaborator. A little bit of RTFM. All our instructions are in the read me. But please, if people are not understanding the the instructions in the read me, let us know. Give us feedback. We can definitely update those for, the next go round. And, also, some authors might go, yeah. We wanna do GitHub. And maybe some of their coauthors might not be as comfortable. So we would like for the authors to ensure that everybody's good for it. Alright. So kramdown. We're liking kramdown. We like editing in kramdown. It's easier to read when we're editing. And knit here because markdown so let's see. kramdown-rfc uses kramdown as a base, and, also, kramdown, can deal with other markdown variants. So sometimes we get surprised by unusual or infrequently used markdown. And so but that's not gonna hold us up for weeks. That's just a, oh, wow. And that that works. And then figuring out what that is. Oh, alright. Okay. So, everybody's interested AI. The RPC has also looked at AI. We have found using agents to edit text, the editing is heavy handed. It is not as conservative as we would be with editing text, so we have not found that a useful thing because, you know, with heavy edits, now we have to figure out what did the author say, and what did the AI, you know, do with that. We have seen some good use with updating the formatting. One of the things that we take a lot of time with is comparing similar text and terms in in clusters or with normatively referenced RFCs. And it seems to be pretty good at highlighting, oh, header fubar is capitalized in this document, but not in that document. Also, source code validation, and also doing that comparison of he did the registry with the information in the INA consideration section. So and I think that's it. And if you would like to more information about the queue, wanna play with it, have questions, please come to the desk. We're here, today and also tomorrow. Any questions?
[00:22:21] Chairperson: Nope.
[00:22:25] Mirja Kühlewind: Mirja Kühlewind. I wanna come back to the GitHub part. So thanks that you're working on it. Mhmm. And I understand that you need to get some experience with the process. But right at the moment, it's actually, for me, as somebody who works on GitHub, more work to use your process than not using your process because you have a separate repo, and so I still have to copy everything over into my repo. Right? So that doesn't really address the problem that I would like to use GitHub for. So maybe we can iterate on the process a little bit more.
[00:22:51] Chairperson: Okay. Thank you.
[00:22:54] Paul Hoffman: Paul Hoffman. Going back on the GitHub thing, we just had an I just had an example in my working group where some of the authors were familiar with how to do off 48 I'm sorry, final review. Mhmm. And other others weren't. And what that meant was you got two authors agreement really easily and the rest not, and they didn't know and such like that. How are you dealing with these sort of, you know, group of five authors where there's a a skills and an understanding split? Because I'm sure I can't be the only working group chair with this.
[00:23:30] David Skenazi: Right.
[00:23:34] Nick Buraglio: Hi. Nick Buraglio. First of all, I wanna say thank you for working on this. I found it immensely useful to be able to work in GitHub and Markdown. I had two sort of question y comments, and I apologize if this information is out there and I just haven't been able to find it. First is a couple of years ago, had communicated with someone in, I think, RFC editor or maybe it was tools about a a a a reverse tool from XML to markdown, which I think is probably somewhat fringe but would be very useful in certain cases. And I was I thought under the impression that this was it existed, but it wasn't public. I don't know if that's true or not, but I think that would be something that would potentially be useful from from the tools. The other question that I had was, is there any markdown guide that has because, basically, I had to go and find other people that had written things in markdown and just copied their stuff so I so I could get it to compile correctly. Is is there a plan for any type of guide like that? Does it exist and I just can't find it?
[00:24:53] Carsten Bormann: Or Mhmm.
[00:24:54] Nick Buraglio: Is that something that would be considered if it doesn't?
[00:24:58] Jean Mahoney: I'll let Karsten answer.
[00:25:01] Carsten Bormann: Yeah. So if you're looking for the tool that converts XML to markdown, you are looking at it. I'm their tool.
[00:25:10] Presenter: Oh, okay.
[00:25:14] Carsten Bormann: Yeah. So there is a tool, but that's the answer to the second partial answer to the second question. There are certain ways of doing things that are idiomatic and other things that confuse people who work on this. So when you up convert something from XML to to Markdown, it always makes sense to to have another look. Is this a reasonable way to represent this in Markdown? And my tool gets better and better each time I throw something at it. So right now, I just send me stuff. It won't you won't get it back same day every time, but often you do. And, well, I'm not gonna going on a vacation for two weeks, so please send it now and not not later on. On the documentation thing, there is a wiki, wiki.rfc.space. And well, that's just the GitHub wiki, nothing special. But lots of people have collected information there. So maybe 60% of the text is from me, 40% is from people who have contributed, and I'm I'm very glad that people are doing it.
[00:26:23] Nick Buraglio: Excellent. Thank you.
[00:26:27] Chairperson: Sean.
[00:26:27] Sean Turner: Hey. I'm Sean Turner. I'm just surprised that the answer was you wasn't use AI. Okay. So, I know this is just an experiment, but the sense that I have is that, like, most people I know are chomping at the bit to use this, as the regular default process. Do you have any sense for when we'll be done with the experiment and decide or evaluate the the the number of times it was used and whether it was good or not and when it will become the default plan?
[00:26:53] Jean Mahoney: So the RPC is moving all their drafts into GitHub repos. So when we turn it so we will continue with this pilot program, but we will also you will start seeing our our history in in the repos is we when we open it for final review. So but we just started that. So give us a couple of months to get comfortable with that, and I think we'll you'll see that we'll be able to turn this up. So, Jonathan?
[00:27:39] Jonathan Lennox: Yeah. Jonathan Lennox. So we've just been having a brief side conversation in the chat that the one downside of renaming auth 48 is that it no longer implies a deadline. Even though that deadline was not for true, it at least imposed some pressure. And so I guess what the question I'm coming to is who's if if authors are being unresponsive or poorly responsive, whose job should it be to impose pressure on them to actually respond?
[00:28:05] Jean Mahoney: The area directors. So we will send out weekly reminders. Mhmm. And if it goes on for a while where a while may I don't know. Depending. Like, we understand nobody's going to respond in August if they live in Europe. And Yeah. Yeah. But then we may ask the AD if they might consider to approve on that author's behalf because that's part of the process for an unresponsive author
[00:28:33] Jeff Haas: Right.
[00:28:33] Jean Mahoney: Is for the AD to approve.
[00:28:35] Jonathan Lennox: I I was mostly just wondering, should is this something where working group chairs of Document Shepherd should be involved, or is that entirely past that and it should just be
[00:28:43] Jean Mahoney: I feel or an AD? Feel feel free to encourage the authors to respond.
[00:28:52] Chairperson: Mike.
[00:28:53] Mike Jones: Hi. Mike Jones. As an author and chair, sometimes dealing with the markdown, one observation I've made is that unlike XML to RFC, we don't have comprehensive documentation of what the syntax that's acceptable in kramdown RFC is. Yes, we can search on the web and try to find examples, but that's fraught and it often doesn't Is there a possible plan in the ITF to produce good documentation so that there's one source that you can look at?
[00:29:37] Jean Mahoney: So kramdown-rfc is Karsten's code. And, Karsten, you mentioned the so I know there's a wiki with your with that repo. And I heard you mention another wiki, or is that the wiki? That is the wiki. So
[00:29:57] Mike Jones: Yeah. But it's not comprehensive. I can't find syntax for a lot of structures that I know how to do in XML. So
[00:30:08] Jean Mahoney: the RPC internally has what we call a Rosetta Stone, which is the a table of markdown in XML. And so this is, I think, pretty baked at this point, and we could make that available on the author's website. So That would be great. Thank you.
[00:30:29] Chairperson: I've I've closed the queue, but if you could be really quick.
[00:30:34] Presenter: Yes. Yes. A little bit similar. T protocol heavily used the GitHub and markdown, and I'm I'm a suit chair, and then not always using GitHub and markdown. It's because I was it it takes reasonable time to set up the GitHub and with the markdown. So it will be nice to have a little bit template to copy, then it will make it easier to use it. I know. I know. I know whether. Just
[00:31:03] Jean Mahoney: Okay.
[00:31:06] Chairperson: Alright. Thank you. Okay. If you have any additional questions, stop by the desk. Jeffrey.
[00:31:25] Jeff Haas: I
[00:31:29] Chairperson: said Jeffrey.
[00:31:30] Jeff Haas: Oh, there's nobody here.
[00:31:31] Chairperson: Oh, sorry. I did say Jeffrey. Maybe it didn't transmit.
[00:31:34] Jeff Haas: I heard him. Okay. You heard Jay. Okay.
[00:31:39] Mark Nottingham: You heard
[00:31:39] Jeff Haas: Jeffrey. That said, I'm Jeff. So I'm here to give, hopefully, a very brief talk about, first come, first serves and what we're gonna do about documentation. Who here in the room has a working group that uses first come, first serve IANA? We have a few. Not as many as I was expecting. So it's helpful for a lot of protocols. And one of the things that's really good for it is disincentivized squatting. And for people who have protocols like BGP where stuff can bounce around very far and have all sorts of interrupt problems. You know, avoiding squatting is really important to us. And, you know, for the code points that we want to use, it's we want to use these only when it's safe to do so. We do have features that are not safe to just simply let people grab a code point and stick it in there. But the problem we have is when we actually incentivize the first come, first serve, we also have other needs that aren't really covered by current procedures, minimally visibility. And part of the headache here is, you know, what does, you know, I am actually say about this? You know, first come, first serve, very fiercely, is you ask for it. The change controller for the registry, you know, helps bless the thing, and there's a very light review process. This does mean, in many cases, that the reviewers, which are often the chairs, can take a look at things and say, this is what it's supposed to do. Yes. We're gonna approve this. Ayanna doesn't review for, know the contents, and they, more importantly, don't know take a look at things if something does change. So we're in an interesting place, know when you need to document things. The ianabis work has a a bit of discussion about a hybrid mode. This hybrid mode is basically not quite specification required. It's we want to have some sort of stable, know, reference for what the thing actually means. And, minimally, you know, if you're, like, building a TSP dump for a packet, being able to decode the thing to print it even if, no, you don't do a single thing else is useful. If your router receives something and just wants to display the TLV, you know, to actually help the operator figure out what's going on that maybe another device cares about that's useful. So we do have a need to provide at least lightweight documentation and, you figure out what we can do about it. ianabis is doing work right now. Hopefully, those of you who raised your hands about first come, first serve are paying attention to that work. If not, pay attention to this one specifically. Also, figure out what the change controller ends up meaning because, you know, they're the only gatekeeper we're going to get out of this sort of thing. The harder conversation is what a stable reference means. If you're monitoring things like IAN Abyss and ProCon, you're gonna see some discussion about how do we actually write these things down, what's the mechanism for it. Internet drafts are easy. But sometimes, we have people that want to drop a code point in that, you know, is this reference over in GitHub somewhere? Well, that's not gonna be around in a few years. The repository might get deleted. It might be in a different you know, somebody's wiki. You know, that might go away. Part of the feedback Sue and I had given to, you know, IANA at their open desk hours is that maybe allowing for some sort of archival snapshot by IANA of some source document, you know, basically as a library of record, that would actually solve this sort of problem. They do need to have the ability to get a license to do so for that sort of thing. So there's legal considerations for them taking up that kind of function, but know there are options. So primary purpose for this talk is really just to bring this point to your awareness. This is important for a lot of us that have protocols that go far. So if you have any questions, we can have, you know, maybe a minute or two of brief discussion. But mostly, this is please pay attention. Please provide feedback. And you have specific thoughts about how stable documentation gets done, please, you know, help Diana to have that discussion.
[00:35:45] Lou Berger: I'm being slow. Yeah. The whole yeah. Lou Burger. Why not just use specification required?
[00:35:52] Jeff Haas: Specification required is, no, too hard. You know? And that's the whole problem for each of these things is that each have a gate. You're immediately gonna say, hey. I could just go talk to the ISG and get early assignment. And, you know, if you're an area director that is tired of redoing, you know, these things over and over again, raise your hat. There's gonna be a few people that have done that.
[00:36:12] Lou Berger: So the specification required doesn't say where that specification occurs. It's up to, if I remember correctly, just the expert to decide if the specification is adequate. Yep. And the flip side of
[00:36:23] Jeff Haas: that is expert reviewer as well. You know, an expert review can just simply bless this thing and have it done. Again, the challenge is who does the registration? Who glances at the thing, which is expert, you know, behavior? And then how do you actually document it for the long term?
[00:36:38] Lou Berger: I would ask that you just delineate between what you're doing and specification required because I'm not hearing a difference.
[00:36:45] Jeff Haas: It's it's very, very thin. I completely agree.
[00:36:49] Mark Nottingham: Mark? Mark Nottingham. Just to highlight, we, had a discussion earlier this week in ianabis, about a document that I'd put forth about, sub policies for specification required. I think the the lightest way to one of those might address your uses. So maybe that's a discussion to continue. Thank you.
[00:37:06] David Skenazi: David Skenazi. I raised my hand earlier, but then I realized that we use a registration policy that's not first come, first serve. It's almost first come, first serve. And it's actually just expert review. You don't need to change anything, and we just tell the experts approve everything except if it's completely bonkers, like someone asking for half of the space. Put specification required with a note for the experts that'll get you everything you need, I think.
[00:37:31] Jeff Haas: And your point is effectively same as lose. The problem is the you know, where you're slicing what these things mean, you know, that's exactly what ianabis is trying to refine right now. Yeah. So
[00:37:41] Sean Turner: hi. Sean Turner. We basically do the same thing. It's spec required with expert review and then basically leave it up to the DEs, and, like, two of them have to agree. You write some rules about all that. And it's working for TLS. And the nice thing is that when the people do squat, though they're not supposed to squat, most of them have a pretty good idea of picking some random number that's in the big space and so they don't collide and all that. And then they delude behind the scenes to, like, use it and test it, which is all good, but it that just means that you're actually getting interoperability. So that's kind of a good thing. So I don't know. So thanks.
[00:38:12] Presenter: So when when we're talking about the review standards, there there's two things being reviewed here. So there's the stuff in the standard, and then there is the durability and hosting location of the standard itself. And that first one is very well adequately covered by expert reviews, specification required, plus advice to the reviewers. It's that second piece or or that first piece where, we need definitions for or at least some vocabulary for describing what suitably permanent means in particular places. And providing that as guidance for even the experts could be something that might be of value.
[00:38:54] Jeff Haas: Exactly. And, yeah, the longevity for GitHub is one of the things that has popped up. And rather to your point and to Sean's point, what's the difference between expert review and first come, first serve? Well, it's really the instructions for first come, first serve is thou shalt issue this rather than, oh, the experts may decide whether they like it or not.
[00:39:12] Chairperson: Okay. Real quick because I locked the queue. So you and Murray.
[00:39:14] Rowan May: And then
[00:39:15] Presenter: I I put my name up, and then I I accidentally ticked you both back off. I feel like we need something that's between an individual draft and a complex RFC process document, which is basically an individual Perma draft, which is I've described this thing in a way that's not going away, will be retained by the IETF, and I've agreed to all the note world stuff around it so you don't have to snapshot my web page and deal with the IPR on it. But it's still it's a permanent thing that doesn't need to get consensus of everybody else. It just needs to have the experts say, yeah. That looks good to me. Exactly. I think that solves this problem. I don't think we need more than that.
[00:39:55] Rowan May: Hi. Chair of iAnabyss. Where were all you people on Monday?
[00:40:00] Jeff Haas: Stuck stuck in other meetings, which is partially why I'm here. Anyway, it's my closing remark. Clearly, we have people that have opinions. We have, you know, shown that, you know, for each of these pieces, know know who gets the control, who gets the review, who gets the say so, where do we document these things. There is a lot of fine slicing and dicing going on here. Please give the stuff to Anabyss so they can actually write it down and come up with the answer. Thank you.
[00:40:25] Chairperson: Alright. So the next agenda item first of all, if you haven't signed in to Meetecho, please do so because it affects the capacity of the room and the lunches that get provided. Second of all, Mark, the next part of the agenda, there was a bunch of suggestions on the list about AI stuff. I wanna focus on the AI, how we're using it to help manage our working groups as opposed to the policy issues that the leadership's gonna need to deal with.
[00:40:55] Jonathan Lennox: Is it possible to plug in? Can we still I don't even know if it's possible.
[00:40:59] Chairperson: I don't know.
[00:41:01] Mike Ellsworth: I guess we're fine.
[00:41:04] Chairperson: So I'm just gonna
[00:41:05] Mark Nottingham: load these stuff.
[00:41:06] Jonathan Lennox: Alright. Cool.
[00:41:07] Mark Nottingham: Thank you. Wow. So that does something? Okay. Well, that oh.
[00:41:13] Carsten Bormann: Uh-oh. I
[00:41:15] Mark Nottingham: don't need network.
[00:41:16] Jonathan Lennox: Oh, I think it's that's the right. I'm gonna keep it warm up.
[00:41:20] Chairperson: I I think it's easier to be on and share each
[00:41:23] Mark Nottingham: Just share share from Meetecho? Okay. I could do that probably. Hi. Let's try this.
[00:41:37] Jonathan Lennox: Yeah. You gotta
[00:41:39] Mark Nottingham: That. That.
[00:41:45] Carsten Bormann: Yeah.
[00:41:47] Mark Nottingham: Sorry. This is not really set up for doing a demo. We'll see how it goes. Alright. Yes. I have to do the full client, don't I? I have requested a screen share, apparently. I do. I'm just gonna share the whole screen. Share entire screen. Yes. Oh, pretty. Okay. I don't need that anymore. Oh, dear. Well, let's just use it this way. It's fun. So I I'm gonna give a very speedy version of a talk that I'm giving at rasprg tomorrow. It is about artificial intelligence and standards participation. I I don't think it's gonna come as a surprise to many people here that we are seeing increased use of AI not only to to write drafts, which is one aspect of this, but also to actually participate in the process. And so this is, in some ways, a good thing. We're seeing, people using it effectively as an accessibility tool, you know, especially with things like translation, and helping their comprehension, and that's great. But, we also see things like, I hear chairs complaining about their group being flooded by AI generated drafts, like large numbers of them, or people unleashing semi or fully automated bots on, mailing lists and having them argue with people. And and that really changes the incentive structure for the work that we do in in in perhaps worrying ways. And and I would put forth that this is even an existential threat for the IETF, that because LLMs significantly and really consequentially lower the barrier for participation, it changes how the work we do can go forward. You know, we have a relatively small number of people who who provide the quality of of specification and experience that makes our standard successful. If they are overwhelmed by, let's call it, slop, then, their capacity to to help produce good specifications is reduced, and, ultimately, we will not succeed as an organization. And then, you know, putting my corporate hat on, it it it is very hard for me to recommend to my company to bring work to the IETF in some venues where it is dominated by AI generated content. It's just it's too much of a circus. It's too much of a free for all. So I when I think about this, I think something needs to change. And this is a a quote from John Peterson when I was talking to him about this, which I think is is is reasonable. So I think of it in two ways. I think we need to have some carrots, and then later on, there may be some other object we will refer to. So the carrot, one thing is a tool I put together a little while ago called IETF LLM. It basically allows you to gather a a corpus of materials related to an effort in the IETF so that LLMs can then interact with it. It's meetings, mailing lists, transcripts. Ecker's nice transcript school tool that pulls from that, issues list on GitHub, the drafts themselves, IASG ballots, the related RFCs, all into a a single place. It munges that so it makes very transparent to the LLM. It it does things like strip quotes, comments, signatures, mix markdown, and then does embeddings on it. So the I the LLM can do semantic search on it using the the MCP server. It's about 22,000 lines of Python. Yes. It is vibe-coded. Quite an enjoyable process. I recommend it to everyone. And it has three low modes of operation. You can run it as a local MCP server on your own machine. You can do it as a shared cloud MCP server on Cloudflare or Amazon or, you know, whoever else. Or you can also run it in the original mode it was designed for, which it was gathering a bunch of files and sticking into NotebookLM or a similar kind of tool. That third case is probably gonna be deprecated at some point because it seems like the MCP mode is working really well. Very easy to install. You use PIPX, which if you're not familiar with PIPX, it's just a way to install a Python program as a an isolated VM, and it does all the magic for you so you don't have to worry about it. And then you configure it your harness to use it as an MCP server, which is implementation specific. So what can you do with it? I've been using it for a little while, and I find it's really extremely useful for asking questions like, you know, why is this topic contentious in this working group, or what's currently going on in a particular working group? And, you know, even what's happening in TLS, some people are interested in this, apparently. What I find is is that you you can ask all these questions to Claude or or whoever, and you get an answer. But what it does is it calls its web tool because that's what it's got, and it makes a couple of requests to data tracker or whatever. And then it says, okay. I've used my budget up. You know? I've I've used these tokens. I've used these tools this many times. I better give an answer now. And so it gives you a fairly shallow answer. When you have the MCP server and it is really tailored for through through a lot of iteration for for answering these kinds of questions, you get a much more nuanced answer because the budget is much effectively much larger. It can ask a lot more questions and get a lot more information and and work with that. And so you get much richer answers to these questions even if you don't want them. So how are we doing on time? Can I can I give a little demo? Is it worth it? Yeah. Okay. Let's give it a go. Oh, I shared my whole screen, so this would be a little easier. There we go. Afternoon, Mark. Somebody give me a quest oh, first of all, let me do this. There is a command line interface as well. Is that big enough? Let me make it bit bigger. Is that okay? So you do an I t f l m. It's got all these different you know? Oh, it's a little too big maybe. Anyway, if I do this sorry. List. Here. Alright. Let's make that fit. Is that still legible ish? No. Okay. Oh, I see. Because it's doing the thing. Yeah. Alright. There. That's a little better. Okay. So you see, these are all the corpus that I've I've gathered locally. It is incremental, so it pulls all the email off of IMAP, the IMAP server, and keeps a local cache. I try to make it as friendly as possible to the data tracker. And then it it tells you when it was gathered and and what's covered by it. So if you see all these ones that's currently gathered, somebody give me a question. What what should I ask it? Anybody? I'll ask what's going on in TLS if I don't get anything.
[00:49:02] Jonathan Lennox: Yeah. Go ahead. Go for
[00:49:03] Mark Nottingham: it. Alright.
[00:49:04] Presenter: In TLS.
[00:49:05] Mark Nottingham: What's happened in TLS in the last two weeks? Let's give that a go. Oh, come on. Use the MCP server, you.
[00:49:25] Presenter: No.
[00:49:28] Mark Nottingham: This is like the first time it's done this to me for about two months. That's very annoying. Okay. Use the there. And
[00:49:46] Mike Ellsworth: this is why we all have jobs still.
[00:49:59] Mark Nottingham: There she goes. So you see it has a way to do semantic search as well as pull individual chunks of files. There's a pre canned overview of each corpus so that it can kind of get easy information easily. It indexes all the participants that it can identify and make sure that it cross references them so they're the same people. So in Ecker's transcripts and in the email and in other places, it says, okay. This person is that is the same person as that person over there. The big one. Yeah. I do have some fairly strong guidance to to avoid certain phrases, but I say I need to beat it about the head a bit more. So, yeah, it's it's it's there we go. All this fun. Sorry, TLS chairs. Don't mean to bring it back. Yeah. So that's that. I encourage folks to have a play with it. I had a working group participant in one of my groups use an earlier version of this to actually create a proposal and test it against arguments that had already been made in the working group to make it more successful, and that proposal was ultimately adopted as the basis of work in
[00:51:14] Presenter: the group.
[00:51:15] Mark Nottingham: And it was a really contentious issue. So to me, that was like, wow. You know, this is this is something that's really interesting and new. So moving on. Next tool, ITF skill. You've got an MCP server, but the LLM doesn't have any kind of context for how to use that or what to do with it and and what the ITF is. So ITF skill is basically assistance for participating in the ITF in skill format. Actually, there are three skills right now. I think the third one's in a in a further slide. It started with two skills. One is in ITF interpreting, understanding how the ITF works. So basically outlining how we form consensus, the working practices, the norms that are kind of unwritten about the organization. All these are my opinions, but but hopefully informed by some experience. The other one is ITF contributing, how you actually draft text to participate in the ITF, And especially for for people who choose to use LLMs for creating email, it gives very heavy advice about brevity and about being on topic and making sure that you're not wasting people's time. Well, there's a whole discussion to be had here, and I'll get to this at the end. But, yeah, the question is what incentives can we give people? We're on the carrot portion of the discussion right now. So, yeah, you clone the repo. You do make install, and it does it. If you're already using ITFLM, you can just call that with a command flag and off you go.
[00:52:43] Jonathan Lennox: You wanna ask? Sure.
[00:52:45] Mark Nottingham: Okay. Yeah. So some details on what's in the interpreting skill. You just go and read the it's markdown. Just go read the skill as to what's in it. And if you disagree with it, please tell me. There's an issues list. Likewise, for the contributing skill, it's got lots of information in it. And then there's a third skill, is the newest I just did over the weekend, IATF HTTP. We basically took the we have a b c p 56 is how to how to write protocols with with HTTP, especially for not IETF audience. And we have a a HTTP directorate, which is reviewing HTTP drafts. So we took b c p 56. We took the editorial style that we have for HTTP documents. We munched those together into a skill, and we started using it. It's very early days. It's very rough, but I've already used it in engagement with one draft review, and it was absolutely fantastic. It you know, you still have to hold its hand. You have to read everything. You have to make sure that you agree with what it's saying. But as long as you take that level of responsibility, it's an incredibly useful tool. And the feedback from the folks I was working with was very, very positive. So for me, this is a great way to take some of the burden off of your director or reviewer's shoulders and share it out a little bit. Because every time I assign a director review, I get sad inside because I know I'm creating a lot of pain in someone's life. Yeah. So let's talk about the stick. This is the best emoji I could find for that. Yeah. Let's discuss policies. So tools are probably enough. We we we need other ways to guide people's behavior, and I think this comes to your question of when is it appropriate to use LLMs? When is it not? What do we wanna encourage as an ecosystem? I ask questions like, you know, is pointing an LM at a list and asking it to you a point for you autonomously disruptive conduct? Personally, I would say yes. As a chair, I would like some backing that that it's okay for me to say, no. Don't do that. That's disruptive conduct. But we haven't had that discussion yet. As a participant, and I see somebody else doing that, is it okay for me to say, no. Don't do that. You know, I'm not I'm going to ignore you because that looks like it's an LLM. Is that harassment or unprofessional conduct, or is that okay? I I don't know as a participant yet, so we should have that discussion. And and, you know, there are many gradations of these questions in terms of fully not autonomous as one end of the spectrum, but what if somebody's just being a bit sloppy? You know? What if they're just being quite verbose, but it's still human guided? Is that okay? Where do we want people to end up on that? I've heard people talking about disclosure requirements. You know, if you use AI, you have to disclose it. That has some interesting aspects in terms of incentive structures. You know, people are very reluctant to to reveal this, and it might just cause them to hide it further. I heard one person suggest recently, should we can change how we consider new work? You know, ban people writing Internet drafts until we have the a use case that is firmly defined and agreed to by the working group. Because someone told me their working group had seen 60 AI generated Internet drafts, and I I I don't know what you do in that circumstance. People have talked about changing the nature of participation in the community, we're not quite so open that you need some sort of strongly associated identity. I think that's a pretty big change for us considering our history and nature, but I have heard people talking about it. To me, the question more than anything, you know, we can come up with all the rules we want. What are the norms? What do we encourage as behavior in our community? And I think that's a really important question. That's all I got. If you install these, please update regularly because they're moving very fast. That's that's where I'll leave it, I think.
[00:56:28] Chairperson: Alright. We have four minutes. So, go ahead, Mike.
[00:56:32] Mike Ellsworth: Hi. Mike Ellsworth. I reviewed your Skill files, both of them in great detail. I you a basically paragraph by paragraph feedback.
[00:56:39] Mark Nottingham: Sorry. I didn't quite hear that.
[00:56:40] Mike Ellsworth: I sent you an email. Yes. I probably got lost in a thread with a, like, paragraph by paragraph feedback on the skill files. I wanna make sure you got that email. And if you didn't, let's find you in the hallway.
[00:56:51] Mark Nottingham: What's your name? Mike Ellsworth. Yes. I thought I responded to that.
[00:56:54] Mike Ellsworth: Okay. Excellent. Okay. And then for the room, I wanna say, I think this is great, and I especially like the aspects of this that give feedback to the human before hitting the send button. Like, things that humans are bad at is tracking a 600 reply email thread or other threads with other titles. And they're like, hey. This thing you're about to post has already been said 12 times. Maybe don't. Or here's an obvious rebuttal. Maybe you should address this in line before you post. Like, that, I think, is an excellent, excellent tool for cutting down noise and repetition. Thanks.
[00:57:26] Sean Turner: I think I was in the queue. I
[00:57:31] Jeff Haas: don't know. I was in
[00:57:32] Presenter: the wrong one.
[00:57:32] Rowan May: Hi. Rowan May. So I just wanted to comment on one very narrow point, which is on having an agent autonomously respond to emails or GitHub. So I think we should have a, you know, a norm, a policy, or a requirement that says that a human has to push a button. If if you're in compliance, it has to push a button to send a send a message. One one, you know, human has to do some one thing to generate one message so that there's no amplification.
[00:58:07] Mark Nottingham: Thanks. I agree with you, but I think we need to think through enforceability there.
[00:58:13] Rowan May: So I I think even if we just say that that's what we expect, then we can continue to figure that out. But I don't think we should wait to make that statement.
[00:58:23] Mark Nottingham: Fair call.
[00:58:27] Presenter: Hi, Yeah. Thanks a lot. It's I I need an eye to help me to figure out which of these things to try out first. What I've been getting to so far was, you know, using the AI to improve the quality of documents by reviews, which kind of, you know, ESL, English as a second language for those who don't know. Right? So Claude has been much better than any of the other spell checkers I tried. Yes. It it makes mistakes, but you can put guardrails in, capture all the stuff that it's doing wrong so it doesn't do that for the next revisions, and finds even small logical bugs. Kind of you forgot a not here or there is a not where there should be not one. And so those, I think, are good recommendations to work out on. I think another participant in the working group stood up and said he got even further. I I was only trying to do syntactical checks. Right? And but he was also slightly with with a lot of guardrails trying to improve the sentences. Right? So kind of engineers think yep.
[00:59:28] Presenter: Thank you.
[00:59:32] Presenter: Yeah. So so I've been using this. I'll say from the Keras perspective, it's amazing. It really helps with very, very fast moving, big working groups looking at UMAC, trying to pick out the work that, you know, matters and or for me specifically. The but I wanted to say on the norms, I'm already starting to see on mailing lists things posted like, you know, at the very top of the thing, re review AI assisted review lightly edited, AI assisted review unedited. AI assisted review, I reviewed every word. And I think if you know, when when chairs start doing that, it helps set norms that really set the tone because people look at our look at our posts. And so if we start, you know, setting those examples for everyone, I think it matters.
[01:00:32] Mark Nottingham: Yeah. In my CloudMD, I have something that says whenever you post to GitHub, characterize the amount of human involvement in every action you do. And it really helps.
[01:00:40] Chairperson: All right. So we're at time. So if I could last last three people in the queue, like fifteen seconds each, really quick.
[01:00:47] Presenter: Thank you for the thank you for the presentation, Mark. And looking forward to see more of it at rasprg tomorrow at 04:30, a bit of self promotion. Do you think that some of these things, and I'm thinking particularly about the skills, would require or benefit at some point of reaching consensus on how agents should participate in the discussions?
[01:01:09] Mark Nottingham: I I could see that future. I think we're a long way from it. Yeah.
[01:01:13] Jay Daley: Hi. Jay Daley. If anybody's particularly worried about their own working group, then I have a little tool that pulls messages out of IMAP, does some work to extract the novel content, and then throws it through into an AI text detector, pangram, and then produces an output list and shows you the ones that are either AI generated, AI assisted, or partial, or anything like that. Okay? Yep.
[01:01:38] Presenter: As a member of the about to be announced moderators team, it would be very useful to have a strong norm of if somebody is caught using AI to automatically post, that it is legitimate to block them and the community says do that, because that would give us a clear guideline. We just look at it and say, yep, that there's no human behind this. They're kicked off.
[01:02:02] Jonathan Lennox: Right.
[01:02:02] Presenter: And they're in the SYNBIN for a little while. Thanks.
[01:02:05] Chairperson: Alright. Thank you all very much. We are oh, go. Sorry.
[01:02:07] Mark Nottingham: One last thing, for this specific audience for chairs. The second last bullet, review the last interim meeting of the AI prep working group and characterize any bias by the chairs. I did that for us, and it was incredibly useful to to self evaluate. I'd encourage everyone to think about that.
[01:02:23] Chairperson: That's really useful. Thank you all. Please clean up after yourselves.
Session Date/Time: 24 Jul 2026 05:45
[00:01:13] Karen O'Donoghue: Okay. I think we're ready to get started. Good morning.
[00:01:32] Mohit P. Tahiliani: Shut up.
[00:01:32] Karen O'Donoghue: Alright. Let's go. Yoo hoo. Hey. Folks, we're getting started.
[00:01:44] Jay Daley: Hello.
[00:01:49] Karen O'Donoghue: Excellent. We have a really full agenda so we're going to go ahead and get started. I know a couple of people need to leave early. So this is EODIR at IATF and this is the note well you all have agreed to. Go ahead. Go ahead. Go ahead. This is the draft agenda. And with that, we will go ahead and get started. Dhruv?
[00:02:19] Dhruv Dhody: Thank you. Yaroslav, who's our IETF outreach coordinator, could not be here. So instead of that, I'm giving you a quick update. So this is not just an update from the leadership side. I think that you could find in our IETF open session where Yaroslav gave a outreach update of all the activities that that we have done from the leadership side, but there were lots of activities that I wanted to highlight also from the community side and that we are maintaining in the EODIR outreach wiki, which Greg will put a link to. So this is, again, an open resource reminder that, like, in if any other place our community members are already participating and if we can find good opportunities to also talk about ITF in those settings, we should take those up and try to do more of that. So just a reminder for that. Or something that I wanted to tee up was since we are now going to a new location in KL, so we should think about planning for that a little bit advance. Is there any outreach activities that we can also link up based on our upcoming ITF meeting in KL? That's it. Any questions that I can answer?
[00:03:32] Karen O'Donoghue: No? Excellent. Thank you Dhruv. Hi. So next on the agenda is IIESO Connection Program. Yeah, I need to share your slides.
[00:04:10] Mohit P. Tahiliani: Alright. Thank you. Hello, everyone. I'm Mohit. I'll be giving a brief update on the outreach activities that we do at India Internet Engineering Society. We conduct an event which is called connections, and it's a pre ITF event. We always conduct it before the ITF meeting to educate people about what is ITF and how they can participate. Of course, when we do it one week before, they cannot make it in person, but we encourage them to participate remotely and be a part of the sessions. The next slide. So I'll not speak about ISOC. It's there. It's a nonprofit that brings together different stakeholders and we partner with industry network technology council in US and with my university, which is called the National Institute of Technology Karnataka. Next slide. So Connections is a ITF community meetup. The main idea is to let people know what happens in ITF and what are the processes and how they can actively participate. The first such event was conducted in 2017. It went on continuously, but then due to pandemic, there were some gaps. We have again restarted it, and we restarted it in person, physical mode from 2025. This I this Connections meeting was held on July 11, just one week before we started the ITF here. Next slide. This was the eighth edition of connections, and if you would like to see the recordings and what was the agenda of the past seven meetings, everything is available on the link, which is posted in this particular slide. So you can just go through it. In the next slides, I'll give idea about what we did in this connection. So let maybe so these were some of the talks. We started with introduction to ITF, and we also told what are the new BOFs that are going to be discussed at ITF 126. Also shared the links for site meetings, hackathon, registration fee waivers, remote registration links. And then we had different kinds of topics varying from PQC, IP based geolocation, AI native networking, AI data centers, AI inference, talking about HTTP events query, EBPF, XDP, queue management algorithms, EVPN, and many other stuff, including measurements. The next slides are just some photos of this year's connections. We had about 40 to 45 people who attended in person. Unfortunately, we were not able to provide remote participation for this, but we have recorded all the talks. And in the next slide, I think I have given the link. Yeah. These are some other events. So we also conduct one another event called RFCs we love. And the upcoming RFCs we love session will be held at APNIC sixty two because APNIC is coming to India this time in September. So we will be hosting another session of RFCs we love. It is not full day event like connections. We just have two hour sessions where people come talk about if they have read any RFCs or if they are writing an Internet draft and if they need any inputs or any feedback from
[00:07:27] Greg Wood: the community.
[00:07:29] Mohit P. Tahiliani: Yep. And then the last slide, the next one is these are the recordings of connections 2026, and I have shared the slides with all of you.
[00:07:36] Karen O'Donoghue: Thank you. Yeah. The slides are on data tracker.
[00:07:39] Mohit P. Tahiliani: Yeah. And maybe if there's any some any feedback from all of you as to what are other things that we could do, we'll be happy to
[00:07:46] Karen O'Donoghue: take that. Thank you. I just have one really quick question. And, Dhruv, I know you're the one who's done a better job at maintaining the wiki prior to now. We're putting links to this information up on the wiki. Right?
[00:08:01] Dhruv Dhody: Yes, they're already there in
[00:08:03] Karen O'Donoghue: the outreach wiki. Perfect. Thanks. All right. Any other questions? Our next outreach report is the youth talent program at IETF one twenty five.
[00:08:22] Chunli Lay: Hello, Chun Li from Huawei. So I'm going to share the latest progress of the youth talent program. So in the previous IETF meeting in Shenzhen, we support 60 students who attend the meeting. And this time, we only support 15 because the cost is quite expensive. Yep. So yep. Thank you. And you can check the detailed information of the youth program youth talent program from the Wiki link. And totally, right now, we have support entirely around 70 to 80 students to attend an IETF meeting, which cost a lot. And 60% 6063% of them are PhD candidate, and 20% of them are master candidate. Yep. So they are all well educated. And the good thing is that they are all fast learners. Right now and to to now, they have submitted more than 30 individual drafts, so which is a very good news. Yep. And they have made more than 10 presentation in different working group or research group sessions. So to me, it's a really good sign. But we also need some challenge because, you know, we are spending a lot of money to support student. And after this year, we need to get more funds to support them continually. That's a problem. It's a truly problem for us. So we're trying to get some support from everywhere. So if you have any opportunity to support, thank you. Welcome to reach out to me. Thank you.
[00:10:13] Karen O'Donoghue: That's it. That's it. Okay. Are there any questions? Thank
[00:10:23] Jean F. Queralt: you.
[00:10:23] Greg Wood: Thanks. Just a quick reminder because we went through this pretty quickly. If you haven't signed in to Meetecho, please do.
[00:10:34] Georges Michaelson: One comment. You can see on the previous slide, if you put the previous slide down, there is a new URL where you can find the report of the Chinese Youth Talent program from ITF 125. So that's for your information. Yeah.
[00:10:57] Karen O'Donoghue: On the side.
[00:10:58] Georges Michaelson: Yeah. That's it.
[00:10:59] Karen O'Donoghue: Sorry. I switched because
[00:11:01] Greg Wood: If you if you have that, you can drop it in the chat.
[00:11:03] Karen O'Donoghue: Oh, yeah.
[00:11:04] Akanksha Gupta: Can put the link in the
[00:11:04] Greg Wood: Link in the Meetecho chat? Yeah. And everybody can get it. Yeah. Have a
[00:11:07] Georges Michaelson: great day. Thanks.
[00:11:18] Akanksha Gupta: Oh, I thought it was
[00:11:19] Karen O'Donoghue: on. It is early. And the part of the wiki is this we need to put this program up as well. You can talk to me afterwards and we'll put it up as an external activity. They already did it. They already did. Perfect. Alright.
[00:11:53] Jean F. Queralt: Morning, everyone.
[00:11:54] Karen O'Donoghue: Go ahead. Yeah.
[00:11:57] Jean F. Queralt: Thank you. Next slide, please. Or can I control in from here? Is
[00:12:12] Karen O'Donoghue: there somebody in the room?
[00:12:22] Jean F. Queralt: Sorry. We had a feedback looped over here.
[00:12:24] Karen O'Donoghue: You're also very faint.
[00:12:28] Jean F. Queralt: Am I?
[00:12:30] Karen O'Donoghue: Now now you're a bit better. So
[00:12:32] Jean F. Queralt: Is it better? Okay. Should I control these slides, or do you wanna do it for me?
[00:12:39] Karen O'Donoghue: I could pass control.
[00:12:42] Greg Wood: Mhmm.
[00:12:47] Karen O'Donoghue: Oh, I I've already shared.
[00:12:57] Jean F. Queralt: I'm no longer controlling this noise. Alright.
[00:13:01] Karen O'Donoghue: You should have control.
[00:13:03] Jean F. Queralt: Alright. So much. K. So this is the update on the, takeoff fellowship for the ITF 126 conducted by the IO Foundation. It is for you, dear. Alright. So we had, in this particular case, 22 submissions, from both APAC and Africa. We had no in person fellows in this occasion because we focused on, the remote participation, and we had 11 fellows that were actually participating during these days, again, distributed between Indonesia and Pakistan. As usual, when we do our our fellowship, we have four phases, selection preparation. We have the execution and then the evaluation, the participation. So in this case, we changed compared to the previous fellowship in which we had four preparation sessions. We condensed those into two sessions, and we, in fact, had the opportunity to conduct the second session in the morning of of the first day of the ATF since the time zone difference allowed us to have that in the morning here in Indonesia and in afternoon, check out the the kickoff of the of the hackathon. The fellows after their participation are gonna have to submit the final report as usual, and they have, of course, also submitted a number of daily check ins for the session that they have participated. I don't really see in my yeah. I can see it here. So as usual, they have some mandatory sessions that they need to attend, such as the new participants program, hot RFC, the IPF plenary, as well as the RITF open, and then some elective sessions and some personal sessions. What we observed was that this particular cohort was very eager in a number of topics, and their agenda was quite full. And we've been seeing them participating quite actively in in this instance. We also have been encouraging them to register to the corresponding working groups that they have interest in, and and we're gonna be helping them as well to follow-up with this. In this particular case, we've been running our fellowship in full in remote across the four Argo clubs that we have in in Indonesia. We spent about three to four days in one of the clubs, and then we moved to, the other one. By the way, hopefully, by the end of the year, we'll have another Argo club in collaboration with Kominfo. Looking forward to to that. And what we observed in this case was the the main friction for this fellowship had been the holidays. Most students are currently on a break, and and being able to mobilize them to be able to to attend the fellowship was not straightforward and even more so in order to ensure the the venues for to keep the clubs open, basically, because some of the universities don't have the personnel, and they don't really accept activities during the during the breaks. On the basis of of this, we've been revisiting our expectations as to how we're gonna be able to engage our fellows into the upcoming ITFs. And you can see there that in terms of the ITF the meetings, the first, the second, and the third, in person, we think that is gonna be, for the first one, moderate mainly because of permission. Students having to travel and whatnot, they will need permissions from the lecturers, and online is gonna be quite easy. For the number two, it's gonna be easier to have in person because of the holidays, interestingly enough. And online is gonna be somehow moderate because of the holidays plus the time zone. And then the third one is gonna be moderate in person and online difficult. So the time zone in this particular case, for instance, San Francisco, it's gonna be very, very difficult for us to to have remote participation because it's basically very late upline for for the students. If we manage to get some in person over there, then that would definitely allow us to to run the fellowship at least partially. In terms of upcoming meetings, definitely for 127, we are working into some in person and somehow doubtful about the the online path as I was mentioning. The types of difficulties are very, difficult to overcome. For 128 in Asia, then, of course, we're gonna be managing both in person and online, and we have a few ideas as to how to support the IETF in terms of participation. And taking the opportunity that ICAM eighty seven has moved their ICAM their AGM to Bali, we also are planning to have an in person and online fellowship and bring some students from Indonesia so they can see a general overview not only about the technical side of standardization, but also the policy side. And with RTF, we are always trying to support with engaging work with with academe. You guys have any questions?
[00:18:46] Greg Wood: Go ahead. Yeah. In that
[00:18:48] Jean F. Queralt: case, thank you so much.
[00:18:50] Akanksha Gupta: Go ahead. Wait. Hold a sec.
[00:18:51] Karen O'Donoghue: Go ahead, Michelle. Hi, Sean. Actually
[00:18:53] Jean F. Queralt: Yes.
[00:18:53] Michelle Cotton: May maybe a question for you and also for Shangli. For the participants you have in the program for 126, were any of them repeats from 125? Like, is it a continued program so you're bringing them back? Or every time, is it new people?
[00:19:15] Jean F. Queralt: So, yes, we have one fellow who continued. There was a bit of a miscommunication. Previous fellows thought that they could not apply to this fellowship. And there was also the fact that some of them were in politics. And so they had other commitments, and they could not participate. As I said, the the holiday season is gonna be a bit difficult for for this particular instance. Now they were expressing two of them were expressing their interest on on continuing the fellowship and the participation, and one of them was actually participating.
[00:19:56] Chunli Lay: Well, from Huawei. In the in this meeting before this meeting, around 30 to 40 students who attended the previous meeting submitted the applications. But, since we don't have enough budget, so we need to limit them to participate in this meeting. So for this total 15 student, we only allow nine students from the previous meeting so that we can allow six new students from the total 60 applications to come here. So, basically, like, you know, two out of three came from the previous meeting, and one out of three came from the new pool. Yep. Thank you.
[00:20:58] Karen O'Donoghue: There's also a question in the chat, if you would, of how many people were from Africa that participated, and how is it different from APAC participation?
[00:21:12] Jean F. Queralt: One single participant that was accepted into the fellowship and has not participated at all, has not followed up. He did the he did the preparation sessions and then has not showed up for the meeting.
[00:21:25] Karen O'Donoghue: Okay. Thank you. Any other questions? Excellent. Thank you.
[00:21:35] Jean F. Queralt: Thanks.
[00:21:42] Karen O'Donoghue: So the next item on the agenda is the hands-on GitHub tutorial that Mirja did on Sunday. Mirja, do you want to talk to that?
[00:21:52] Mirja Kühlewind: Sure. We've been talking a while about how to support people better with GitHub and what we came up with that we probably need some kind of live hands on session in order to help people to set this up. That was also my experience when I did this personally with some people. So we didn't do a huge amount of preparation. We really kind of had the people in the room and then went step by step through click here, click here, click here. We restricted it to 30 people, and you said, like, a little bit more actually showed up. Right?
[00:22:25] Karen O'Donoghue: We had about 31, 32 at one So
[00:22:29] Mirja Kühlewind: I think that was probably about the right size. I don't think a bigger room would have worked well. But there are definitely some lessons learned, there's definitely things we
[00:22:39] Sisters Representative: can
[00:22:39] Mirja Kühlewind: improve. Kevin Kelly nicely helped out and that worked very well, then we both could go around and help the people setting things up. So I think the plan is that we do definitely another one at the next meeting, and then there were also a couple of requests for remote presentation, which didn't make sense. I still don't think that makes sense, But like we said, maybe we can do an online version as well. And we need to think a little bit more about that, how to do that
[00:23:03] Karen O'Donoghue: online. Yeah. Also, with the help of the LLC, we did send out a survey to the participants that we definitely characterized this as an experiment and asked them to get their feedback. And I was talking to Greg about this yesterday, but we will be writing up a really short, you know, what is the basic process to request one of these and to do it and how move forward. So there's a little bit of process that we need to clean up going forward.
[00:23:41] Mirja Kühlewind: Yeah, didn't see the survey results yet, but I talked to some people. I think some were actually quite happy and was super helpful for them. Others were like, you know, halfway there. Some were maybe lost or whatever. But again, I think in general this was helpful and we're planning to do it again.
[00:23:57] Rich Salz: What was the breakdown in terms of IETF newcomers versus IETF experienced people learning new tricks?
[00:24:06] Karen O'Donoghue: Well, were I don't know the actual breakdown, but it was also on Sunday. So anybody that was a new participant participating in the new participants program was not there.
[00:24:20] Rich Salz: Sort of informally, did you recognize most
[00:24:24] Karen O'Donoghue: Oh, of the yeah. So I probably recognized a third of the people in the room. There were some very experienced IATF that I was like, oh, that's interesting. So I'm curious to see how the survey results go. And there were some people that I didn't recognize at all. There were people that struggled to get past the first or second step.
[00:24:50] Mirja Kühlewind: Yeah, I think not everybody fully engaged as well. Like I think some people who were sitting more in the back were probably just listening and not like doing it actively. So that's normal.
[00:25:04] Karen O'Donoghue: Any questions on this? Actually, Jean attended.
[00:25:11] Jean Mahoney: Yeah. So yes, I attended because I was curious to see, you know, who was looking for assistance. And I provided some feedback to Karen after the session, but like really quickly I think action should be covered sooner in a little bit more detail, and I recommend that everybody gets works with the dummy markdown document in the template, and we tell people to comment a lot of stuff out so the tests pass when they do their first commit. I think that would help a lot of people who are newer to GitHub to, you know, have success on their interactions?
[00:25:59] Mirja Kühlewind: So absolutely. So like one lesson learned is and also I didn't know how much time we have and how much time everything needed, so I think we rushed a little bit through it. But what we really need to do is like when the setup is done, we need to go to everybody and check if they are actually there. And we had the time for that, but I just didn't know. So, that's one lesson. The other one is we need to provide a little bit more material. I had like five slides, putting slightly more information or even giving people like a printed cheat sheet or whatever. And then I had one more thing. But anyway, yeah.
[00:26:35] Jean Mahoney: And also to help with helping people, maybe a room organized like this so maybe easier to walk around rather than everybody's facing the screen.
[00:26:47] Mirja Kühlewind: Yeah, mean this is a little bit the question as to if I said initially I want 20 people so we can actually help everybody, but then again not everybody fully engaged and so on. So like I'm not sure what the right number is.
[00:26:58] Jean Mahoney: Right. I didn't register because I didn't want to take an official seat.
[00:27:03] Karen O'Donoghue: So
[00:27:04] Jean Mahoney: there were more people in the room, I didn't want to take up resources. But I wanted to check it out and see how it went.
[00:27:17] Mirja Kühlewind: Yeah, roughly it was okay. My third point was like people also ask for like how to get continuous help. Like, is there a mailing list or a help desk or whatever, so we should think about this as well.
[00:27:37] Karen O'Donoghue: Did there's a question in the chat from Tariq about understanding there was a call for an online version. We've a little bit already addressed that. We'll look at that going forward. Michelle, you're in the queue, but is that for the last? And Georges? Yeah.
[00:27:56] Georges Michaelson: Related to the question on the job, I think it's I heard from people that attended the the door that was very useful. So thanks, Mirja. And, yeah, so my question was about also about recording. I don't know if it's useful to be recorded and show. I don't know.
[00:28:19] Karen O'Donoghue: I think the version that we did on Sunday was would have been hard to record. I think we would it would need to be more it it was really a walk around the room and help people with their
[00:28:32] Mirja Kühlewind: This is not set up as like a tutorial with slides and so on. It would be I'm not sure that recording is very useful. But for the online version, I'm actually thinking that we need to have even like a smaller number of people like 10 or 15, and then do multiple sessions if there's enough interest for it.
[00:28:55] Mohit P. Tahiliani: Yeah. Just one point. I think I agree. I think recording wouldn't work if the hands on is given. But just a thought, can we have a recording of the speaker done separately outside the ITF and share it on YouTube beforehand so that at least they have little bit of idea and they can watch it at their pace and then come. So and then we have volunteers to assist with hands on. Plus, they have a recording which we can keep it on our Wiki that they can refer to even otherwise. So, like, we screen share, zoom in, and show all the things in twenty minutes, and then put that recording out for them to watch.
[00:29:36] Mirja Kühlewind: Yeah. I think that's not a bad idea. We generally need to think about what additional material material we want to provide. Yeah. This was the first try to like actually understand what the problems are. We need to develop this continuously. So even for recording something, I would probably try a few online courses and then maybe figure out what really the right recording is.
[00:29:55] Chunli Lay: Thanks.
[00:29:59] Greg Wood: Yeah. Yeah.
[00:30:05] Participant: Plus one to what Mohit said. It would be good to have a recorded focus thing on YouTube. People can look at it prep, and it might also help others look at it.
[00:30:20] Karen O'Donoghue: Jay?
[00:30:21] Jay Daley: Thanks. Mirja, what of this training was unique to the IETF or different from any, say, YouTube video about GitHub?
[00:30:33] Mirja Kühlewind: It was really about using Martyn Thompson's template. So that's very unique.
[00:30:45] Karen O'Donoghue: All right. Thank you. The next item on the agenda is the working group chairs forum.
[00:30:55] Sisters Representative: We
[00:30:57] Karen O'Donoghue: had the working group chairs forum as regular. I think we had some very good discussions on a number of topics. And I think there were some follow ups out of that. There's a couple of structural things that Greg and I have talked about, about checking with Roman and seeing if we can get things restructured a bit so working group chairs doesn't show up as it to solve some of the Meetecho issues and things like that. I thought I was concerned about the AI topic that we had on the agenda. When we originally asked for it, I was concerned that it was going to be all about the policy and not having I didn't think we were ready for that conversation, and I didn't think the working chairs was the place to have it. But I thought Mark did a really nice job of teeing up the tools that he has, And I thought it went well. I don't know if there's any other comments. Thought your RFC report got a lot of engagement. So any other comments or questions on working group chairs for him? Rich?
[00:32:11] Rich Salz: No. Mark gave a demo on some tooling he's built to take IETF working group information and knowledge and incorporate it into an LLM, and then you can ask questions. I was impressed. And he's also gave a longer version of the same thing at the MAPRG. So when that video comes around, it might be worth looking at. And like all this stuff, it's on GitHub. But, yeah, I am glad we avoided the policy questions of what the IETF does about AI. I think we had a case lesson this week.
[00:32:58] Karen O'Donoghue: Alright. Sisters.
[00:33:04] Sisters Representative: Hi. Yes, we had two sister sessions at this ITF. I had a breakfast on Monday and a lunch yesterday. Both of them were kind of fairly free flowing without any kind of particular theme. They were just an opportunity for people to meet and to network. I thought they were both very successful. We don't really formally count how many people arrived but I think yesterday's lunch was probably the busiest sister session I've ever seen. Credit to Laura for getting us more sandwiches because I was doing a lot of apologizing. Thank you, Paige. So, I think with sisters, I think we've got a really positive thing going on in terms of providing the space for women and non binary people at the ITF in the meetings. I think we've found kind of less incentive for people to do stuff related to sisters out outside of the meetings. People are often very enthusiastic about it when you chat, but taking that forward is everyone's busy. But that's fine.
[00:34:12] Mirja Kühlewind: So, yeah. All all going well, I think.
[00:34:14] Sisters Co-Chair: Just one quick update that we mentioned at the Sisters' Lunch. Sisters has a charter which is up on the website. We drafted that, I wanna say almost three years ago and it expired for I think it runs through IETF one twenty four. So we're going to sort of initiate a bit of a on the mailing list on that. We I think, you know, we were having a discussion discussion with Flora revisiting why we have the charter and we were new chairs at the time and we thought it was good to sort of rehash with the group what we all thought the space was for. We think the charter still holds. So we're going to propose just sort of erasing the end date for it. But also, yeah, we'll be facilitating the chat in the sister's mailing list in case, yeah, people have any additional suggestions and brief update on that as well. Thank you.
[00:35:27] Karen O'Donoghue: All right. Any questions on the SISTERS events? No? Michelle, new participants update.
[00:35:38] Michelle Cotton: Okay. I will send my final numbers to the mailing list, but there were a lot of new participants at this meeting. Last time I checked, it was around 42% that were remote and on-site for people that have attended less than five meetings. That's that's huge. I continue to hear messaging that people feel welcome, and they're enjoying all the new participant activities that we have. People actually get sad when they reach their fourth meeting and they can't come and hang out. On the other hand, I was pleased to hear a bunch about it. I was pleased to hear about a bunch of new participants who just after one, two meetings have moved on from being a new participant. They feel that they have what they need. They're not coming to the new participant activities anymore. They're writing drafts. They're getting involved. I heard a lot about that. So I mean, think that's really positive news and that's what we want to hear. And yeah, so no like hard data or anything, just what I've heard. But I get the feeling that what we're doing now with this new program is hopefully working. We continue to make adjustments. We had some speakers move around this time, but everything was well received. We do have a survey out. I'll be reminding people one more time, and we'll look at that feedback from the survey. But overall, I think a great meeting for new participants. Any questions?
[00:37:36] Georges Michaelson: Yeah. Michelle, thanks. I didn't how many do you how many newcomers were in the meetings in approximately,
[00:37:44] Jay Daley: I think?
[00:37:47] Michelle Cotton: We were averaging, I wanna say, around, like, seventy, eighty for most of the sessions on Sunday, but I'll I'm gonna send the exact I took No. Just for Yeah. I took numbers for everything. I do numbers for sisters too. We actually count. So I have them going back for many meetings if you're interested. But yeah, I'll send them to the mailing list. But well attended. We did cap sign ups for a lot of these events due to spacing issues. So might have had more, but yeah, they were all full.
[00:38:47] Karen O'Donoghue: People seem to be more comfortable in working group sessions than they used to be. No. I think it's obvious when you talk to new people that have been through the newcomer sessions. The questions they ask are better questions. It's just better, I think. Right. Otherwise, it's already overwhelming. Even if you go to the new sessions, it's overwhelming. But this way at least they've had a little bit of background and know a little bit about why in the working groups we're doing things the way that we're doing. And so they will come up and say I want to write a draft on this. And I'm like, great. Or maybe a little like this. Yeah. So it's better. I think the questions are better. I think they're better prepared. I think it's it's got to be a better experience. I will add
[00:39:40] Michelle Cotton: to that. So I do meet echo test sessions prior to the meeting. They're usually two weeks prior to the meeting. Usually I do two. I added a third this time just to be a little more fair time zone wise because the North America times were all awful, so I added another one. A lot of people I don't know if people who register late and then don't realize that we had those or what, but we're talking about maybe trying to throw one in there on Saturday just so people can test their MeetEcho because we still get questions online. Remote participants like freaking out about them presenting and they haven't had a chance to test their MeetEcho. So we're going look at if there's something we can do there.
[00:40:31] Karen O'Donoghue: So Greg used to do this, right? You used to have MeetEcho sessions on Saturday and Sunday, right? For chairs.
[00:40:37] Greg Wood: Exactly. For chairs. And we encourage chairs to test with their presenters.
[00:40:46] Mirja Kühlewind: So, we have a lot of in MAPRG, we have a lot of first time, one time presenters. And it usually works very smoothly. I think the tooling improved. What we do is we actually send them a media guide. We tell them explicitly this is a different tool. You have to get into this. Like it's not working the same way. We tell them we will hand over control to you. You don't have to do anything. I think what we need is to train the chairs to do these kinds of things with the presenters.
[00:41:20] Greg Wood: Yeah, just to follow-up. I'm sorry we're getting a little away from new participants and back to chairs, but we do I think we do send reminders to chairs about this, but is there something else that we can do to encourage chairs to tell their presenters as well?
[00:41:36] Mirja Kühlewind: So we have an email that we use every time that we send to the speakers, right? So it's like two paragraphs or three paragraphs. So providing this or maybe actually we can automatically send this to speakers, I don't know. But then maybe also the working group chair is just talking about this once again.
[00:41:59] Greg Wood: Yeah, I'll follow-up. I'd love to see the email.
[00:42:10] Karen O'Donoghue: All right. Anything else for Michelle? No, Wes.
[00:42:19] Wes Hardaker: No worries. Well, one more thing for Michelle. So there are six board members here this time. Normally there's three. But there are three new iCANN board members that have never been here to an IETF before. They went to the new participant training program, and one of them said, can we get iCANN to do something like this? This is, the best newcomer training program he's ever seen. So I think that's a that's a major kudos that we're doing things right. They've all had a fantastic time. They're they're just thrilled. In fact, one of them, is the current chair of the government advisory committee, is probably gonna quit ICANN and just start coming to the IETF because he has to quit ICANN anyway. But he he's in love. So for the guides program, we had 22 matches. We matched even earlier than ever before, I think three, four weeks out. Normally, we don't get sign ups until very late. And something, Michelle, you put into the wording this time, We got a lot more sign ups really early. I don't know what you did, but do it again. So I think things went really well.
[00:43:21] Greg Wood: Two of the two of
[00:43:22] Wes Hardaker: them are remote, I think. I think we had two remote matches and one unmatched remote, unfortunately. But the only other thing worth noting is that so with the the guides interface now has, you know, guides marked as I'm always willing to help, which is something we always struggled with before. So now people can say, I'm always willing to help, which is great because that makes it easier to match. I don't even have to mail people. The downside is that nobody updates their profile, and a lot of working groups have changed. So I need to figure out how to get everybody to go log in and say, you know, these are my current working groups. I mean, at one point, Webtransport wasn't you know, listed as an area, which Robert fixed. But and then, you know, there's a bunch of people that that have accounts, but they don't say they're always willing to help. But having the plethora of ability of people that are just always willing to help is amazingly beneficial. And there was one more thing I'm gonna say, but it's really early on a Friday morning, and my brain is now off. Change now the tooling changes, Robert. That's a back end thing that that won't matter much. So the you know, the the one thing that we see very early on is, like, what's the current hot topic? It was definitely AI, of course, but even space. There was actually a bunch of people that were requesting space related guides help, too.
[00:44:48] Jay Daley: Thanks. I was actually going to go back to the new participant program. Thank you for that thing that the ICAM board members thought. That was great. One of the design goals that we had for this was to bring in experienced IETF participants and have them share their experience one presenter unable to attend, so somebody else we brought in Stuart Cheshire to do something, who nicely deviated entirely from the agenda and gave us a lot of talk about his own experience of doing things that went down very well, apparently. So as well as what we've got within the new participant programme, hopefully, that work of those people trying to understand what they're saying to the new participants is going to translate into more material that works its way through in other forums.
[00:46:08] Karen O'Donoghue: Any other questions on the new participants and the guides? Nope. I was so concerned about getting through the agenda that we have gotten through it, and we are now at any other business. Does anybody have any other business? Go ahead, Kaliya.
[00:46:29] Jean Mahoney: I'll
[00:46:32] Kaliya Young: get it out and pass it on. I actually did a whole research report on the IETF, and I had a couple discussions with folks about the possibility of linking to outside resources that are helpful in explaining the organization to others. I'm
[00:46:49] Karen O'Donoghue: not the
[00:46:49] Kaliya Young: only one who's done research on this organization. So I have have physical copies of it. It's online. And I would love it if it was useful to all of you in helping you understand yourselves and also help other people understand how you work. Because I think it's really remarkable and unique and special and good. And I'm not sure where this meeting is online. I can put the link into the chat if I knew where it was. But are you just in a
[00:47:29] Karen O'Donoghue: It's linked from the agenda. But I can help you.
[00:47:36] Kaliya Young: I went into the WebEx because it was sitting in front of me but that's not where you are.
[00:47:39] Karen O'Donoghue: No. Okay. Sorry.
[00:47:41] Greg Wood: I'll go find the
[00:47:42] Karen O'Donoghue: right place. You could also, if you wish, you could also post to the EODIR mailing list. EODIR has a mailing list. All right.
[00:48:03] Sisters Representative: So I think I have
[00:48:04] Karen O'Donoghue: your email address. I'll forward you the agenda from EODIR. That way you have the EODIR address and agenda. Is that okay?
[00:48:12] Karen O'Donoghue: All right. Thank you. Jay?
[00:48:16] Jay Daley: Yeah, Greg, you might want to do this introduction.
[00:48:22] Greg Wood: Yeah, was going to say, so I wanted to welcome Akanksha. She's the new research and insights analyst that we have at the ITF LLC and, as mentioned, has helped with surveys for various related programs. You also noticed that she worked on the ITF community survey, so we're we're really this is her fur this is she's also a new participant, so this is her first ITF meeting. So I just wanna make sure everybody knew knew who she was. And when you saw the name online, you can introduce yourself. So yeah. Did I miss anything, Akhaksha? Hi,
[00:49:05] Akanksha Gupta: everyone. Thank you so much for the introduction, Jay and Greg. Yeah. It's my new I am a new participant. It's my first meeting. So far, it's been great. The new participant program was really helpful to understand the workings and the processes of IETF. And, yeah, I'm I'm still learning, so thank you so much for being so inviting. Thank you.
[00:49:31] Karen O'Donoghue: All right. Is there any other business? No? So thank you all for getting up really early and we're going to end ten minutes early. Just a reminder to people, you can always send information on the various activities that are related to the EODIR mailing list. It's a pretty quiet mailing list, so you should feel safe to subscribe. And with that, enjoy your day.