Session Date/Time: 19 Jul 2026 12:00
[00:00:04] Bron Gondwana: I just had to I didn't know what it was again. Hold on. I'll make it up.
[00:00:59] Rich Salz: Okay. We got
[00:01:06] Michelle Cotton: just a quick reminder, if you could scan the QR code for this session, it is a different, attendance record since we have the morning session and the afternoon session. So we'd love to see you practice that. You'll be doing it all week long. So you become experts. Okay. I hope everybody, got something to eat, maybe rested your eyes a little bit, caught up on email, took a nice little break. Welcome back. We this is the afternoon sessions for the new participant program. We're gonna have session five, which is about Internet drafts and RFCs. After that, we're gonna have a session about the power of the community in the ITF, which is you all. And then we just do a very quick summary and wrap up, and we talk a little bit about what's to come in during the week and point out some sessions for new participants and just, yeah, tell you a little bit about what's going on. So without further ado, I'm gonna pass it off to our speakers for this session. So thank you.
[00:02:31] Alice Russo: Hi. I'm Alice Russo, and you are at session five.
[00:02:35] Rachid El-Bariqi: Mhmm.
[00:02:36] Alice Russo: This is about the work items of the ITF. This is part of the ITF mission, the high quality relevant technical documents. Next slide. I'm part of the RFC Production Center. I've been part of the RFC editor for a long time since RFCs in the April, and we recently crossed into the October. I'm interested in how ITF tools and education can help authors write clear documents. And my favorite RFC is fifty years of RFCs, which is some of the history of the RFC series, which we will not be covering in detail today. And here's Rich.
[00:03:28] Rich Salz: Hi. My name is Rich Salz. I've been helping with the newcomers thing for a long time. Disregard the philosophical rah rah stuff. I don't have a favorite RFC, but, I also got a new haircut since that was here.
[00:03:47] Alice Russo: Sure. Thanks. Okay. This is the note well. You've seen it earlier today. By participating in person or remotely, you agree to these policies. You'll see this a lot in every working group session this week. Please go ahead and ask questions along the way. Also, there'll be a chance for questions at the end. RFC is an acronym for request for comments. That was the historical purpose of the document series was to share ideas, share notes. To get a sense of your familiarity I'm just gonna go back one so we're not all reading that slide. To get a sense of this room's familiarity, can you raise your hand if you've read an RFC or a part of an RFC? So that's most people in the room. And then can you raise your hand if you've written an Internet draft before? So that's maybe less than a quarter or about a quarter. And then if you have an idea that you want to write into a in an Internet draft, but you haven't done it yet. Okay. Less than a quarter. Who has visited authors.itf.org, a website? Anybody? A couple people. A few people. So authors.itf.org is designed to give you the guidance you need to write an Internet draft, and a lot of what we're covering today is on that site. Okay. There are almost 10,000 documents in the RFC series. The official site is rfc-editor.org, and that site was recently totally replaced in May. So if you haven't checked it out lately, go check it out, please. A lot of what we'll be talking about today is about content on rfceditor.org, but RFCs, by their very nature, are freely available. And so they're available on a lot of URLs. Right? A lot of different places have RFCs. The the concept is that they're stable and they support interoperability. Some famous examples of RCs, TCP IP, TLS 1.3 recently published, QUIC. And today, we'll be going through a lot of aspects of RFCs. Where do they come from? What are they exactly? What's their status? What does it mean to be in a subseries of the RFC series? Relationships with other RFCs, and the RFCs don't change. So if there is an ish issue in it, an error in it, then it gets reported as errata. And the errata are now on a sub site. That's errata.rfchatter.org. They're also linked to from the main display of our seats that's on rfchatter.org. Internet drafts. Many, many more Internet drafts. This is what is used to write down your idea, share your idea, and then and anyone can upload an Internet draft. So as you learned today in the earlier session about standards development, this is how the working groups are moving forward with ideas, by writing Internet drafts and then multiple versions. This is the primary way that a protocol is advanced or an extension or any other idea. Datatracker.itf.org makes them available in various formats and shows the version history. In contrast to RFCs, Internet drafts are expected to change. We'll cover today how they're structured and the tools to write them, and they time out after six months and then move to an archive. Okay. The RFC series has existed for many years, so they are available in various formats. The bright, shiny new format on rfstater.org for the more recent RFCs is HTML that is has responsive design, works in different window sizes, will display SVG diagrams if they're available. And on the right side of the page has metadata about the RFC and also links to Errata. What's shown in this screenshot is the table of contents. There's also available an HTML file that's compact for download, but this is the most accessible and most beautiful of your RFC displays and newest. This on the other end of the spectrum is old school plain text. This is the original, well, originally, they were typed and distributed in hard copy only. Then plain text files. So this was this doesn't have any links in it. These files are still available. Plain text is still available. The series was the RFC series was created before online existed, and the series was created before HTML was defined. So we've seen the evolution of, the document formats and how they were stored and how they're made available. So, plain text files have been retyped, basically, for the super old ones. This is showing the header of a retyped, r f c one from 1969. This document series created the ITF or documented the creation of the ITF, I should say. And this is a HTMLized display, so, basically, taking an old plain text file and adding links into it. It's also available at that same route, the path, which is rfceditor.org/info/ the rfc number. So it has a similar layout on the right. You're getting the metadata about the r f c, and it's going to show here if this RFC has been obsoleted, which means completely replaced or updated, which means part of it has been changed. There's also a PDF available. This is the only paginated format, and it contains SVG diagrams that I mentioned earlier. For the newer RFCs, the PDF is very similar to the HTML format. For the older ones, it's just a PDF of the plain text. This header is the metadata at the time of publication, so it's not going to be updated to show later that this document has been been obsoleted. So you're best off if you wanna know if the RFC is current, you're best off with HTML. And this is the source format for generating the RFCs. It's a defined vocabulary. It's an XML file. The attributes here hold the metadata and the content follows. But for writing an Internet draft, you don't have to use RFC XML, which is this defined vocabulary. You can use markdown to create this XML file. And there's specifically a flavor of markdown called kramdown-rfc, which we'll cover more later. Okay. Status, what kind of document is this? Sub series is specifically within the RFC series. There's two smaller sub series, one for full Internet standard, one for best current practice, closely tied to the concept of status. And then stream means where did it come from? So did it come from the ITF? Likely, most RFCs in modern times are from the ITF. For example, in 2025, over 90% of the RFCs came from the ITF. So we're talking about the most common case and other cases as well. So informational. This is for use cases, applicability statements, framework, architecture. It's not the protocol itself. Experimental is a different status for, like, a new extension on an existing protocol. It can be run as a time limited experiment where then you report back. For example, IMAP extensions are often experimental, like IMAP message limit extension. Proposed standard is the most common status. Over about 70% of the RFCs published last year were a proposed standard. And the standards process is now only two stages. That's why draft standard is crossed out here. This maturity left level is no longer used. So your document can start as a proposed standard, and then when it's shown to be interoperable and widely deployed, then it could become Internet standard, the final standard stage. For example, WebRTC, all the core specs for it are all proposed standard. TLS 1.3 is proposed standard. For Internet standards, we have multicast listener discovery, p two, I p d six, and more keep going on statuses. We've got best current practice. So there are two two things that a BCP could do. One could be that it's about process. So for example, the ITF standards process itself is documented in the BCP b c p nine, or it could be about technology. For example, OAuth two point o security is documented in a b c p b c p two forty. And historic are are spec a specification that has been superseded. So for example, network time protocol v two and v three were moved to historic. The trick with historic is not every RFC that has been obsoleted has been changed to historic status. So an RFC could have been completely replaced by a new RFC, but the old one might not have had its status changed to historic. So when you're reading an RFC, you wanna make sure you look at the header and see, but has this document has this RFC been replaced? Because obsoleted is the word for replace. Then you wanna go look at the newer RFC. And the last category here is unknown. So this is catch all for the RFCs that were published before statuses existed. For example, RFC one host software that we saw earlier from 1969 is marked as status unknown in the sense that these defined categories for the standard process didn't exist at the time that it was published. K. Moving into subseries. Some's RFCs are Internet standards. These are the one that have reached that stat that status Internet standard, And then they receive another number. So they have their RC number, and they also have an STD number. And similarly, some RFCs are in the BCP subseries. They have status, best current practice, and then they're assigned another number. So they have a BCP number. So it's small here, but BCP two twenty six is about selecting the I yes. Go ahead.
[00:15:58] Nico Caballero: What is what is STD?
[00:15:59] Alice Russo: It so the question is, what is STD? And it stands for standard, the word standard. Yeah. And it's but it's reserved only for the ones that are Internet standards. So proposed standards don't have an STD number and are not part of the STD subseries. The whole yeah. So for an example of how these subseries numbers work, RFC seven ninety three was TCP. And if it was obsoleted several one of the the most recent obsolete was RFC ninety two ninety three in 2022, and that so when the old RFC was STD seven, but when it was replaced, now the new RFC is STD seven. So you can think of the STD number or the DCP number as a container. And in the container, it can go multiple RCs. Like in this example, the DCP two twenty six contains multiple RFCs, or sometimes it only contains one RFC. So but when that RFC ninety two ninety three TCP was published, then it became part of s t d seven. Publication streams are where did the RFC come from? As mentioned, most RFCs come from the ITF stream, but it helps to know these other ones exist when you're reading an RFC, and this is in the header so you can immediately know what where it came from. And each stream has its own process for approving documents. So, the ICF stream is the only one that can publish standards track or BCP documents. The IAB usually is the Internet architecture board. It usually publishes workshop reports or architecture documents. One of the most important ones is well, anyway, they've they've I won't say most important. Anyway, they published a bunch of documents. IRTF, publishes is the Internet Research Task Force, which I think you learned earlier today, and they publish the results of research. And their documents go through a research group process instead of a working group process. And the editorial stream is about the RFC series itself, the policies of the RFC series. And the independent submission stream is content that's about the Internet but has not gone through the official process of the ITF ID and IRTF. It goes through a process where the independent submissions editor, who's Elliot Leer, who's here this week, reviews the document and has an editorial board that reviews the document. And, he's also checking in to see where you've already taken your inner if you have an Internet draft that you submit to the independent submission streams, he's, excuse me, reviewing where that document has already been. Like, did you already try to bring it to a working group, and is the independent submission stream the right place for it? And there's information available on rch.org with more details about what that criteria is, what is to be included in the independent submission stream. Sometimes people just call it independent stream for short. And what content actually goes inside of these documents? Rich will tell you.
[00:19:47] Rich Salz: Okay. So one way to think of the ITF, excuse me, is we say we make we work to make the Internet better, and the way we do it is with words. Just lots and lots of words. We as you saw in the previous session, we don't have testing programs. It's all pragmatic. We write documents that we test out in the hackathon and clarify if needed, and then we it gets published. There's a two or three parts to the process of publishing, and then they're deployed and used. If somebody implements something wrong, it'll be on them. We don't you know, there's no enforcement mechanism. So let me talk about what's in these documents. Both the ID ID is the abbreviation you'll see all the time because Internet draft is just too long to type out. Right? So I I dash d. And in RFC, so these are the things that appear in the drafts that are developed usually through a working group and then finally published. Common elements of the title, author. Author and editor are sort of used interchangeably. Sometimes there's special meaning associated with it, but fundamentally, it's the person who wrote, put those words to I was gonna say paper, but that's stating me. When it was published, what its status or intended category is, it can change at any time. Someone could start to write something that's informational, and the working group will decide, no. This should be a new standard. So we would be on the standards track, proposed standard. If it updates or obsoletes any previous RFCs, those are noted in the header too. Some of the differences are if a working group it can be intended or it can be actually adopted by a working group. That's a semi formal process for a working group to say, yeah. We wanna work on this problem. Those appear you know, that a working group doesn't appear in the final RFC. The work an RFC is the product of the ITF or other streams, but we'll talk mainly about the ITF. What stream, if it's been adopted, where you intend it to go, how long it ex how long until it expires. Drafts automatically expire after six months. Oops. Oh, okay.
[00:22:11] Michelle Cotton: All good.
[00:22:12] Rich Salz: All good? All good. Okay. Sorry. They normally, expire after six months. What expire means is it just doesn't show up in some views of the archive. It's still there. Nothing is actually ever removed. It's a really it is a semipermanent document. So you can see on the upper right hand corner there, there's the the things that show up in the draft version of a document. Later on, it'll show Jay Daley wrote one. Okay. And then at the bottom, you'll see what the RSC actually looks like. It has, for the most part, the same kind of things. Everything is published. What do I do?
[00:22:51] Jay Daley: You wanna fix it?
[00:22:52] Michelle Cotton: I don't know if that I don't know if that was it or not.
[00:22:54] Rich Salz: Alright.
[00:23:02] Bron Gondwana: Okay.
[00:23:08] Rich Salz: Maybe we had a network hiccup.
[00:23:10] Michelle Cotton: Might have?
[00:23:11] Rich Salz: Might
[00:23:11] Bron Gondwana: be. Find it to be some people
[00:23:15] Rachid El-Bariqi: who could
[00:23:15] Rich Salz: think If only there was some engineers around who could, yeah, knew how the network worked. Yeah. Right. But it's
[00:23:25] Nico Caballero: yeah. I
[00:23:25] Rich Salz: would say, yeah, it's it's obviously a DNS fault. But
[00:23:30] Bron Gondwana: Hey. What? Okay.
[00:23:35] Rich Salz: Where were we? 916. Yeah. Do
[00:23:43] Michelle Cotton: you know where we're
[00:23:44] Rich Salz: Yeah. Try try it to 18? Yeah. Nope. Keep going.
[00:23:50] Michelle Cotton: Are you there yet?
[00:23:51] Rich Salz: Yeah. Not yet, but we can be there. Okay. We'll take some time. Okay. So the the yeah.
[00:23:56] Bron Gondwana: Right there?
[00:23:58] Rich Salz: So I'll go back on the quarter content. Somebody should've
[00:24:16] Bron Gondwana: stopped me.
[00:24:20] Rich Salz: Keep going. Alright. The
[00:24:21] Alice Russo: clicker's not working?
[00:24:23] Rich Salz: Yeah. Click.
[00:24:24] Michelle Cotton: I have to
[00:24:25] Rich Salz: Oh, she's good. If you sign it to me, I can test forward to where we are.
[00:24:28] Michelle Cotton: Okay. Ready?
[00:24:29] Rich Salz: Yes.
[00:24:29] Bron Gondwana: That's probably not done.
[00:24:31] Rachid El-Bariqi: Yeah.
[00:24:31] Michelle Cotton: Okay. Good. That was our first hiccup.
[00:24:36] Jay Daley: There we go. And we
[00:24:37] Michelle Cotton: get go for today.
[00:24:38] Bron Gondwana: So we're doing good.
[00:24:38] Rich Salz: Yeah. This is the first real day of of using it. The tool is really very good, and I'm sure it was a DNS problem. So, when you use the standard or the common authoring tools, much of the information, what we call the boilerplate, is sort of automatically generated, the status of the memo. What you see here on the right is the text that appears in the Internet draft. It says, you know, hey. This is a draft document. Don't use this to make purchasing decisions. It could change. This one is a product of the IAB, which is the architecture board, so it's not an official standard at any rate. Copyright notice. When you write an Internet draft, intending it to become an RFC, you are giving the IETF rights to do things with it. You don't give up any of your own rights, but you are giving the IETF permission to modify it, use it, publish it, drop it on the floor, whatever the IETF wants to do with it. And then the table of contents that's automatically generated. In the old days, we used to have to type, like, in ROF dot l l and dot I n plus five, and nobody counts page numbers anymore. Required content, similar to what mentioned before, the abstract. This should be a short summary of what the document is. A lot of that abstract is then commented into the intro copied into the introduction, which is a longer description of what the document is. The abstract should only be, like, a paragraph long. Right? Security considerations is required. Every document must have a security considerations document. There's a section. And even if it says, no, this it can say something as simple as this is all about security. For example, the TLS specification says, this is all about security. Or it can have something that says this does not, there is no impact on security at all. For example, one of the BCPs that describes how the IETF standards process works says, oh, this isn't there's no Internet security involved here. Typically, that will be a couple of pages that say, well, if somebody does this, then that information could be exposed. So you have sets of trade offs. Often, that's very, very helpful to implementers, and the working group will often come together and help you provide security considerations. IANA, the Internet assigned numbers authority, that's the group that assigns things like the protocol number that says HTTP is on port 80. DNS is on port, I forget, twenty three? Fifty three. I knew there was a three. They just they assign those kinds of numbers. So if you're making defining a new protocol or you're filling out an extension to an existing protocol, you have to describe in the IANA considerations where you want that number to come from. References, they're divided into two parts. Informative, hey. If you don't know what did if you're confused, this might be useful to you. And then normative, which says this thing builds on those, so you really have to understand those other kinds of documents. There were tools to, particularly for the references, make it very easy to generate reference lists and so on. Let's talk about writing a draft. This is the bulk of the work that members in the ITF the participants in the ITF and folks who want to participate in the ITF will do. Anybody can write one. There is a draft out there by Warren Kumari, I think, that says this is not a standard, and it goes through paragraphs of all those cute little phrases. And I can say, I can talk about my peanut butter and jelly sandwich if I want to. Anybody can submit a draft. You don't need any permission. All you need to know is when you submit the draft, you're giving the IETF rights to do things with it. Some people write a draft and never submit it because it's a useful construct or useful outline sometimes to get your thoughts on paper. Once it's submitted, it can never be removed, withdrawn, taken away. The rights are granted permanently. There have been a few instances where it was decided somebody submitted a draft, that was, like, blatantly offensive to large groups of people, so they deleted them. They have no formal status until they're adopted. In other words, they're not a part of a product of the ITF or involvement with the ITF. Oh, and there's the Warren Kamari draft. It says, here's the draft. I wrote it. It's nonsense. Okay. Step one, choose your language and tool chain. There are many ways to write a draft. Ultimately, as Alice said, the final input format is a dialect of XML or a particular subset of XML called RFC XML. Nobody cares about XML anymore. Right? It either it's JSON. Mhmm. You know? Either unless you're like a a doc a doc writer, and you're doing doc type stuff. It's either going you know, XML became either JSON or or something like that, or it became Markdown. So Markdown and in particular particular dialect of Markdown, called kramdown-rfc2629, is is what to use. So if you don't know what to do or even if you think you know what to do, just pick Markdown. The sub site authors dot I h f dot org has all of these definition, all of these examples of here's a list of all the tools we use. Here's the you know, should be one use markdown. It should be one there are also additions to Markdown that provide nice, simple ways to integrate with GitHub. So you can make submissions. You can make drafts. You can do a GitHub task that says publish my new update my draft and so on. All of that is done by one of the volunteers, guy named Martin Thompson at Firefox. People often follow the lead of the coauthors. Generally, when you're writing a draft, the first time you'll do is you'll you'll work with somebody who's either knows how to do it or has already written a draft that you wanna add to. So you work with the coauthors. Guaranteed they're doing markdown and probably using the GitHub tools. Step two, add your content. Required, recommended, general content. So, if you're writing a standard, the terms must or you're writing a protocol, the there's certain terms that have specific meaning. Must. Obviously, you must do somebody implementing the protocol must do this. Should. You cannot do this, but you better have a good reason. Must not. You must never do this. Right? Big eye the I e s g also has guidance on inclusive language. Happened about, well, turn of the century. Right? We used to see phrases like master slave, white list, black list. We try not to use those anymore. We try to also be gender neutral. NIST, The US government agency, used to have a spec that was really good about why you would want to do inclusive language. It got pulled back, but we have a copy of it, you know, stashed. Nothing ever disappears from the web. You must it's important to remember that. There's also glossaries on the RFC editor site about abbreviations and special terms that you don't have to explain. Right? I don't think anybody really knows what TCP stands for anymore. Right? Or HTTP. Yeah. You can put in special content diagrams, which are generally written as scalable vector graphics, SVG. If you're starting to do that, ask the community for help because there's particular dialects and rules. There are formal mini languages within the I used within the ITF. Augmented BNF, back as now our form, I think, that says you know, you can say, the must be followed by an a or an an, and there's there's rules and languages for that. Yang is a data description language. There's also CDDL and Cboar and stuff and so on. So there are other formal languages used within the document of the prose of your draft. Author dash tools is a separate site that has a whole bunch of tools on how to on how to verify things. It will look at your yang. It will look at that sounded obscene. It will sorry. It will look at your documents and say, are you do you have all the right subjects? Did you how do you have the right copyright notice? Did you does your a, b, and f follow the right structure? Did you start to use some terms that maybe you shouldn't have and so on? It also does a thing called the knit, knit tracking. Knit is like little pieces of fluff or or cat hair that you might pull off your clothing. I can't think of a knit offhand. Yeah. Typo. Yeah. A typo can be. Right? You know? Did you you spelled t e h? Did that really mean to be the? It will find typos. It will also find references when you start to use a reference. And it says, you're calling out this RFC, which is in standard track. Did you really mean for it to be informative or not informative, and so on? So, it will do that. Generally, you do this kind of thing often just before you submit a new version of your draft, because as it gets later on in the scheme, right, it's like software bugs. If you find and fix them after it's in production, it's a lot harder than if you do it during the initial development. Submit the draft. Again, the data tracker. Datatracker.ie.org. It can be abbreviated via dt.iet.org. That's just what I type all the time. There's a page, like, on the front after you log in, it says submit a draft. You just submit it, and you can up you generally, you wanna upload the the generated r c x m l. If you use the GitHub tooling, it's you can it's a one step, you know, click, draft, and it it goes in. You get back a confirmation mail that says it goes to all the authors saying, did you really mean to do this? Yes. Go to a website and click yes. I meant to nobody you know, two factor authentication. It will validate the draft. It will check with all the authors, make sure that what they submitted. And then once the draft is posted, it will go to the working group members and a special mailing list that says this new document a new version of the document came out. The documents, by the way, they end with dash o one, dash o two, dash o three, and that's how you determine the subsequent additions. Yeah.
[00:35:11] Nico Caballero: Is kramdown-rfc2629 the only tool that will do the conversion? Or and and that's why you're
[00:35:17] Rich Salz: kramdown-rfc2629 is the tool that does it the best. There are probably other tools. I forget there's you can write it in XSL. Pardon me? Yeah. Yeah. There's other markdown formats, but kramdown understands, for example, what the front matter looks like when you how you can you can sort of curly brace open two open curlies and then RFC number, and it will automatically turn that into an RFC reference. So that's without a doubt. That's the most time saving thing. And it looks like markdown. Every you know, paragraph submitted by blank lines, bullet lists have a dash in front of them. It's it's it's markdown with some extra additions. Yeah. Two weeks before the IETF, we stopped pub we stopped accepting drafts, and they start up again tomorrow. That's to give time people time to read the drafts that are of interest to them. Nobody it used to be everyone would, you know, print out all of the drafts and read them on the plane. Nobody has time to read all the drafts anymore. There there's just too many working groups and too much content. But the ones that are you know, you're probably focused on a particular set of things, so you definitely want time to have the drafts available. The authors website authors.itf.org has a whole bunch of things. It's got pointers to all of the tools that we know about. I think the ones you should use are starred. It has some of them are developed by staff of the I ITF staff. Some are developed by volunteers. kramdown-rfc is by Carsten Bormann, who is guy likes writing tools, as is Martin. Templates and schemas for RFC XML and templates for writing different kinds of drafts are also there, as is the full reference for RFC XML. So if you look at something and it comes out weird, you can look at the kramdown output. It'll change. If you generate a post script, a PDF file by the way, your markdown is embedded in the PDF file. You can't see it, but it's embedded there as an extra item. Okay. That's all the groundwork, and now Alice will talk about what happens after work group says we're done.
[00:37:29] Alice Russo: So from what you learned earlier today about the working group process, let's say we're in the ITF stream and your documents made it through the working group process and is approved for publication as an RFC, then it enters the queue for the RFC editor, which is the RFC production center to review your document. So at this point, the technical content should be solid. And so this is an editorial light edit, generally speaking. Occasionally, an editorial question is raised that points out that there's a technical issue. And at that point, the area director would be involved. And if necessary, the document can even go back to the working group to resolve the technical issue. But for the typical case, this is not happening. It's not the document does not go back to the working group at this point. The RFC production center is editing the source file, giving an RFC number, doing a pass for English syntax. One of the goals is clear, concise, easily understood documentation, and that that's what's happening. This is a copy edit format questions about any unclear text. We ensure that the I n actions are clearly documented inside the in the document if if your document required Iana actions. This means, registration on iana.org. There is an opportunity for the authors to review the edited document before publication. It's now called final review. In the past, you might have heard the former name AUTH48. The AUTH48 stood for authors 48. It is in fact not forty eight hours, typically. So, basically, at this point, you see each edit that the RFC production center has done, and you are checking to make sure that your technical content is still intact, which it should be. But each author who's listed in the header of the document approves the document for publication as an RFC, and then it's made available in various formats, some of which we talked about today. This week, I'm here with my colleagues at the RFC editor desk. You can come by with questions about RFCs or what we've covered today. I really recommend going to authors.itf.org that was mentioned and grabbing a template and and get started writing down your idea. Any questions?
[00:40:07] Michelle Cotton: Yes. If you could come to the microphone. And if you even wanna practice putting yourself in the queue and meet Echo, now's the time.
[00:40:18] Rich Salz: Good job.
[00:40:21] Nathan: Hi, everyone. I'm I'm Nathan. I I wanted to just ask a little bit more about the the interaction with IANA. I mean, hypothetically, let's say, would like an experimental protocol number for something that I'm working on with the expectation that maybe eventually it will become a production grade. I don't know what the word is. Protocol number. Could you talk us through how IETF interacts in either or both of those steps?
[00:40:46] Alice Russo: Yes. So IANA's here this week. So they and they have a desk, so you can actually ask them directly. But, also, they make a document available on iana.org that's called guidance to RFC authors, which is really guidance to Internet draft authors. And it really gets into, I think, digging into what you're asking and how they'd like it. But it's basically you write into the Internet draft the details of what you want, and they review the text.
[00:41:16] Bron Gondwana: Okay.
[00:41:16] Alice Russo: So before the document even comes to like, would be approved for publication as an RFC, IANA would have closely reviewed your text. Even if it gets on a working group agenda for an ITF meeting, they review all the documents that are on the agendas and send you comments and tell you if your IANA consideration section is not okay. So IANA considerations is the portion of text where you detail exactly what it is that you'd like, a new registry or a specific value in a registry, but you don't say a number of the value. You you put TBD, and they will tell you what number you get if your, if your assignment is made. But, basically, the IANA, decisions about what you want registered happen separate from the RFC production center. And by the time we get it, IANA has completed typically completed their actions, and we're just updating the document to match the registry. Okay. But in terms of guidance about what how to detail what you want, I'd say they have an RFC, which is RFC eighty one twenty six, but they have this more, what I'd say, more user friendly guidance that's on their website. Okay. And they're here. And Rich, do you have something
[00:42:27] Rich Salz: to Yeah. I was just gonna add. Many of the registries, and I think there there's over a 100 of them, they have space allocated for, you know, free for open use, experimental use so you can start to play around with it if you're developing something new or at the hackathon, you know, next meeting or something like that. But, yeah, work with see their their website. And often, there are registries that have designated experts, And IANA will deal with contacting them and say, does this make sense? You will have to approve this and so on.
[00:42:56] Nathan: So would it be fair to say that they are kind of a parallel process, but that the draft process is an entry point to getting an official assignment? Or is the entry point?
[00:43:07] Rich Salz: Yeah. Almost always, something has to be in a draft. Sometimes it's a provisional assignment waiting for the publication of the RFC. Sometimes a a draft is good enough. Sometimes other standards organizations request assignments, like the MIME types. W three c can allocate a new MIME type, for example.
[00:43:28] Michelle Cotton: And and different registries have different rules.
[00:43:31] James: Oh, good.
[00:43:32] Michelle Cotton: So I would check the registry. Look in depending on what you're asking for, check the rules for that registry. There are some experimental numbers that you can get ahead of time for an Internet draft. There's just different rules associated with it.
[00:43:47] Nathan: Gotcha. Thank you so
[00:43:48] Michelle Cotton: much. Hi.
[00:43:55] Rachid El-Bariqi: I'm Rachid El-Bariqi from Securus. I am the author of all the HTTP. My my quest my question is about, do I know registry? Because I have two level in the Infranchisement section. We have, for instance, and and some some sets of for. This can be INA registry is is a registry IAN has impact of the air of of the solution itself.
[00:44:27] Rich Salz: Does IAN have impact? They will yes. Some registries are just free text, and IANA won't care much about those. Like, the name of the mime type, that's a free text kind of thing. And IANA will just make sure it's, you know, not obscene or meets the legal the letter you know, what requirements are in the alphabet. Some the actual numbers matter a great deal, and so you want to you you know, as you're developing the draft and the working group, if it adopts it, is developing the draft, you wanna make sure that toward the end of that process, you might have to change what number you're using in your code.
[00:45:09] Rachid El-Bariqi: Yes. For instance, I I have a I have a three we suppose that we have three three tokens. Okay? Mhmm. The loop and the and the blocks. And there are two steps in order to define those. The first one is to define the lexical token. And after that, we we define the semantic
[00:45:31] James: Okay.
[00:45:31] Rachid El-Bariqi: For for for each one. And the the the passage from the lexical and semantic, we we should define logically. We should define a set of logical.
[00:45:42] Rich Salz: So when you do so if you're creating a new registry, you can define the rules and relations relationships between the different tables that are in your registry. But I would suggest at this point, you may wanna sketch it out and and talk to people.
[00:45:57] Rachid El-Bariqi: Okay. Okay. Thank you.
[00:46:02] Michelle Cotton: Any more questions?
[00:46:11] James: Alright. And, Go ahead? Yeah. My name is James. I actually put up my
[00:46:16] Nico Caballero: hand Good job.
[00:46:17] Bron Gondwana: Up there. Maybe
[00:46:20] James: you didn't take note of that. Alright. So I have two questions. Right? The first one is the other time I had once an RFC's approved, although I I think you were not the one that made the presentation, once an RFC is approved with a number, right, that it cannot be changed again.
[00:46:46] Rich Salz: Mhmm. Right. Yeah. So those yeah.
[00:46:48] James: So so my question is, we know that things evolve and change with time. Does it mean that if there is a new innovation which is still related to that RFC, we have to start a new RFC altogether. So I want you to clarify that. Uh-huh.
[00:47:12] Rich Salz: Sure. So there are two kinds of ways things can be updated. For example, DNS or TLS will have a they'll have different record types that you can add a new thing to. You can add a new record type or a new extension. Yeah. That you just document in its own RFC.
[00:47:30] James: Okay.
[00:47:30] Rich Salz: Sometimes there'll be a whole new version of something. Really? I p v four, v six Exactly. TLS one two one three. At that point, we say this updates that. Pardon
[00:47:42] James: me. Sorry.
[00:47:42] Rich Salz: And that old version, it may or may not be obsolete. It's quote, unquote marked obsolete, but people could still be using it. Right? Because we're not gonna Okay. You know, we're not gonna outlaw things. We don't do that. We're not the protocol police is a common phrase. So either way, they can be either additions where you just it will become in the metadata that Alice talked about
[00:48:03] Bron Gondwana: Mhmm.
[00:48:04] Rich Salz: An update to the original, or it will be something if it's a complete replacement, it will be an obsoleting of that other version. Okay. In the interim, we just collect errata. Yeah. A series of errata that mark with what we what we got wrong. And then when the new version comes out, we make sure that they're all addressed.
[00:48:25] James: Okay. So if the new version comes up, right, that means we have to send it for approval again. Like, it goes for approval.
[00:48:34] Rich Salz: It goes through the same process, the working group, the ISG.
[00:48:38] Bron Gondwana: Alright.
[00:48:38] Rich Salz: And then if it's an ITF document, the whole ITF's consensus. Yes.
[00:48:44] Bron Gondwana: Okay. Okay.
[00:48:44] James: Alright. Thank you very much.
[00:48:45] Rich Salz: Sure.
[00:48:46] James: Then the the second one is okay. So if I have an idea, right, and I I think it's something that I want people to contribute to the community Yeah. And stuff like that, what is the best approach to to to to bring it to the community? Gotcha. Is it HotRFC, Birds of the Sinfather, IRTF? HotRFC. What is the best approach?
[00:49:14] Rich Salz: So HotRFC is definitely one. If you haven't written anything down yet, because a HotRFC, you have five minutes to talk about? Last
[00:49:22] Michelle Cotton: Yeah. Or twenty minutes?
[00:49:23] Rich Salz: Like Yeah. So HotRFC, which is this evening. Yeah. This evening?
[00:49:28] Michelle Cotton: Yeah. Yeah.
[00:49:29] Rich Salz: HotRFC this evening, you get, like, two minutes to talk about it. You get three slides. Here's what I wanna do. If you're interested, come see me, or here's my email address. If you have a document that's more well formed, say you've been working with some other colleagues or in your organization, write it down as a draft. Hot RFC may not be appropriate since you've already got more. There each area has what's called a dispatch group Okay. Where they will to say, oh, we think this should go here, and they'll tell you. And there's there a lot of them are meeting. I think the first one is Monday morning. There's a general dispatch area that's covering security and and Okay. Heart. Yeah. Or speak to the people you meet that are in the newcomers, the connect quick connections.
[00:50:12] Michelle Cotton: I was also gonna mention that on the agenda, you will see two places where it says I b IAB new work help desk. So twice during the week, the IAB will have a little office, and they have a sign, and there's some times there. And you can talk to them about new work, and that's another place where you can ask them what do you think, you know, do you think hot RFC or dispatcher? They might have some suggestions of where you could bring your new new
[00:50:46] Rich Salz: work. Alright. Yeah.
[00:50:47] James: Thank you very much.
[00:50:48] Michelle Cotton: Yeah. Fabulous questions. Thank you. We're running just a little bit behind. We're going to take a quick five minute break, change over slides, give you a chance to get something to drink, and we are going to talk about the power of the community. Bron's going to lead us into our next session, so we will be here back here in just a couple of minutes. So thank you. Thank you, Alice and Rich.
[00:53:11] Bron Gondwana: Brand new best. Have to
[00:53:12] Rich Salz: upgrade just about
[00:53:13] Bron Gondwana: 20 things.
[00:53:16] Nico Caballero: But it's
[00:53:17] James: all Over on you.
[00:53:17] Rich Salz: It's yeah. Yeah. Yeah. If you do the mark if you go to GitHub Yep. And say, username is martin thompson without p, I dash d dash template, it handles all of that stuff automatically. So it's worth it. Yeah, it might be worth doing. And he's also got some useful introductory items, but it ends up it only works really on a, you know, experience environment. You have to take me to get something to happen.
[00:53:55] Jay Daley: Yeah.
[00:55:37] Bron Gondwana: Let me adjust this microphone to human height. There we go. Take all the way up, and it still needs goodness. That's got a second thing. Fantastic.
[00:55:49] Michelle Cotton: FYI, you know this has
[00:55:51] Bron Gondwana: a pointer. A pointer?
[00:55:55] Michelle Cotton: Ready to go to. Alright. So
[00:55:58] Bron Gondwana: it is.
[00:55:59] Michelle Cotton: Hold on. Let's
[00:56:00] Bron Gondwana: Yeah. We'll give people a second.
[00:56:03] Michelle Cotton: Official door closer.
[00:56:05] Bron Gondwana: Alright. I'm only wearing the hat so that I can say that people wear different hats in this community at different times. And then, you can already tell by the accent. So I'm Australian? No. Welcome to the thank you. Thank you. I live in America now. It's okay. It's the final session of the day other than some some cleaning up. So thank you for staying for the whole time or around about a third of the people who are here this morning, I think. But, you know, you've stayed for the best bit. So I'm talking about the power of the community. And some of these slides are about the details about how the community works. And part of what I'm gonna talk about is the fact that you're joining an existing community with an existing culture and some of the things about people. So here we are in the sixth session of the day. This is me. I've been at the ITF for nine years. I'm one of the rare people who came in as a chair at my very first ever session. So when I joined nine years ago, there was nothing like this. I got half an hour quick. Here's how the tools work that you're going to have to deal with tomorrow from my area director and nothing to give me a guideline of how to get involved with the community. But one of the first things when you join a new group is understanding. And a lot of the questions that I've heard so far today have been, I've got this great idea. I want things to work. And that's I mean, that's why we're here. We're here because I assume you've joined this because you either want to learn about what happens to the IETF or you have some great idea of how to improve the Internet, which is fantastic. And that's that's how we continue to grow. There are a lot of people here who already have some great ideas about how to improve the Internet. You need to persuade them that your idea is also good. The note well, you've seen it many times today. Part of what I'm talking about today is some of these specific parts of note well and how they work in reality. So I'm not gonna spend ages on this because you've already been through it, but we will cover some of those points. Alright. Here we are. Make the Internet work better by producing high quality relevant technical documents. So it has to be high quality. And if you come into the ITF saying, this is my way or the highway, I know exactly what it should be, you're gonna fail. Because we brought our brilliant idea JMAP, a protocol for communicating between clients and servers for email, at which has been extended with many things since then. And it got almost completely rewritten by bringing the expertise of the other people at the IATF to it. And what came out was a lot better than what we brought here. If we had said, it must be this, we would have wound up in some of the other processes that you'll see later for appeals and rejections and all sorts of things. And I have watched that happen a few times during my time at the ITF where someone's come in with a I've got this brilliant idea and it must be spelled exactly how I want it to be or work exactly how I want it to be. And the rest of the Internet must change to match my vision. That's not gonna work. Alright. High quality, relevant. Not every idea belongs in the IETF. Not every idea is going to make it through the IETF process. You have to persuade people that it in that it will influence the rest of the world. If your idea doesn't have any other support, you're the only person in the world who wants it, it's not gonna be implemented. It costs I was told when I came in here, it costs about a million dollars in people's time, in all the stuff that happens to get a specification from the initial part of the work through until it's published. A million dollars per document. That's everyone's time. That's all the effort that goes into it. That's the years that a lot of these things take to get through. If nobody uses it at the end, you've wasted a lot of people's time. So you have to have an idea that's useful to other people as well. And it will make the Internet better. Every one of us uses things that were built designed by the ITF. Alright. I think you've already seen I wasn't here this morning. Sorry. So I didn't see everything. But I think you've already seen how the community selects the leadership, this simple diagram here. Now on this diagram, there are a couple of people who are paid to be here. And most of these people are volunteers. And most of these people have a full time job somewhere else. And most of these people, the ones in in a lot of these fairly busy roles are being sponsored by their employer to have the time to do this. But they have their own areas of interest, and they have things that they've done. And you need to persuade these people that your idea is worthwhile. And so what I say to people that have come to the IETF, to you lucky people who are here in the room who have hopefully this whole week to meet people, to build relationships, to persuade them that you know what you're talking about, that you understand things. And hopefully, of that is reading other people's documents and seeing how they write so that when you write, it matches the style. It matches the kind of things that people know how to read and know how to understand. So that when it comes time for your document to be progressed, you've built that social capital, you've built those relationships the people will listen to you. And so more than anything this week, it's building those relationships. So these people here are real people with real lives. And the conversations you have with them in the corridor, the conversations you have over lunch, they're gonna be the kind of things that build those relationships more than just what happens in the sessions. That's the real value of meeting in person and being in this place. Alright. This is some of the technical detail. The NomCom is how all those roles get decided. There's a group of 10 poor suckers who have been selected to spend their time interviewing all the candidates who've applied for these positions and deciding who to choose for each of the roles. And so the these are very important roles. As you heard during the RFC process, any one of the area directors can say, I want to discuss this document further or I want to block this from progressing. They are the arbiters of the consensus, the decision makers of what actually the IATF wants to happen. And so that's important roles. And the way the NomCom is selected is a complex mathematical calculation over some lottery numbers that decide who of the volunteers actually gets given this job of interviewing a lot of people and spending a lot of time deciding. And so this is basically anyone who is eligible to volunteer. A lot of these new people won't be eligible yet because you don't have the experience in the IATF. I do recommend anyone who is eligible put your name in because like jury duty, it sucks, but it's also a very important responsibility. And so this process then chooses who gets to make the decision. The whole calendar here, I'm not going to read through all the details about it, but it's a lot of work. And at the end of it, you come out with the people who will be sitting up on the stage on Wednesday's plenary session, answering the questions from the community about why they made the decisions they did. Alright. The other thing here is, IETF has been around fifty something years. It's amazing that this organization exists the way that it does. And the organization has to protect itself from the kinds of silliness that occasionally come into groups like this. So we have an immune system. We have a bunch of rules about how people should behave. And you saw some of that. The note well is a bunch of instructions about how to work in a group of a thousand people who come from all over the world with our own backgrounds, our own cultures, own languages, and work together as one group. So these policies have developed over a lot of time and they change. Even just recently, this ITF community moderation draft was just published. The moderators group has only just been announced, I think it was a week ago, something like that. The moderation group. The the new moderation process, it just came out. There are, I think, or six people in that group. We haven't even worked out exactly what the policies of that group will be. But this is the group of people who have the right to to block people who have been complete jerks on the mailing list, basically. They show up every so often and interrupt the work of the group. And so the ITF needs to be able to keep working, keep progressing things. One thing here, you don't have any special rights above anybody else in this group. But by the same token, nobody here has any special rights above you. You are we're all equal. We're all representing just ourselves in the IETF. And so, anyone can object to consensus. Obviously, we need a pro a way to progress. You can't have one person come and say, I'm just gonna sit here and block the IATF for the rest of my life. That that would not be viable. And so there's there has to be a process for dealing with people who are just so disruptive that they are destroying it for everybody else. Alright. Code of conduct. This is just basic human decency. It is pretty easy to get by here. The ITF is very tolerant of a lot of things. So our immune system is pretty hard to trigger, but you do have to accept that you're dealing with other people. And what you do need to do is persuade them. And it's very easy to be unpersuasive, particularly if you show that you're not listening to feedback from other people. So listening to basically, listening to and acknowledging any piece of feedback from anybody in the entire organization is very valuable. Other people will be watching whether you're listening to feedback. When you bring your idea and people say, what about this? And you say, I'm just ignoring you. That's gonna not get you very far. Alright. A lot of authority is divested to the working group chairs. So the person who sits at the front of each of the rooms and I would recommend going to working groups outside your area, going and seeing how things happen in different parts of the ITF, and seeing how working group chairs manage their room, manage their mailing list. You can you can look at any mailing list. You can go connect to the IMAP server and read every single email that's ever been seen or go through the web interface and click through and see every single email that's been sent in any of the mailing list. So you can see how things happen here. And go and and soak in how the IATF works first so that you understand the culture, I think, before coming in and throwing your brilliant idea into the mix without having acclimatized yourself first. But a lot of this authority belongs to the chairs, and so the chairs will decide on consensus within their working group. The chairs will decide who gets to speak in who gets to present in the working group. So it's worth getting to know your chairs and getting to persuade them that you're someone who knows what you're doing so that they will give you space on the agenda, particularly in a busy working group that already has a lot going on. Why should they choose your work over other people's work? Yes. You want to make the Internet better. So does every other person here. And so it showed that you know what better is, I guess. Anti harassment procedures, this has been around the onboards team's been around nearly ten years now. They have a confidential process for handling harassment within the organization. There's a list of who those people are. David is here in person out of the three. I don't think I've seen him around, but he's he's floating around here. There are their pictures. Obviously, you could also contact them. The instructions on how to contact the ombuds team are available on the website, and it's they will handle your your report confidentially about anybody else in the organization. Obviously, if you have a problem with the ombuds team themselves, then that's where you go to someone else. Alright. Disputes and appeals. These happen. A few of them happen every year. Somebody's unhappy with how things have been handled in the ITF, and so they might take a dispute versus the working group chair and say, I don't think I was handled correctly there. If you have a problem with your working group chair, you take it to the area director. If you have a problem with the area directors, then that's where you take it to the whole ISG or to an appeal. Alright. And there's there's errors around process. There's technical errors. You can say there's something wrong with this document. I don't think it should be progressed because it's broken. This won't work. People in the IETF are very keen to hear about things that won't work. Nobody wants to publish an RFC that has an error in it. It means it doesn't work because guess what? You've got to start from scratch. You need to create a new RFC which replaces the previous RFC. This has happened in some of my working groups. I've had documents published, and then when it got out there, we realized there's this real interoperability problem. We're going to have to go back and replace. My first RFC, I'm in the process of building a replacement for because there's a couple of things in it that it just didn't quite work for what people wanted and so it hasn't been implemented and everyone says it's because of this one thing. I changed my mind on that because the working group told me to. But here we are. We're going back and and changing it again because it didn't work. Sorry. That would that just I went down a path. This will happen to you. You know? If people will say this idea sounds great, but it doesn't work for reasons, and they might be right and they might be wrong. So good judgment and and good taste is very important as well. Alright. Process. Almost always ask your working group chairs to reconsider. Working group chairs hate the idea of being dragged in front of the area director and also want to do the right thing. And we make mistakes. Working group chairs make mistakes and are generally happy to be politely asked, and politely is important there, to reconsider. Obviously, then you can speak to the area directors, and the area directors will speak with the chairs and try and figure things out. I've been through both of these processes. Thankfully, nothing I've done has been appealed to the ISG yet or any of the further things yet. We'll see. But, yeah, you can at at the very end, you can make an appeal to the Internet Society and say, I don't think I've seen one of them yet either. But there's a whole process, and these really exist. You can go and look at the appeals that have happened and the responses that have come back. And I think that's it. Questions? Come on. Sure people have questions. Come on up.
[01:11:34] Nico Caballero: I have a quick
[01:11:35] Bron Gondwana: one. Microphone, please. Alright. So I have a
[01:11:39] Nico Caballero: quick one. My name is Nico Caballero. I'm the gag chair at ICANN and board member along with two board members here from ICANN, by the way. Thank for joining. My question is, so very quickly, what are the requirements for being an IAB, member?
[01:11:57] Bron Gondwana: I don't actually know this that there are any specific requirements other than persuading the NomCom that that you should be an IAB member.
[01:12:06] Michelle Cotton: Leslie was an IAB.
[01:12:13] Leslie Daigle: Sure. Leslie Daigle. I was IAB chair a billion years ago. The general idea is to I mean, the IAB itself is a charter and has a purpose. It is a committee amongst the committees in in the organization. So have a look at its charter and see what work it does, and then and then do what Ron said, which is convince the NomCom that you should be selected amongst appointees. Generally, it focuses on having a broad technical understanding of the work being done in the ITF space and also being out facing for the organization. So I for example, interfacing with ICANN and other organizations. So more of a generalist body than the specific technical one: focus of the IESG.
[01:12:59] Bron Gondwana: Yeah. But you don't need to have had a specific degree from a specific institution or anything. You just need to put your name in the ring and and persuade people.
[01:13:11] Michelle Cotton: All right. Any other questions? Anybody want to practice putting themselves in the queue? No? All right. Thank you very
[01:13:24] Rachid El-Bariqi: much, Bron.
[01:13:24] Michelle Cotton: Thank you, Leslie.
[01:13:25] Bron Gondwana: You, relationships. Thank you.
[01:13:32] Michelle Cotton: Okay. In about, well, technically seven minutes because Bron got us actually back on schedule. We're gonna do, very quick, summary wrap up and just to look at the week ahead. I'm just waiting for my copresenter to get here unless he's hiding in the back of the room. I don't think yet. Okay. So I'm just gonna switch over the slides. We'll try to get that, up real quickly, and then, you'll be done for the day. So just one more session. Hang in there. Thank you.
[01:14:12] Bron Gondwana: Thank
[01:14:14] Alice Russo: you, Ron.
[01:14:16] Bron Gondwana: Yeah. Yeah. Yeah. That's it's important to recognize. Yeah. And not to break. Thanks
[01:14:26] Michelle Cotton: for getting us back on schedule. It's rare. It's great. Thank you. Thank you.
[01:15:14] Alice Russo: Thank you.
[01:17:42] Jay Daley: Okay. We're gonna finish off with the last session of the day, Ben. So thank you all very much for coming and spending the day here. I hope you've learned something or several things or lots of things. And as I said at the very beginning this morning, many people feel that they need to come back and do portions of this again. That's understood. You know, there's a lot to learn. It's very complex. And, hopefully, you've met and seen a few people and have a chance to ask some questions. And as Michelle will tell you, we have the the quick connections coming up later as well. So Michelle and I are gonna finish this bit off. So presentation that starts with the note well. You're all now used to this, seeing this slide here. So it was our goal then that you get, you know, general understanding of the ITF and the organizational structure, some useful information, some practical information for you to know when you're going around the ITF meeting and things, an understanding of the leadership, the resources and tools, the sort of practical things that you'll be relying on, introduction to the hackathon today, a basic understanding of the standards process. I know what you saw today looked very complicated, but there are quite a lot more bits to the standards process than that. And how to get started writing an Internet draft as well. And then the the important bit about what it takes personally to be effective in the ITF, which you will that can be one of the biggest frustrations for people that they start and they don't know how to you know, they might have some great ideas, but they just don't know how to turn that into something useful. And hopefully, you've learned a lot about that. It is you know, this is a a social organization in many ways. While it's good to have the ideas and be able to do that, you need to be able to talk to the people. And because most of the people here are engineers, it is generally a very direct conversation. You literally just go up to somebody and say, can I talk to you about this, you know, and start talking about the the topic you want to talk about? Now there those of us who don't do the engineering might start off with the how's your family, you know, how was your travel, that kind of stuff. But you will find us in the minority, and most people will be just, oh, I was just, you know, reading so and so. And on paragraph 17, you said this, and, you know, surely that bit should be that way around. And the other person will go, oh, thank you for spotting that. Yes. Let me talk about that. Just, know, those are the conversations you can have here. We have a number of bits about new partition activities. Yeah. You want me to take it? Yes. Go ahead. Oh,
[01:20:18] Michelle Cotton: gosh. Braun was Braun Braun, you're really tall.
[01:20:22] Bron Gondwana: He was. He's still there.
[01:20:25] Michelle Cotton: You're still tall. There we go. Okay. We are just gonna review real quickly the rest of the week as far as new participant activities go. After the session, we do have quick connections. It's best described as kind of like speed dating without the dating part. We have tables with numbers on them, and we post an experienced ITFR at those tables. And then in in, you know, five to ten minute intervals, we have the new participants switch tables, and you get a chance to talk to leadership, IAB members, ISG members, the IRTF chair will be there, and a handful of working group chairs also. So you get to meet a lot of people in a short amount of time. It does give you an opportunity where if you're looking for a particular person or somebody with particular expertise, we can talk about it and try to figure out who you should talk to. Even if they're not there tonight, we can try to help identify who you should look for during the week. Space is gonna be tight, so that was a pre sign up event. If you didn't get a chance to sign up, you can probably hover, and we can monitor the space to see how crowded it is. It is in the Celanese bar downstairs. So with the caveat that it might might be a little tight, might be a little cozy, we'll see what we can do to get more people in. Monday night, we have a new participant dinner. Again, that is also sold out, but we may or may not be opening a couple more spots. So I will send a message to the new participant mailing list as soon as we open spots, and it'll be a first come, first serve if you want to join that dinner. Alternatively, I will be posting a new participant meetup spot sign downstairs in the lobby. If you want to coordinate meeting with other new participants to go get a bite to eat, to go get coffee, utilize that spot to meet up and you can self organize. And then on Thursday, we have a new participant social hour, which kinda wraps up the week. We have leadership there too. They like to hear about your experience during the week, what what went well, what can we improve on. And so, yeah, please join us for that. You do not need to sign up for that social hour. Everything is on the agenda, so agenda is your friend. It is subject to change as far as location, so just keep an eye on that. And then I send out a daily message in the morning highlighting events that are specific to new participants or things that might be interesting. So you'll see those every morning, and hopefully, they can help you just plan your day. It's a clicker. Thank you. A couple other things just to mention. This evening, we have the welcome reception. Please join us there. There's some food and drinks and, again, another opportunity to meet people. We have HotRFC that also is this evening, and that's what we talked about earlier where people can present ideas. There's no question and answer. It's just a very quick lightning talk about a new idea. And then if you're interested in it, you can talk talk to that person. Maybe new ideas will be brewing, you have a new Internet draft or a new future working group. You never know. Sisters, again, we and Jay covered that this morning. We have a networking event on Monday morning, very early. Wednesday is the plenary. That's where we have the open mic with the leadership, and people can ask any questions. A host speaker series, that's the host of the meeting that does a a talk. On the agenda, we've got the speaker and the topic there, so you'll find that on the agenda. Sisters has a lunch on Thursday. And then on Friday, to wrap up the week, we've got a farewell reception. So this is all on the agenda. Our communications director puts together a blog post about new topics specifically geared towards new participants, what's interesting, what's happening. Check out that blog post. Might also help guide you to what working groups might be interesting during the week. And we mentioned area director office hours. Not all areas have office hours every single meeting. So just look on the agenda, and I will also include that in my morning updates. Yes?
[01:25:24] Nico Caballero: Quick question. What is sisters with a y? Sorry. I wasn't here this morning. I didn't
[01:25:29] Michelle Cotton: It's a group for women and nonbinary participants to get together and network and yep. Alright. I mentioned the IAB NewWork help desk. Again, there's two breaks, I think, that have that help desk available. You've got a new idea. You're thinking about it. Go talk to the IAB members. They are there to help. And yeah. You still don't know where to go get help? Registration desk, the secretariat folks are there. If you don't know what to do or where to go, come talk to us. We will help you. If you're having technical issues, go to the technical help desk, especially in, Rich and Alice's session about Internet drafts and RFCs. They mentioned the RFC editor desk and the IANA desk that that you'll find. I actually think one is downstairs and one might be upstairs. Upstairs. So just look for the table. Any questions? They are more than happy to talk to you. They're the they are there to help you. We talked about the ombuds team. If you're having any problems, we we surely hope there are none. But just in case, they are also there to assist you. But above all, we want you to enjoy your week, have fun, meet people, and, we appreciate we appreciate your time today. We know it was a long day. We know it was a lot of information. And, yeah, thank you for being here. We we had a good time. So thank you. And quick connection starts in thirty minutes. Are you a quick connection, bro?
[01:27:43] Rich Salz: I'll show up. Thank you. Well,
[01:27:49] Alice Russo: you know,
[01:27:51] Michelle Cotton: you're one of my, like, regulars there.
Session Date/Time: 19 Jul 2026 07:30
[00:01:49] Michelle: No. Thank you.
[00:02:01] Jay Daly: And good morning, everybody. Hello, and welcome to the IETF new participant program. I'll introduce myself in a moment, but you are here in case you're in the wrong room, which can happen at IETF meetings. You are here for the new participant program, and this is session one of a session seven session program that will take place all day. And this session one is the introduction, the welcome to the IETF, all of the tips and tricks about things, the gossip, that sort of stuff. K? This is the best session of the day. So I am Jay Daly. I'm the IETF executive director, and I've been in this job since about 2019. And I'm an Internet person. I started using the Internet roundabout 1986, 1987, and then worked for a long time in the domain name industry, did a little bit in the IETF, and now the executive director of the IETF. I am gonna be introducing well, introduce my colleague, Michelle, who you have had many, many emails from over the period of time introducing you and helping you to things. Michelle will be running the session throughout the day. And if you have any questions or anything about things, ask either Michelle or I about things. K? So what you can expect from today. So the IETF is a big organization, and it's complex, and it's broad in scope. Lots of things going on. It's a mature organization. It's built up over forty years. This is the fortieth anniversary of the IETF, and so it has detailed practices and rules. And all of these things put together can be quite a high barrier of entry for new participants. And so the we've introduced this program to help try to teach you the important things about the IETF because understanding what do I need to know now, what do I not need to know now is is complicated. So that you can become a productive and effective IETF participant and to reduce the chances of you giving up. We have data that we know from people that they start with the IETF, they find it far too difficult, and they walk away quite soon. So we try to avoid that by, you know, inducting you through this process so that you understand where things are going. We also aim to build a cohort of new participants. So we have this event where you can talk to each other. We have the the quick connections later today, and we have the dinner later in the week for you to meet each other and talk and build a cohort, you know, as you go through the IETF. We also aim to provide a head start in meeting people. There are lots of people in leadership within the IETF. There are probably 200 or something or more where you take all of the chairs and the various other people together, and they rotate regularly as well. So getting to, you know, recognize faces and know who people are is useful and helpful for you. So we aim to do that as well. So and then finally, we want to give you an indication of where the the hot topics are, what's being spoken about, what isn't being spoken about. So that's the plan. I give this session as the the the staff member who gives this, but the rest of the sessions, well, apart from one, most of the rest of them are given by community members, the same issue, who've just been doing this for a long time and who we think can reasonably communicate well. You know? So you'll hopefully learn a lot from the session as you go through. It one other thing, because this is such a complex organization and this is such a complex day of events that we we put together sessions to teach you, We we understand that many people need to do this in two bites. So they might come to, you know, half of it this time around, and then for their next meeting, to the other half. Nope. That's fine. That's understood. You you know, it takes a while to learn all of these things. So first things first, just to make sure we're all clear, we need to talk about MeetEcho because all of your participation relies on MeetEcho. That's a MeetEcho screen over there. This is MeetEcho. Everything is controlled by MeetEcho. So it is our it's our custom tool for remote participation, and it's what we use for tracking attendance and for identification. We the reasons why we talk about that later, why we need to know who's in certain sessions, largely related to intellectual property considerations and things. All sessions are linked off the I the the data tracker agenda page. There is a QR code in every session. That's the QR code here, which you can scan on your phone and which will open up the the MeetEcho web tool for you to be able to participate. And we have a little guide to explain to you how to use it. And I think Michelle has sent stuff out in advance, so many of you may be familiar with this. Just some little things for you to know straight away. So just get a quick understanding of the features. There are the normal things that you might expect. You can mute and unmute your microphone, turn on off your video, then there's joining and exiting the queue with a hand raise button. Those things are normal. Then we have the chat. Now that's slightly different in that you can use Meetico for the chat, but it this talks to a back end server of a chat system called Zulip, and you can also just use a Zulip client directly to talk to that server and engage as well. Then we have the show of hands tool. It's not a voting tool. We it's will be explained later. We don't do voting in the IETF, but sometimes this is used or regularly, this is used to take the temperature of the room to understand where people are roughly on something. Then we have the the map showing you, you know, the what's happening at the event and the note taking bit. People will talk about the note taking later, but taking notes during the session is a good way for some newcomers to ensure that they concentrate throughout the session, help them learn what's going on, and help them learn to contribute and, you know, get started in a session. And then we have the transcription that you can see there. We have, I think, four rooms that are human transcribed, and then the rest of the rooms are AI AI AI transcribed. And we've been doing that for some time now. And so so that's effectively MeetEcho for you to be able to use to go forward. Right. So about the IETF then. So the IETF essentially is a standards development organization. So its job is to for people to come together to agree on standards and publish those standards and other people to choose whether or not they wish to use those standards. Most importantly, it has no formal membership. Anybody can participate. So you can just join an email and participate. People participate as individuals, not as representatives of their employers. Now what that means is that you have no formal standing by by your employer. You know? Because we have no formal membership, your employer cannot buy, you know, a role for anybody in this organization. And that's very different from many other standards development organizations where employers will buy a seat on the executive committee or a voting seat or something for other people. We don't have that at all. So if you I mean, people do say, my employer is interested in this and talk about their employer. That's perfectly understood. I'm not saying you shouldn't do that, but, you know, it doesn't bring any particular authority there. Our standards here are driven by market based adoption. You know, we as as you will find many people will tell you, we are not the Internet police. We cannot say to people, you must use this standard. You know? It is up to the implementers to decide whether or not they wish to use one of our standards. And if we find ourselves writing standards that are not implemented, then that's a clear signal we are looking in the wrong direction and need to be doing something else. We are bottom up community controlled. So while I am the executive director, my job is largely to follow policies that have been designed by the community and written down as RFCs. It is I I do not come into any of the technical sessions and influence those sessions by, you know, or have any control over those sessions at all. None of the staff do in that way. We that and again, that is quite different from other STOs where you may well have a staff member who is working with the rest of the community on actively writing the standards. That just doesn't happen. We don't do that. So everything is controlled by the community here. And everything that you will see has been built by the community. And we have a the one of the last sessions of the day is talking about the power of community and how the community has built everything. Most decisions are made by rough consensus, not by voting. The one the few ones that are made by voting are made within specific leadership groups or groups that are appointed that have rules that say they will use voting, such as the nominating committee when it is deciding whether or not to appoint somebody to a role that would do voting. So and we will have a a long explanation about what rough consensus means later on as well. There is no formal role for governments in the IETF, though governments do send people. So we are a multistakeholder model. There are different multistakeholder models. So if you take ICANN, for example, the Internet Corporation for assigned names and numbers, a separate multistakeholder body that has a role for government, a role for civil society, a role for the technical community, and those things. We don't work that way. We work in a way where anybody can participate equally in that regard. And then the final thing you may have noticed, outside here, there are no sales booths, no salespeople, no sales related activity. The the people that come to the meetings are the people that participate in the meetings, whether they are whether they are engineers, whether they are policy people, whatever they come to participate, not to do a meta participation of sales or anything else. Okay? So at any point, if you wish to ask a question, go into MeetEcho, press the show hands thing. Michelle will spot it, and then you'll be able to come up to the microphone, you know, and ask a question. Okay? If it if you're struggling with that, just come up to the microphone. That this session's okay with that. Later sessions, you'll probably find people will ask you to ensure you do that. So this is the mission of the IETF, not the most inspiring mission, but technically accurate. So it is intended to make the Internet work better by producing good documents that peep that work, that people use and choose to adopt. So a brief history of the IETF. So the IETF itself was formed in 1986 by what was then called the Internet Activities Board as an engineering activity. It is the Internet Engineering Task Force. The first IETF meeting was attended by 21 US federal government funded researchers, and a number of them still participate. You'll still see number of them around here. K? So at least three or four of them, I think, are possibly here at this time. And if we can get some of them in to say hello, we will do that as well. Certainly, for the quick connections, I think later today, we tried get one or two along as well. Not sure. Maybe not this time. Right. The IETF initially met three four times a year. Now it met three times a year, and it's always open to the public. The RFC series, which the IETF now controls, started before the IETF, started with RFC one, published in 1969 by Steve Crocker of UCLA, to organize the working notes of the new ARPANET research program. And it's now actually gone over RFC 10,000 rather than approaching RFC 10,000. And Steve Crocker is still a participant in the IETF. Okay? The FTP, one of the early standards of the IETF or or the RFC series was defined in early RFCs, and RFCs became available via FTP and was therefore the first online publication series itself because you could get it through its own protocol, which is lovely. And for twenty eight years, it was managed and edited by the Internet pioneer, John Postel. It's moved on significantly since then, but his influence still stands in many ways. So I'm gonna talk now about the other participants in the IETF, and I'm gonna be basing this on data from our annual survey. Every year, we send a survey round to every address subscribed to one of our mailing lists, which is about 50,000. And we know that of those 50,000, about 7,000 people are active at any one time inactive in any one year. And we get generally somewhere in the region of 1,700 to 2,000 people reply to our survey that we send out. And we just published this last week. So we first thing we do is we ask people to categorize themselves as to what kind of participant they are. Are they a regular participant? That's straightforward. Are they occasional? Do they occasionally send something to an IETF list? Are they a reader only, somebody who just reads IETF lists but really doesn't engage? Are they a monitor? Somebody who doesn't who who gets lifts feeds but doesn't really look at it unless they sort of feel that there's something they need to look at. You know? So there are many senior managers in organizations who do that. You know? They have a copy of the list in case anything happens, but they don't read it all the time. And then we ask there are there are a number of people who cease to be participants in the IETF and then new participants, people who many of you haven't yet worked out which of the other categories you fit into. So as you can see, we are skewed here towards the readers and monitors when it comes to the the participants who responded to the survey. So this is while this is useful, the when you read the serve you need to read the survey itself to see what people think broken down by these categories. I can't go into that detail itself now. So this is the breakdown by region. As you can see, Europe and North America dominate and have done for quite some time. Asia, growing slightly. And certain areas such as Oceania, where I'm from, you know, are overrepresented represented compared to say Africa which is significantly underrepresented. This is, you know, voluntary adoption and a voluntary participation, but there are obviously barriers to entry that we will talk about that leads to this breakdown by region. Then we have the breakdown by age and breakdown by gender. So as you can see, this is an older organization. The median is somewhere in the 45 to 54 range for people. And there are still people, you know, significant number of people well over that participating. So over the age of 55, we still have a third or more of participants participating. Now gender is the the the bad story about the IETF here. We have less than 10% of our participants are women. This is changing considerably, particularly with new participants. Their demographic amongst new participants is approximately 25 to 30%, I believe, of of new participants are women. We we don't have any good figures to benchmark this against other than, you know, normal society. We've looked at software development where people have done a lot of work on gender benchmarking. That's about 25, 30%. But we're in our area, which is largely engineering, we don't have any good benchmarking figures to understand that. But this is still something that is changing and is growing over a period of time. Then we also ask people about their type of employment and the sector that they work in. And as you can see, most of the people here are employees. Then we have people who are business owners. And generally, those are small business owners. Many of them are consultants or people who used to work for something and now have run their own smaller business, independent contractors, and through to students and others. But to be clear, from looking at the bottom one, as you can see, while business is top, academia and research comes next. So that's because we have lots of employees of academic and research organizations who come here. Alright? So the employee bit doesn't necessarily mean all business. So when you look at sector, as you can see, then we still have healthy participation from civil society and not for profits and from government as well as from business and academic research. So we are truly multi stakeholder in that respect. And then this is just something to interest you. We look at when did people first participate in the IETF going back to 1986. And as you can see, we have a relatively good spread. When people are new to the IETF, they're more likely to answer our long survey, so that's why we have the long tail at the end of it. But still, we still have a lot of people who have been here a very long time and participate. And that is because for many people, being part of the IETF is fulfilling. They enjoy it. You know? It is the things they are doing, the work they are attempting to do and and produce is is technically satisfying. Engagement that you have to have with other people is, you know, socially satisfying. And it for many people, it fits with their careers as well. So people stay in the IETF for a long time and continue with the IETF. So a little bit about the structure of the IETF. The IETF structure is really quite simple. So, you know, we one of the things about the IETF is that it is intentionally designed to avoid centralized control except where it is meant to be centralized control and to avoid capture. So we have this structure, and this will be explained to you throughout as we go throughout this whole session today as we go forward. Because everybody has a different role and does different bits within that. Alright? So we can see my role just there. Alright? But I don't have control over the other bits. We can see the IETF chair's role there, who is the single most important community person, and you can you know, his role again is limited. So that's why we have this structure with various people doing their different bits, and also because this is a large and complex organization to do things with. So just going through it very briefly because we will come back to it later. I think I have it on the next page. So I actually I'll go back and talk through this through the diagram so you can see this. So we have the Internet Engineering Steering Group, which is the peak technical body for the IETF. Right? That is the one that runs the standards process. We have the Internet architecture board over here, which I'll talk more about, which has the long term view and doesn't manages much of our external relationship things for the IETF. We have over here the LLC, which is the company, the bit that I run that supports people within the IETF. We have over here the research group, the Internet Research Steering Group, which runs the IRTF, the engine the research part of the overall IETF. And this is where things get slightly complicated. We use the word IETF to mean two things. We use it to mean absolutely everything, and we use it to meet the standards bit of absolutely everything. Best not to have a conversation with anybody about that because you'll get 50 different views just from one person. So then we have a nominating committee, which is a group of volunteers that is reconstructed every year and appoints most of these people to these roles. And then we have down here the working group chairs, a 100 plus, a 150 or more of those. No. 250 of those. Sorry. Who run the working groups in which their work take place. So that's you know, this will be deconstructed over time today for you to understand things going forwards. Right. And the one that I missed off, two more that I missed off, are the IPMC over here, the IETF Trust or IPMC. This is a separate company of run by a small group of volunteers appointed that holds the intellectual property of the IETF and licenses the intellectual property. It's designed in such a way that it protects us from legal attack against the IETF by having that put separately. And then over on the end, have the Internet Society, which is our parent organization, which is the global charity that is dedicated to the development of the Internet across the world. So you'll be able to read on these slides later a little bit more details about them if you want to. So this is the IESG, the Internet Engineering Steering Group. And as I said, these are this is the peak technical body. These people here are called the area directors, and they are the ones that make the decision, each one of them, on whether or not a technical standard gets published. As a group, they make that. So the working group works on something. When the working group has reached consensus, it comes up to the ISG, and the IASG runs the program the process which determines whether or not there is community consensus to publish that. And a number of those will be coming to the Quick Connection session later on today. Then the IAB. So these are again are all community volunteers, and the IAB has a number of different jobs. It the IAB has been around for a very long time, longer than the IETF, but its name has changed and its role has changed. So it is currently, it is chartered as a committee of the IETF and an advisory body of the Internet Society. And it does these four things. It does architectural oversight, so technical programs, workshops, other things. It confirms appointments and has a lot of work on appointments. It appoints the chair of the Internet Research Task Force, the independent submissions editor, it appoints our external board members on things like ICANN and these things. And it does liaison coordination. And it is the normally the last body in our appeals process. It is possible to appeal once beyond that, but normally that's where our appeals stop at the IAB. This is just some examples of the IAB activity and recent work. It has run a number of programs looking at protocol evolution, deployability, and long term maintainability. It's run one on environmental impacts and sustainability of Internet technology. It has had a number of workshops, most recent one being the workshop on age based restriction on content access. And I think the RFC that is the report of that is just about to be published. It did another one back in September 2024 about practical opt out mechanisms for AI, and that we now have a working group that is working on that. And it has the IAB has published some very important RFCs. RFC eight eight nine zero, the Internet is for end users, is one of the most important ones. And then nine four one three, another one about maintaining robust protocols, undoing some folklore, I suspect, that have been built up over a number of years. So then now I'm gonna talk a bit about the Internet Research Tools Task Force, the IRTF. So this is much smaller than the IETF, and it's a parallel organization. And it has 16 research groups compared to the 100 and something working groups that we have within the IETF. And the the the equivalent explanation I'm gonna give you about the IRTF about the IETF will be given in the next session. Okay? That's I'm not skipping that. It's just that requires a lot more work to go into. So it has these 16 research groups looking at, you know, research things, systems and protocol aspects for our circumstellar environments, proper stuff that you need to think about in terms of research. And it has its roles the way it works is slightly different to the IETF. It's headed by the an IETF chair who's appointed by that IAB rather than appointed through our Hong Kong process. Research groups have a broader scope. So there are no deliverables, no milestones. They expect it to live for a long time. They can only publish informational and experimental IRCs. They cannot publish standards. And they don't require consensus because they may publish competing proposals or competing ways for doing something. It is intended to be proper research. And they have a separate code of conduct or supplementary code of conduct that covers academic integrity, research ethics, and other things. And it hit some examples of some of their publications, guidelines for human rights protocol and architecture considerations, and then a number of bits, you know, say down the bottom from the crypto forum research group about particular crypto algorithms. So now I'm just gonna talk a little bit about the administration and stuff behind. How am I doing for time?
[00:30:01] Speaker 2: Doing good.
[00:30:02] Jay Daly: Great. So this is me. I've met IETF, etcetera, as I mentioned. And I have four teams underneath me. The secretariat, Cheryl is part of the secretariat, manages IETF meetings and provides ministry support to IETF leadership and processes. Then we have the tools team. This is our, in fact, our software developers and architects who write and manage the software tools used by the community. Then we have the RFC Production Center. They edit and publish RFCs. So when an RFC has been approved for publication by the IESG or by one of the other publishing bodies, it goes to the RFC production center who then go through an editing process and then publish it. And then we have the bits that you might expect. We have finance, comms, finance persons over there, data analyst persons just over there, and some comms people as well. So to help you to to identify people, on the left, we have the secretariat. Now all of the staff are wearing badges that have this blue background color there. And just a little reminder to everybody, please wear your badge at all times. Okay? You will be challenged if you're not wearing a badge. We don't normally have any incidents, but we've already had one thief yesterday walking around stealing cables of all things. So please just wear your badge so that we don't keep being gassed. Are you a thief stealing cables? Okay? And then the RSC Production Center, they will you'll have a talk about them later on today, and only a couple of them ever come to each of the meetings. And they run a help desk that you can find down next to registration, talk about things. And you the sorry. Downstairs, you'll also find two other desks as well. You'll find the tools team desk where the tools people are, and you can they'll provide your assistance. And then we have IANA, which is a function of ICANN. So this is not run by the IETF. We have a contract with ICANN, but IANA runs the registries for IETF protocols. So the 6,000 or something registries, which have code points, you know, and various other things in them. And then oh, sorry. There's one other desk downstairs, which is partially manned, which is the network support desk as well for you to go up if you have problems accessing things. And also, is my normal plea. Please turn off hotspots on your phones. That we there are some people who have phones who have a hotspot that just blasts like that across the spectrum and like that. And the 15 people around them all complain to us, and it's just annoying. So please turn those off. So we do have a team that's worth noting, which is the IETF Sisters. So this is a team that offers women and non binary participants the opportunity to meet and exchange knowledge and experience that has a breakfast during the week and a lunch. And if you'd like any more details, ask Michelle because I don't remember the details at all. So a little bit about the funding of the IETF. The IETF LLC itself is a US five zero one c three not for profit. It is not a pay to play standards development organization, so you cannot buy any formal role. And that means that we run on a much lower budget, say, than something like the Linux Foundation, where they, you know, you to join the Linux Foundation at a particular level, you have to pay several $100,000 and then you if you then each of the individual areas, if you then want to seat on it, you then buy it, spend another, you know, and so and so and your bill adds up and they end up with a considerably more money than us quite quickly. So we receive a significant portion of our funding from the Internet Society. And this is using last year's budget, not this year's budget because I couldn't get around to changing it. So but it it hasn't changed that much. So that is the Internet Society give us this money directly. They're our parent organization. They support us. Then we have income from our registration fees for running these meetings and corporate sponsorship. Even with those registration fees and corporate sponsorship, we still run our meetings at a deficit largely. So we understand that the cost of coming to an IETF meeting is high, and we understand that people would prefer, you know, it to be considerably cheaper and that's not to charge so much. But we run, you know, on a tight ship in this way, and that's and we don't have any other form of income. We don't sell anything, you know, to anybody. And so that's why we have to charge that, and that's how our finances work. And then we receive donations as well. We get significant amount of free equipment and services. We for these meetings, we install our own network, and all of the access point switches and other things are donated to us by Cisco and by Juniper or HP as it is now. And we receive various other bits of free services. So Cloudflare, for example, support us and now has access to almost all of their products are free, which is great. So so we we couldn't easily survive or do what we do now without that that very generous support that we get from many of those companies there. And then we get individual donate donations and some corporate donations as well that help. So a little bit about our policies. How am doing with the time? You're good. Yeah. Great. So this is the IETF Note Well. This slide will appear at the front of every other session. I mean, throughout the week. This is the only session where it doesn't appear at the front of it because I need to explain it to you before I put it up there. Alright? So this is a reminder of the policies and processes of the IETF. It's not the policies and processes. It's simply reminding you of them and telling you where to go and read about them. So the first one here is about behavior. We have behavioral expectations that everybody hates in a professional manner and extends respect and courtesy to their colleagues at all times. And we have a policy that is the guidelines for conduct. We have a mechanism for dealing with concerns about that behavior through the ombuds team, which is a group of volunteers who are the single most powerful group within the organization. They are the people who can instruct me to exclude people, you know, permanently from IETF, for example, these things. And there will be more explanation about them later onwards as you go forwards. Then we have intellectual property rules, and I will talk more about those in a minute. Intellectual property rules are exceptionally important for every standards development organization. We can't get away from that. And by intellectual property, I largely mean patents rather than copyright. Copyright is important. I will talk about that. But something more the complexity is within patents. Then we have our detailed process information about how the standards process works, which is what the next session or the third session third session will be all about with some fantastic diagrams to help you understand it. And then just a note about our privacy statement. The IETF is an extremely transparent organization. So we routinely make public written audio, video, and photographic records of IETF activities. All of our mailing lists are accessible through an online archive, you know, except we have a a set of private mailing lists for things, but otherwise everything else is available there. All of these sessions, this is recorded. This session is recorded and will go on to YouTube on the Internet and be there forever in a day. Okay? So everything is public in that way and and while we do attempt to give people, you know, whatever control we can over privacy through the the red lanyard, we cannot there our legitimacy comes from us being an open and transparent organization so that people can see that things have been developed in an open and transparent way. We cannot allow a degree of reduction of that and still maintain our legitimacy as an organization. Organization. So contributions to the IETF. Almost everything that you provide to the IETF, and I'll explain what that is, is classified as a contribution And therefore, includes a basic grants of rights to the IETF for that contribution. So that means that anything that you say or write in a a working group session, you know, at the microphone or one of our meetings or other meeting session or any leadership meeting, anything written on an IETF mailing list, any working group or design team list, or anything issue submitted to a GitHub repository of the IETF, any of these things. Anything written is a contribution, and any documents submitted to the RFC editor or the Internet drafts function. And when you do that, you are granting the IETF through its organization, the IETF Trust, a perpetual, irrevocable, nonexclusive, a license that lets us use it. Okay? Alright? And the IETF trust then publishes a license about how other people can use it. So it's not, you know, you you're not it's not becoming open source or public domain giving it to us. What you're doing is you're giving the IETF rights to use it, but the IETF then controls how others can use it, you know, beyond that.
[00:40:16] Speaker 2: Right?
[00:40:19] Jay Daly: And as I mentioned, the privacy and transparency statement. So we publish and almost never redact following things, you know, names, organizations, and country codes of all meeting participants, audio and video transcripts of meetings. We, for example, have had somebody start a session in a publicly recorded session with some highly confidential internal slides for their own company. And, you know, it took us six months of discussion to decide whether or not to redact that in the video, by which time everybody and their competitors had a copy of it. You know? It it it's a big thing for us. Right? But we also don't sell your data, and we do keep confidential, you know, personal information, application to roles, various other things as you might expect. Okay? And for the Europeans amongst you, yes, this is 100% GDP compliant. Very happy to explain to anybody who thinks it isn't exactly where they're wrong in great detail. Send me an email, please. Right. So for patents and similar intellectual property. So
[00:41:29] Rob Wilton: we
[00:41:31] Jay Daly: participants are required to disclose the IPR. Alright? And this is what you're meant to do. The but we don't check this. Okay? This is a disclosure regime that we have. And it it's we also don't advise people what they should do when they see a disclosure. The the IETF tries to leave patents to individual participants to make their choices about and working groups to make their choices about. But we we what we do expect is good information for people to make their choices about these things. K? The IETF I think I've got a slide about this. No. I haven't. Sorry. I should probably add one. The IETF does prefer, through its processes publishing standards that are not encumbered by patents, but doesn't avoid that. So it is generally a decision by the working group as to whether or not it wishes to pursue a particular technological path that is encumbered by patents. And so that is the decision that people are required to make. And, of course, the the the problem then is if people spend a long time working on something, and it then gets published and people then disclose their patents that they've held, you know, for some time and haven't told people about, which is then a problem within the IETF that needs to be addressed. So that is why we have this requirement for people to there's quite a broad requirement for people to disclose their patents for other people to make decisions about. And this is what a disclosure looks like. So it is simply just who holds it, and anybody can make a disclosure. You can disclose somebody else's patent if you wish. Alright? So not not doesn't have to be your own. And but if you do disclose your own patent, then we do ask you if you can to tell us what licensing you would be aiming to apply for that. And that is very helpful for then for people to make decisions about patents. So we're not gonna talk any much more about patterns throughout this whole day. This is just a small bit of it. It's a technically complicated bit. If any of you are completely confused about this, I would suggest talking to somebody within your organization about this, about what this means just to understand a little bit about it going forwards. Okay. So that is the introduction to the IETF, and that's just to help you understand just how complicated it's going to be by giving you a really brief little introduction to the complications of things. Do we have any questions at all? If not, we're going to start the exam on the diagram. We may hand out gold stars to people as well. So any jump at the microphone. Introduce us behind you. Yeah. That microphone there. That's it. Introduce yourself, and then ask a question.
[00:44:38] Sam: Hello, everyone. I am Sam from University of Toronto. So in one of your slides, saw that the age group, the dominant age group was somewhere between 45 and 54. So I was wondering whether IETF really requires contribution from young people like university students doing PhD or masters because those age groups correspond to highly experienced people working industry. So I was thinking whether IETF has plan to increase the participation of young people so that it will bridge the gap bridge bridge the gap between, like, university resource and the real standards. Okay. So a few things there.
[00:45:21] Jay Daly: The IETF technology space is so broad that there is nobody who can count themselves an expert across everything. Alright? It is just way, way, way too big. It is full of specialists who work in individual areas and do things in different things. Some people can be relatively broad, but, you know, even then, they're still when you step back to the big picture, looks limited. So there is still and even within those areas where there are specialists, this is still a developing and changing set of technologies and a growing set of technologies. And so there is plenty of space for new people to get involved and bring new ideas and do new things. Okay? By the way, once you've asked the question, you're welcome to sit down, talk to the you know, people often will do that. So the the the IETF people choose to come to the IETF. The IETF does not invite people, and the IETF does not select people. So we can't go out and, you know, say to a university, please, can we have that student, that student, that student, that student. Right? It doesn't work that way. And we don't have funding that we can go out and give to people to to do that with because, you know, the the the the budget that we run on. So what we have is we try to provide a mechanism that when students and others do come and get involved, that they are welcome and engaged and listened to and, you know, their ideas are adopted and brought in. And this these sessions today are one of those. So we actually have increasing set of young people, students, and others coming in and getting involved in the IETF and being productive. We also have the older generation aging out a bit as well, you know, retiring, stepping back, you know, these things. So we are seeing that transition very much so. But it is an organic thing. It's not something that we can manage, well, which just can't manage. Okay. Right. Any other questions at all? No? Okay. Well, look, thank you very much. As I said, you'll see me around regularly. Please come along, ask me any questions if you spot me. Alright? And I hope you have a fantastic day today, and I hope you're able to continue participating in the IETF going forward. Thank you. Thank you for coming.
[00:47:47] Michelle: Thank you. So our next session is going to start at 10:30. So we've got about thirteen minutes if you want to stretch your legs, use the facilities, get something to drink, and we'll see you back here shortly. Thank you.
[00:48:21] Jay Daly: I mean, it it is it's discussed a bit in session three. So I need to go and read and see the session three session.
[00:48:39] Michelle: I just wanna be. Mhmm.
[00:48:42] Jay Daly: I forgot this discussion session
[00:48:43] Speaker 2: for her. But, yeah, I'll come to this. You don't
[00:48:47] Michelle: have to do it now.
[00:48:47] Speaker 2: Yeah. No. Alright. Thank you.
[00:48:49] Jay Daly: Alright. See you later.
[00:49:25] Speaker 2: If you
[00:49:25] Michelle: go to your new if you go to your participant dashboard Yeah. In there, underneath your name, it should say that you signed
[00:49:34] Jay Daly: that. Yes. Like, it
[00:49:36] Michelle: should be right underneath your your name. It's Monday night,
[00:49:53] Speaker 2: but it's currently full. Yeah. I I I
[00:49:55] Michelle: signed up. You signed up. Okay. Monday night.
[00:49:58] Speaker 2: So Monday night. Yeah. Thank you. I'm gonna
[00:50:03] Michelle: be sending out are you on the new participant mailing list? So I'll be sending out a message in let's see. Tomorrow is afternoon. Yeah. Tomorrow morning. Okay. But yeah. And it's in the hotel here,
[00:50:17] Speaker 2: so you don't have to go far. That's great. Thank you. And my second question was on the systems and things that I saw. So I actually have some information about talk about breakfast. So,
[00:50:28] Michelle: yeah, if you look on the agenda Yep. There's two sessions for sisters. The first one is tomorrow morning. Okay. It's a little early. It's before sessions start, but it's just a networking breakfast. Very casual and formal. And then on Thursday, there's a lunch. But you'll see both of them on
[00:50:45] Speaker 2: the agenda. Okay. Does require a session sign up? We are just coming. Okay.
[00:50:50] Michelle: Well, thank you very much for having Welcome. Nice to meet you.
[00:50:55] Sean Turner: Walter.
[00:50:59] Speaker 2: Where do
[00:50:59] Tom Satter: I find the
[00:51:00] Christian Dikoff: participant dashboard?
[00:51:04] Michelle: When you so when you when you register
[00:51:08] Sean Turner: Yeah. You
[00:51:09] Michelle: should have gotten a link that, it's like when you but you know what? Let me just check. I I can probably like to see the Wait. One second. Felix? Yes. Felix. Yes. Yes.
[00:51:31] Speaker 2: I'm registered. Perfect. Thank you.
[00:53:06] Michelle: Thank you, Jay. The struggle is real. Yeah. Well and as Jay said, that's often why many participants, like, they when you sign up and register for a meeting, can choose to be a participant for many, many meetings.
[00:53:44] Speaker 2: Because it does take,
[00:53:45] Michelle: you know, a couple to really
[00:54:15] Speaker 2: Yeah. It
[00:54:15] Michelle: it takes takes a while. I've been coming to meetings for twenty six years, and I'm still learning new things.
[00:58:16] Sean Turner: I thought it was one of these.
[00:58:17] Speaker 2: If you give up now, you don't
[00:58:19] Sean Turner: get the information. Right. Right. Yeah. Sit.
[01:01:30] Michelle: Sit. Yeah.
[01:01:37] Sean Turner: It's nice. It's not full of stragglers trying to get free food that are actually not newcomers.
[01:01:41] Speaker 2: Mhmm.
[01:01:51] Michelle: Alright, everybody. Can I get somebody so kindly to close the door in the back?
[01:01:59] Jay Daly: The the
[01:02:00] Michelle: sound travels into this room. Thank you so much. So we're gonna go ahead and get started on session two, which is all about participating in the IETF. And so I'm gonna pass it off to my friend, Sean.
[01:02:16] Sean Turner: Hello. Hey. So this is everybody's first time. Anybody nervous about being here and figuring out what's going on? I'm a little nervous. I've never given this presentation before, so we'll see how it goes. So we're all in the same boat. Alright. So my name well, I'm here. My name is Sean Turner. I've been involved in the IETF since about IETF thirty four. I've shared a bunch of working groups. Some you may have heard of, some you may use. Right now, the fun ones are like TLS and MLS and DOLT, which is, like, detecting unwanted location trackers. I'm a consultant. I have various clients. I've also been on the ISOC board of trustees and other places. I guess now I'm actually the little dots, right, that you guys have heard about, I'm a chair, so that's the blue dot. And this purple one is the IPMC, so that's the trust. We'll talk a little bit about that later too. Yeah. And so the funny part is how I actually broke in and got started in the IETF. I went to a meeting, and people were like, we need somebody to take notes. So I agreed to take notes, and it worked. And at the end, you know, it's back in the day when you had, like, overhead projectors, you wrote down a little plastic microfiche thingies. And so I had to go figure out where to send these things, and they were like, hey. You come to lunch. And Then I went to lunch, they were like, why don't you write a document for us? And that's how I got started. And now I've written, like, 70 RFCs at this point. So the best way, I think, to get really involved is to do something, and sometimes the simplest way to do that is to just take minutes. So think about that when you're when they're when the chairs are asking for volunteers. It also keeps you focused and out of your email because a lot of people, you're presenting and you look down and look at everybody and they're typing away on their keyboard, should really be paying attention to what's going on in the rest of the room.
[01:03:54] Rob Wilton: But
[01:03:54] Sean Turner: alright. Let's get to the fun well. This is the Note Well. You will see this at the beginning of every session. This is the policies and procedures and the IPR related things that you need to go through and need to understand this. You'll see this. Friday, it will be a joke because you will have seen it a 100 times. But, basically, the the idea is about the IPR stuff. If you see something, say something. If you know about an IPR thing, you're supposed to disclose it or don't participate, and that means get out of the room. There's code of conduct and any harassment stuff. If anybody if you if you feel like you're having a a issue, you can go to a chair. You can go to an area directors. You know, buds team. There's a whole process in place for all that. The standards process is another one that you kinda gotta follow on, but there's gonna be a whole session, I believe, on that actual process stuff later, so I'll save you that. The other thing is you're gonna be recorded. Right? So you got the little lanyards. You've got a red one. You're probably only gonna be photo if you're in a large group setting or if you're at the front of the room because that's how it works. And if you're presenting, there's a pink x up here. You're supposed to stand on that so you can be on the video. So this just kind of be aware that you're being recorded. And that also gets back to the first thing about the code of conduct. Remember, you're being recorded. So if you're being rude and jerky, it's gonna be on YouTube. Not all not always a good look. Alright. Email. I hope you like email. There's a lot of it. Some people hate it. But new peep newer people that are younger that come along, they're like, email. I use Slack. Well, email is how this place gets worked on. So there's a bunch of mailing lists. There's over 500 mailing lists, and people are like, oh, why don't you switch to the what the cool kids use, Slack or whatever the newest thing that is that's gonna come along? Well, the surveys that we do that Jay runs all the time basically consistently comes out and says, IETF mailing lists are really kind of the the thing the the thing that people want to use. I don't agree, but, you know, that's life. You gotta go with
[01:05:47] Rob Wilton: the flow
[01:05:47] Sean Turner: sometimes. Spent a lot of people spend a lot of time in GitHub now because that's where you can write drafts and do everything, but that's not the official place you do things. So, like, when you send an email about GitHub, you put a link in there and people follow it around. It all kinda works. And remember, all of your emails you send are contributions. They're in the public record. You can Google those from 1972 or something. Remember that. Alright. Mailing list. There's all kinds of types. Right? There's announcements list, which is like, hey. You know, a new RFC has been published. There's ID announce. So every Internet draft that gets published before the IETF, there's this huge spike. It's nice to be on that list, but it's a lot of email. You get get to be friends with your filtering mechanism because you're gonna get overwhelmed. And there's also the IRTF analysis, is, the sister organization, which I assume is also covered somewhere else in this presentation. Not this presentation, but throughout today. And there's working group, boss list. The thing to remember about that is for each working group, there is its own specific mailing list. Sometimes they kind of overlap, but mostly people don't cross post on on many of the mailing list because it's just kind of rude. Because many people are on multiple mailing lists, and you get, like, six emails from one person. You're kinda like, did you really need to send it to all these people? And then there's some other IETF general things. There's the IETF general list, which is just kind of like general community discussions, like, I don't know, whether you like the cookies or not. There's some architectural discuss. There's a last call list, which is specifically for when the documents go through the process and it gets to the point where it's going out before it's gonna be evaluated by the Internet Engineering Steering Group, which is the ISG, to make it an RFC. The it goes out to the whole of the IATF to get cross area review. So that's where the the the message goes out. And there's admin discuss, which is things like finance and policy, and if you're a finance and policy person. It's really interesting. If you're not, maybe they'll never join it. There's also nonworking group lists, which are sometimes technical and sometimes not. So they're not a working group, they're not a bot, but maybe there's somebody that's even before all that process is like, hey. I want a list, and they've convinced an area director to go off and get a list started to talk about a thing. And so they go talk about
[01:07:57] Rashid Buzir: the thing.
[01:07:58] Sean Turner: There are other lists, like the runners group and the sailing group and the whatever group, which you can also join to kind of find your little community of people. And then just meeting specific lists. So I hope everyone joined the one twenty six attendees because then you can find out about whatever the changes are. Like, you know, that could separate.
[01:08:15] Michelle: The new participant mailing list is most important.
[01:08:18] Sean Turner: Yes. That is that is true. Okay. So lots of mailing lists. Don't join them all. You don't have enough tiMeetEcho through all of them. Just gotta pick and choose and wade your way in there because just you'll get overwhelmed. Alright. Operations. It uses Mailman. I don't know that any newcomer is really gonna show up and be like, let me go get in the Mailman settings. But you get an account, and then you can get on. And so the nice thing about this is that all the lists that are there, they're all public. So, again, you can go back to 1970 whatever and look at the old emails. And you don't need to use, like, IMAP or, like, Outlook. You can just use your web browser to go through depending upon the interface, and we'll get to that in a second. The nice thing is about once you're subscribed to one mailing list, you're pretty much whitelisted into all the other ones. So if you wanna be on six mailing lists, you only gotta join one. So, yeah, that makes it easier on you so that you don't have to go around and, you know, spend a lot of time figuring out which ones you're on. You could just do it. This last bullet is very it's highlighted on purpose because what you'll hear during the sessions is we need to go confirm that on the list. So people will do a show of hands. We'll have a discussion. It gets into the, you know, heat of the battle, and then we're like, okay. It looks like we're gonna go this way. And then we'll go, well, alright. Now we're gonna go check it on the list. So we have to send it to the list and see if we can continue to get consensus there. And then that's ends up being the kind of, like, final way to do it. Now the interesting thing is before, you would and now we use a thing called show of hands tool. So you use the show of hands tool to make sure that people that are remote can actually participate as well. So it's kind of it's a little bit fair, and that kind of came about around sometime around COVID. Alright. Mail archive. So if you use the interface to get to the mail archive, and you can get to the data tracker or you can jump directly to it for mail archive at itf.org. And it's pretty much pick your poison right here. They they they made a user interface, and you can pick the way you wanna do it. You can do the different ways you wanna view and you wanna search. You can find links. You can download it. You can download individual messages, like, over there on the right, and then you can just hit reply, and your mailer should take care of it. What else? Yeah. That's just like the tool. Go in there, start poking around. You can't really break anything. So, you know, just get in there and poke around if you're looking for info. The search is pretty good. It's pretty fast, and it works. Alright. Okay. Email. So we send a lot of email. Think about email. Do you wanna write a do you wanna read a 16 page email from somebody about their particular thing? Probably not. You wanna have it short and kind of on point. Right? And that's really the best way to communicate and get things done is to write effective emails. Don't send email in anger. If you are excited and really hot to talk chat on a particular topic, maybe take a couple minutes before you send I often write email and don't send it. It's a good plan. Threads and useful subject lines. Yeah. I mean, you know, if you really want if you really want somebody to read it, you should pick an interesting subject line, but not so interesting that it's inflammatory because then that's bad. Right? But it's it's usually you're trying to figure out how you're gonna kind of scope the conversation. And so you're the one that's kind of in maybe if you're starting the thread to try to figure out how to get in to get your point across. And you can do that by some good ways and some bad ways and following along what's on the list and watching what other people do, that are effective at getting their eyes ideas across, you can try to mimic what they do. There's this whole idea whether you top post or bottom post in an email. You know, the etiquette here is you're supposed to do it underneath so that people will read the original message, and then they will get to your your post. Some people do that, some people don't. The other thing is you can cut down on the amount of text that's in the email. So if you only wanna reply to a particular point, you just put snip, s n I p, and clip off the rest of it because it saves everybody else who's kind of, like, scrolling through the messages. They don't have to go through the rest of it. It just make kinda makes things a little bit faster. Alright. In your corporate environment, you might have some really cool backgrounds with some nice tags and, you know, on the bottom. You don't need any of that here. Most people use the old school emails, none of that stuff. So there's not pretty text. You're not highlighting things. None of that gets done. It's mostly just straight, you know, basic non HTML kind of stuff. So, you know, send those kind of emails at your own risk because you might get some comments back. But that's pretty straightforward. Alright. The data tracker. So there's the itf.org mailing list, which is, the main list. I never go there. There's no reason to go there. So I get a data tracker at itf.org because that's where most of the work gets done. So it's a document management system, Ryan. It's where it's like your own bespoke system that keeps track of the day the the the documents, the status, like all of that stuff. If you do do go to other standard development organizations and they have their own particular flavor or whatever, you might like it, you might hate it. This is just the ITS version of that thing. The decision support team, it it's it's basically where, again, where the the the the ballots for the different documents go through, and you can track all the various different states. People, if you're here, you probably got a data tracker account already to get in because if you wanna log in to anything, you gotta get gotta get an account. And so it's pretty straightforward. There's also groups, you can find the different bodies of different areas, the working groups, directorate, the research groups, the teams, etcetera. And so you can find about two pages about them, like who's on them and what they do and the charters, etcetera. Again, the documents is where most people jump directly to. And so if you go to the working group, it'll jump directly over into, like it shows you the documents, not the charter, and then you have to, like, click around to figure out which one you want. The meetings, obviously, because you got here, you probably ended up over there at some point. It's nice because it has the agenda in there, and you can you can can you pick through it. And we'll get to that in a second. There's other things up there too, like IPR disclosures and liaison statements, etcetera. Alright. So this again, this is the the front page, what it looks like. Again, you can't because Jay's got his name up there. You can click away. You can't really break anything. So it's just it's fun to get in there because as you get more privileges, then you can't break things. I can break things. I don't want to. I get very nervous. And so, again, this is the authentication provider. So, again, if you're gonna go to a session, it's gonna ask you to log in. If you don't have a data tracker account, it's a nonstarter. But if you're here, chancellor already got one. The same thing with the mail archive. So when you log in to the mailman thing, it it gives you a you you you you get logged in and and then it it, like, sets your privileges, you can click on, like, the list you own, the ones you're you're part of, the ones you moderate, etcetera. There's bunches of stuff in there that you can get to, wikis, the notes at itf.org, which is where most of the notes get taken for the various sessions. There's a Zoom interest will zip that instance, which we'll get to in a second, and then the YANG catalog of stuff for, like, management. They've they've got separate accounts for the mailman and the data tracker, and eventually, gonna merge all that together. So that'll be fun. Luckily, it's not me. Alright. Meetings. Thought you're here. This is great. These happen three times a year. They're sometimes referred to as a plenary meeting. I've never used that term. And they rotate around in various parts of the world. So this time, it's in Europe. Next time, it's in North America, and then we'll have an Asian meeting. And kind of where you end up is just they have to go do some negotiations. They do a site survey. They figure it out, and it gets announced. Usually, they try to announce them as far in advance as they can get away with so that you can do a little bit of planning, but it's at least it's usually announced at least one cycle in advance. So working group sessions, there's approximately a 130 working groups. That number is pretty steady. When stuff comes and goes, it pretty much just stays at a 130. It's interesting. I don't know why that is, but that's what it is. Birds of a Feather, which is like a pre working group. It's where people get together to, like, talk about it. It's they and I think you I suspect you'll get into that later, one of the other sessions. The research group, they, again, have about the same amount, about 16 research groups. That's part of the research groups are part of the IRTF. It's different from the IETF. They have slightly different rules. And then there's a big plenary that happens on Wednesday night. It's it's fun because it's an open mic session, so all the leadership has to be up on stage. And if anybody wants to say anything from, like, I like the cookies at the session to you guys don't know what you're talking about, people can get up and and and do that. And there's also other area, like open meetings. So, like, the IAB has a session where you they just go and they they have a particular set of presentations lined up, then you can go and ask them questions. The hackathon, which is happening basically across the across the hall, is going on. There are social events. Sometimes there are social events, but a lot of times that's related to how much funding because it's not free. And so if you have a corporate sponsor and you would like to write a check for having a party, let me know. We'll get you to the right people. Some of them have been fun. We went to one in Orlando, Florida, and they rented Harry Potter World for us. That was pretty cool because it was just us, and that was pretty neat. And I guess in China, they had some really interesting ones. Know? When money gets tight, funding the social events goes away. And then it's kind of like do your own thing. There's also stuff that happens here with respect tutorials and deep dives. Like, you'll like, hey. How does BGP work? Well, they'll get the guy that wrote BGP to explain it to you, which is kinda neat because it's like a horse's mouth. And that's been useful in times because sometimes people don't always get the full story, and you can actually talk to the people who help bury the dead bodies when the when the protocol is developed. Hot RFC is where somebody hopefully has something in RFC that they think is super interesting and I think that they want you wanna know about. So it's, like, kinda common, you know, let me tell you all about my thing. And they try to make it a little more entertaining than just, here's my protocol. So because they're trying to get your attention and get you to come to the session. And then there are side meetings, which are not official meetings of the IETF, but there's, like, another there's, like, another page that kind of lists through those. They're not supposed to clash with this the regular working group sessions, but they sometimes do. And then various ones, there's also applied networking research centers, research prizes at the IRTF open meetings. And that's kinda neat because a lot of times it's like testing and things that they've, like, taken the protocols and actually done stuff with. And so that's kind of interesting. So you can actually find people that did the stuff. Alright. Standard setup. So when you're a chair like me, sit at the front of the room. And, basically, there's two screens at least, and then there's one for the speaker. So you can you don't have to stand here and, like, do this. Then you can't hear me when I talk. So it's better if you kinda stand here and focus this way. Again, there's a big pink x up here so you can stay on camera. And then the queues in the microphone. So if you wanna get up and say something, you just get up and say something at the microphone. Before you get up, though, you should be logged into the on-site queue management tool. And so you basically put yourself into the queue, and then you can walk to the microphone, and they'll say, John, and you kind of jockey for position with everybody else to get to the front of the queue. You talk, and then when you're done, you take yourself out of the queue. Again, we do that to support remote attendees so that we can kind of, like, manage the mic line because people will be dialing from all over the world, and it's hard to be like, hey. Am I next? Are you next? And some of the rooms that are bigger, there could be multiple microphones. Like, if you go to the plenary, there are probably, like, six microphones out there, So that's fun. So the person at the firm room is trying to figure out who's who. So it's kinda fun. Again, fully supported remote sessions. Everything, again, is recorded and transcribed. If you sit tuned close to a microphone and you're over there, you will note that your conversation will go into the record. So maybe, you know, don't talk about your corporate secrets right next to the microphone when they're recording. There's power strips on the floor. There should be. So, like, usually, you can plug in. If you've got a newer laptop, maybe it'll last longer than five minutes like the one I had for a while. So it's good. And typically, it's funny in the in the sessions. Usually, the first couple rows, there's tables. And oftentimes, those are supposed to be reserved for the people that have read the drafts or written the drafts. I don't know that it's followed as much anymore. And then the the pro tip here is these rooms are smaller than some of the other meeting sessions we've been at, so go early if you wanna sit at a table where you can not burn your legs with your laptop. And, again, as I said before, everybody uses the MeetEcho thing to log in and and sign in to make sure you can get it in the queue and and do all the the various things you need to do. What's next? General meeting etiquette. It says wear what you want. I mean, wear what you want within reason. Right? Like, wearing a Speedo, maybe not. I mean, Hawaii, people did present in their bathing suits. Right? They literally had just gotten off the beach. It was kind of funny. You you can come and go as you please. If you're like, well, I went to the wrong one, go. If you think you're gonna leave early, obviously, don't sit in the middle of the room and then have to, like, crush like, go through 12 people. If you think maybe you're gonna bounce around, sit near an edge so you can get in and out. Yeah. And, again, it's like behave, you know, respectfully and tolerant towards others. You can really dislike somebody's idea, but you can still like the person. I've had this problem before where, you know, you'll get into it with somebody about their particular draft, and then you'll say, like, hey. This idea is great. How can I help you? And the person will say, oh, I didn't think you liked me. Like, nothing to do with you. That idea was crazy. This other one's great. How can I help you? So it's it's really about the you know, again, be nice to the people. English. I often make jokes that they're American euphemisms. They don't always fly with everybody else, so you try to be a little more normal, not not you know, crack too many jokes. The difference is too with English, like, you're making slides, get them in early because it's not everybody or English is not their first language, and it gives everybody else a chance to maybe read ahead and participate a little bit better. That doesn't always get done, but the chair should do a better job of kind of, like, riding her on the people that are presenting. There are some people that speak really, really quickly. Like, I'm literally thinking slow down every time I open my mouth. There are people that can go really, really fast. It's okay to ask them to slow down, because it's just computer people that don't talk to anybody else, and they just go real fast. And it's better that you understand.
[01:22:30] Michelle: And we have an IETFer who actually he has his own speed. Yeah. Right?
[01:22:35] Sean Turner: Yes. If you're remote, obviously, you wanna test your stuff to make sure it works. There's a test site for the MeetEcho things to make sure it all works. One of the things that's important is that in an IETF meeting, they don't always spend a lot of time doing, you know, tutorial material. They jump right in. Right? It's like, here's here's an issue. Let's get through it. Let's talk about it. So if you haven't read the draft and you don't know what's going on, you might be lost. So it's good to check ahead to see what's the what's on the agenda, and they usually have draft names, and you can link to them. If you go to the session, when you build a session, you can actually put the drafts that are gonna be discussed at that session. And so if if you do that, it's nice because then you can you can catch up and you can get it get involved quicker. Yeah. And, again, I love this thing. It says try not to repeat. So if the thing's been said 14 times and you get up to say it the fifteenth time, people are not gonna be thrilled. Oh, lanyards and dots. Alright. So this is the thing. So I mentioned I got a white one. You can take my picture. I don't care. Some people in red. I just always assume you're security people, so that's always funny. But yeah. So it's like you shouldn't they shouldn't people shouldn't be taking pictures of you if you're wearing a red one unless you're in a group or you're at the front of the room. The little the little things tell you where they are, where you met, and then there's a bunch of this stuff down here, the chair, the ISGIBLC. So that's if you're chair of a working group. The ISG is the groups, the group that is full of area directors, which is the one that tells you about that's in charge of all the the other various working groups. The Internet architecture board is kind of one that's kind of parallel. The LLC is the money people. The IRSG is the Internet Internet research steering group. The the NomCom is the people that pick all those other people. And then the IPMC, which is one of ones I'm on, is the the the trust, the people in charge of the legal holding of the documents. And if you wanna, you know, personalize your badge, you can add all kinds of little things on there. Some people go minimal and some people go crazy. So you'll see some people, they're down to their knees. It's whatever you wanna do. It's makes makes you know, you need to do what you want. Yeah. Yeah. So there's somebody running around. It's a woman this time. She's taking photos. So if somebody's taking a photo, don't be surprised. It's not I mean, it's gonna be used, but it's, you know, probably not going on Twitter or Facebook. If you don't wanna be photos photographed, wear a red one. It's exciting up here. There we go. Alright. Cool. Sorry about that. Meeting technology. Alright. This is the agenda tracker tool. It's part of the data tracker, and you can go through and set up your agenda and pick things. So if you look on the the most important part is, obviously, the sessions that you can go to. So it gives you the the location. You can click on the event location, and a map will pop up. So that's helpful because it shows you where it is, and you can figure out where you are. There's the name of the the the session thing, and then you can go click on the ones down on the right. The interesting ones really are the on-site meeting tools, the one you're looking for. That's the one you use to log in to make it work. You can make the cool thing is you can actually set it up and make your own iCal calendar invite so that you only have to follow those and don't ever have to come back here. And then it's set up nicely because if you click through it, it'll you can get to all the same data. And again, so on the right, you can build your own calendar. So, like, if you you you, like, pick the sessions and then you can click through all the ones from the various areas that you care about. And then you just end up downloading the thing to your thing. It's pretty cool. The NOC team. So these are the people that make the network at this hotel scream very fast. It's also gonna allow you to, like, watch dancing cat pics in the elevator and all the crazy things that they set up. They get direct connections from any from most of the major providers. There are some funny stories because the IETF is a network hog, and they've burned a routing equipment down in various hotels. And the hotel doesn't love it, but at the end of the day, they, like, you know, get free networking, you know, consulting experience with the guys that made the stuff, setting up their new hotels. So when we leave, it's usually better than when it started. The Wi Fi SSIDs pretty much throughout. If you're staying in a hotel here, at least in the conference hotel, the I t f dash hotel hotel works, it's just as fast. And the team is is managed by a mix of people that are volunteers that have been doing it for a long time and then some actually paid staff as well. Yeah. They're fun. You can go check them out. They're they'll if you walk in there and just be like, hey. They'll tell you all about it. Alrighty. Zulip. This is the chat thing. There used to it used to be Jabber, and now it's Zulip. It's one it's one of the things on the the the the agenda page. You can click on that too. So if you don't if you wanna if you're really good, you can be in multiple sessions at once. And if you're in a Zulip session or a Zulip room for one of the the meeting one meeting and you want somebody else to go to the microphone, you could you can put mic, and then their people will walk up to the microphone and say whatever you put there. Yeah. It's neat. Alright. Then there's the wiki at if.org. It's the same. Like, if you go to the itf.org website, you put meetings, and you put itf120six, you'll get all this this this meeting info. It tells you where it is and stuff. And the side meetings is a place where you can figure out the the stuff that's going on and various other things, like meeting venue information. You know, if you didn't figure out that you needed a different plug for Europe, that this is where you're gonna find that out. There's a weather emergency assistance, all kinds of things that people have had to figure out or too we're too lazy to ask Google. So it's fun. And and then one of the things is the arrival and departure information. So if you wanna share a cab or take the train or whatever, you can put it in there and you can try to coordinate with people to get to and from. And that's also an interesting way to meet somebody. I've done that. It's funny. Alright. MeetEcho. This is not Webex or Zoom. I would advise you to try it out beforehand because it can be a little daunting, especially if you're trying to, like, get in there and say something and, like, this is your chance. It it is it is fairly intuitive. I have use it a couple times. One of the reasons why we do use is because there's a show of hands tool that we use a lot. And, again, I think it's just going through and kind of playing with it and trying to figure out, like, if you're presenting, like, when do you have to press all the buttons? And, again, it's better to to try it out before you actually have to immediately need it. And that's it. I gave you five minutes for questions.
[01:29:14] Michelle: Awesome. And this is a great opportunity to test out your Meet Echo. If you have never put yourself in the queue and you wanna do so now even if you don't have a question, feel free to just test it out and make sure things are working. No pressure in here. And if you do have a question for Sean, please put yourself in the queue and head up to the microphone.
[01:29:38] Sean Turner: Gosh. Well, good one. Make sure when you fill out the survey, Sunny was great. Terribly entertaining.
[01:29:43] Speaker 2: Because, you know
[01:29:49] Sean Turner: Yeah. There we go.
[01:29:50] Michelle: Just keeping an eye. People.
[01:29:54] Sean Turner: Alright. Well, I'm around. If you got other questions, let me know. It's all good. Is there a cookie break or something? Is that when he's like, don't don't.
[01:30:03] Michelle: We we do have a little break in between this session and the next one. Just keeping an eye on the room to see if we have any more questions. K. Questions? Going once. Going twice. Okay. So thank you, Sean.
[01:30:34] Jay Daly: Alright. Thank you.
[01:30:36] Michelle: Okay. So it is we are perfectly on time. Currently, 11:00. We have a fifteen minute break right now. Again, if you do have questions and you're just too shy to go to the microphone, come on up and ask us. Feel free to, you know, go take your break, catch up on email, whatever you need to do. The next session is on standards development. Some would argue it's almost the most important session because it's really all the meat of what the IETF does here. So we're gonna have Rob come Rob Bolton, who used to be an area director, who's very familiar with all of those processes. He's gonna be presenting. So we'll get started right at 11:15. So we'll see you back here shortly. Thank you.
[01:31:27] Jay Daly: Thank you.
[01:31:36] Michelle: Oh, that's okay. I I asked
[01:31:54] Sean Turner: So are are you gonna be presenting as, like, you're, like
[01:32:00] Speaker 2: At the IRTF open.
[01:32:01] Sean Turner: At the IRTF open? So usually, ends up happening is you'll send those slides. You can use the data tracker tool to upload it. Yeah. And so then when you go, you're not plugging in.
[01:32:09] Speaker 2: I see.
[01:32:10] Sean Turner: They're gonna they're gonna set it all up for you, and then you're gonna use this.
[01:32:12] Speaker 2: Like, with those transcripts?
[01:32:16] Sean Turner: So it's pending.
[01:32:17] Speaker 2: Doing it on a different note.
[01:32:18] Sean Turner: So if you do yeah. So usually, they upload p usually, I do PDF. But you can share screen. So that is a way to do that. What I would do is try to check with the your TF. Share. Yeah. Or or that is to make, like, hey. I wanna I'm doing this. How do you how do you wanna run this? Okay. Because they can they can give you screen control so you do it. Yeah.
[01:32:39] Speaker 2: I'll I'll reach out.
[01:32:40] Michelle: Definitely Courtney will care. Yeah. Yeah.
[01:32:42] Speaker 2: The other thing is also I need to sit yeah. I'll look
[01:32:45] Michelle: for the finish of it.
[01:32:46] Speaker 2: I can't stand it
[01:32:47] Jay Daly: all. They
[01:32:49] Sean Turner: can they can move this. They can move the chair, then whatever you need to get done. I mean, yeah, it's all good. Yeah. I would just tell them beforehand because then it's, not until the last second. Okay. Cool.
[01:32:56] Speaker 2: Yeah. Thanks.
[01:32:57] Michelle: Yeah. And the other thing is is we can let MeetEcho ahead of time because they'll control the cameras. Like, so it'll if you're sitting right here So it's
[01:33:05] Sean Turner: see more than just the top of your head. Yeah. No. No. No. That's that's Yeah. We need to we need to test this more often because people in wheelchair and stuff. Cool. Alright.
[01:33:16] Rob Wilton: Good stuff.
[01:33:18] Sean Turner: Alright. So, hopefully, I didn't talk too quickly.
[01:33:20] Michelle: No. Alright. Alright. Perfect timing.
[01:33:40] Rashid Buzir: Download the presentation material.
[01:33:43] Michelle: Mhmm. If you go to show meeting materials and you go to slides, they're all right there.
[01:33:50] Sean Turner: Thank you.
[01:33:51] Speaker 2: Yeah.
[01:33:53] Michelle: Thank you, Sean.
[01:33:54] Sean Turner: No worries. Noticed a few people walking around with, cold caffeine Coke, whatever. You know where they got those? Or
[01:34:23] Michelle: They're probably outside. We have I
[01:34:27] Sean Turner: see lots of coffee.
[01:34:28] Rashid Buzir: But
[01:34:29] Michelle: So if you look if you look on the agenda Mhmm. You'll see there are specific, beverage breaks. So, usually, at the actual beverage breaks, they're
[01:34:40] Sean Turner: They have other beverages.
[01:34:42] Michelle: Yeah. Usually, there's something more than water and coffee. And if not, that's a lot of people going somewhere and getting. We've been we've been getting coffee, from two different places, but I wasn't the one that went. But I will tell you, starting tomorrow, we have a barista Ah. That we bring into the hotel
[01:35:23] Speaker 2: Okay. Okay.
[01:35:23] Michelle: That provides free coffee, mochas, lattes, everything. And so you will see the barista starting tomorrow, and they'll be here all week.
[01:35:34] Sean Turner: And how long is the line?
[01:35:36] Michelle: Well, so, usually, we have two, places set up, and the line just depends on session starting. But, yeah, usually, it's
[01:35:46] Sean Turner: The machines over there seem to be a little bit better than the group.
[01:36:24] Speaker 2: Mean, I'll just grab a water pan too, but I was like
[01:36:35] Michelle: There should be pitchers somewhere out in the hotel.
[01:36:40] Stuart Cheshire: Hold on.
[01:36:40] Michelle: Let me
[01:36:40] Speaker 2: No. No. I'm I was looking for, like, a I'm looking for Lynn. I've just been, like, indoctrinated by, like, the whole lot of those takings at the airport, and I was, like, looking for the also
[01:36:50] Michelle: Hold I'm gonna double check real quick. Hold on. Okay. Every, venue that we go to does it just slightly different.
[01:37:08] Speaker 2: Sure. So
[01:37:13] Michelle: just double checking to see.
[01:37:23] Rob Wilton: Bought water from my hotel. So Not here.
[01:37:27] Sean Turner: I don't
[01:37:27] Rashid Buzir: I haven't been looking.
[01:37:30] Michelle: Sean had a little water accident here, so we're waiting for paper towels. Somebody's typing. Somebody's typing. Okay.
[01:37:40] Rob Wilton: I can get it. Go and get something.
[01:37:42] Michelle: Oh, I I
[01:37:43] Rob Wilton: I'll go and grab another bottle of water as well.
[01:37:45] Michelle: She's probably losing my
[01:37:46] Rob Wilton: voice, mister Denson.
[01:37:47] Michelle: You're losing your voice already?
[01:37:48] Rashid Buzir: Maybe. We'll see.
[01:37:50] Michelle: Oh, Paige is supposed to bring the paper towels. Fine.
[01:37:53] Rob Wilton: Okay. I was
[01:37:53] Sean Turner: gonna grab some.
[01:37:54] Rob Wilton: Let me start at first class.
[01:37:57] Michelle: No. You have till 11:15. Okay. Yeah. You're good. You're early. Somebody's typing a lot because oh, now two people are typing. There's water stations in each room.
[01:38:23] Speaker 2: I think what they mean is just
[01:38:25] Michelle: the Yeah. So they supposedly, there's a water dispenser in the hall around the corner from the hackathon.
[01:38:33] Speaker 2: Okay. I'll show water here.
[01:38:37] Michelle: But there there should be a water dispenser, I'm guessing, on that side of the room. Yep. You just confirmed it.
[01:39:34] Sean Turner: Here.
[01:39:38] Rob Wilton: I thought this might not.
[01:39:40] Michelle: No. It's just Yep. I I got a picture here for you. This is. 18. Right there.
[01:40:01] Speaker 2: Okay. You
[01:40:02] Michelle: good? Yeah. I take it right. Yeah. I I'll just leave. I'll keep this one here just in case. Case. Just
[01:40:08] Rob Wilton: Where
[01:40:13] Speaker 2: is speaker standing?
[01:40:14] Rob Wilton: Here? Yeah. Like you said.
[01:40:16] Speaker 2: Okay. Because I decreased the image, I can't do anything more than this. But I think that then you're not in projection. Fine.
[01:40:23] Michelle: Okay. Somebody saying something? Yeah.
[01:40:26] Speaker 2: Somebody said that the speaker is always in the projection. Okay.
[01:40:29] Rob Wilton: I mean, I'll just stand slightly.
[01:40:31] Speaker 2: I think that's that's fine because this way you're sliding the projection. Yeah. Yeah. I don't
[01:40:37] Michelle: like it.
[01:40:38] Rob Wilton: Bye. You
[01:40:41] Michelle: got five more minutes
[01:40:42] Rob Wilton: It's okay.
[01:40:43] Michelle: To relax.
[01:40:44] Rob Wilton: I'm look at the slides this morning. The cushions are lots of material, miss.
[01:40:49] Michelle: Yeah. You've got the hardest you've got the hardest one, but I told everybody it was the most important, so no pressure.
[01:41:00] Speaker 2: Alright.
[01:41:13] Michelle: I'm I'm more grouchy. There's no grouchyness. Right. Have it loud.
[01:41:19] Speaker 2: Sound grouchy. Bless you. I'm gonna say
[01:41:56] Michelle: Yeah. I think, give me
[01:41:59] Speaker 2: a second to double check something.
[01:42:05] Michelle: So you're set you were set for an hour.
[01:42:09] Rob Wilton: Yes.
[01:42:10] Michelle: So, yeah. I'm just gonna go shut the door off.
[01:45:34] Speaker 2: Yeah. Fine.
[01:46:28] Michelle: Just a reminder, scan that QR code if you haven't already.
[01:46:39] Rob Wilton: Right. Okay. So hello, everyone. I know you've had a couple of sessions already this morning. I hope you've enjoyed those. Hope they've been good you good and useful. I've got quite a long session here for an hour and covers a lot of the detail of the standards process. And it tells you also about a bit about how IETF's structured in bits that you more like to interact with, even part of the IETF part of it, the the standard development side of it, and also how you bring new work into the IETF. Now the amount of detail here is sort of too much for you to consume in this one session. So you've always got the notes to go back to and look look to towards. But it's really to try and give you an overview of how this stuff works and fits together. So you've had the introduction to IETF. You've had participated in the IETF, those two sessions. And this third one, we're gonna talk about the areas, working groups, the process you actually go through to get a document through the whole process. And then most perhaps most importantly and interesting to you is how do you bring new work into the IETF? What do you do? What are the approaches? And there's different ways of doing that. I'm happy to take questions at any time. So if you do that, then please use the queue and use your either laptop or phone to rest from the queue, and Michelle will very kindly look after the queue. If, I'm running behind the time, I may move those questions to the end, at the end of the session or after the session if necessary, but feel free to ask questions as we go along. About me, so, I've been working for Cisco in in networking basically for about all my career, twenty five years now. I used to work on Ethernet and VLANs, layer two technologies, and then moved into network management. And that's the point that I sort of got involved in IETF. And that was about ten years ago I first came to the IETF. So I was like you in a room coming to these participant new participant sessions. It was much more simple at that stage in terms of what these sessions were, less detail. I think, hopefully, it's got better now. And then after about four years, I then moved into the IETF leadership, which is sort of quite quickly. I'd skipped out being a working chair, and I went on to being an area director. I'll talk about those in a bit more. And that will happen just as COVID was beginning, so I also had the the difficulty of handling being an area director, a new area director, and also everything being remote at the same time. I did that for four years, and then I'm now sort of back in the community as a just a regular participant. I do chair a working group, the green working group as well. But it just sort of says that you can your journey through IETF is is sort of what you choose to make of it and in terms of how you participate. The Note Well, this session, obviously, is an IETF session, and it's covered by the Note Well. Normally, for most of these meetings, we'd give you time to read the Note Well go through it in more detail. But because you've had the sessions this morning covering the Note Well in a bit more detail, I'm actually gonna skip over it this time, especially given we've got quite a lot of content to cover. So so with the IETF, when you come here, it's sometimes quite hard to figure out the wood from the trees. There's a lot of different stuff that goes on, and that's organized in different areas. And what the IETF is working on changes over time. And to try and provide some structure to that, the IETF is split into areas, like broad areas covering particular technologies or or groups of technologies, and then within those areas is sort of divided into working groups. Now these areas can change over time, and the boundaries are completely strict. So some technologies will span across multiple areas, and you might just define, you know, what's the best time for these things. But, basically, you if you look at what the areas are and the working groups that can help sort of direct you to the bits of the IETF that you might get the most out of as your new participant. So so the IETF is split into seven areas, and these come under the responsibility of the IESG. And that's the the IESG, the Internet Engineering Steering Group, has the overall responsibility for the IETF standards process. So most of the RFCs, not there's a few other parts, but most of the RFCs come under the responsibility of the IESG to go through the entire process and get to an RFC at
[01:51:07] Rashid Buzir: the end of them.
[01:51:08] Rob Wilton: And and as I said, the IETF is split into areas, and currently, it's seven areas that can change. And those areas can change over time. So the time that I've been in IETF, a couple of areas merged into or split and merged into different areas to make it easier to characterize where the work is currently happening. For each of these areas, you have roughly two area directors, and those are the the people who are responsible for all the working groups in the area, and they're responsible for the ROCs that get published by that area. So as the documents go through, you'll find that the area directors get involved in the latter parts of those stages, particularly for the areas that they're working on. They also review documents in other areas as well. But it's the area directors that have that responsibility. And each of those areas is then split into working groups. You can see down the right hand side, it sort of varies between about normally about 15 to 30 working groups depending on how big the area area is and depending on how big those working groups are. So some of the working group sessions you go to this week, you might find there is 200 people in the room or 300 people in the room, but they're really large. Another working groups are on more niche areas of technology where you may find there's only 20 or 30 people in the room and some people online. So so what the iTunes tries tries to does or what the IESG tries to do is split the work between the area directors and split the work between the working groups to try and balance everything. The other advantage of the areas is it means that the technology, similar technologies grouped together. And so if you're interested in particular thing, like, you're interested in network management, which is the best area, clearly, then then that's you know that all the sessions and working groups are sort of scheduled so you can go to most or all of them. So, again, the areas serve a function to help the sort of scheduling in the meetings so that you don't find that all of the meetings for your given area happening at the same time would be spread out. So I'll quickly cover what the different areas are. It's listed on the slide, so let's have a look. But art is the sort of highest level area, applications in real time. So this covers things like email. It covers video conferencing technology like WebRTC. It would cover messaging when IT was doing more of that. And other small little application things that sit close to application layer. So JSON Schema, I think, is probably their other one. So so that's the one sort of closest to the application and closest to the user in a way. Then you've got the gen area, the second that's on this list. This is like a special area because this is actually involved about the IETF processes. So the IETF uses RFCs to publish technology, but it also uses the same mechanism to control the rules of the IETF and the rules of the IETF standards process. Those are also RFCs. And it's this gen area that is responsible for evolving those over time and making changes. So it'd be things about evolving the process or meeting venues, all that sort of thing might be what comes on the gen area. That only has one AD, and the AD responsible area is also the IETF chair. As Roman is is the AD and the IETF chair for the gen area. But they don't cover technology. It covers process stuff. So if you're interested in process, go to that one, but be aware, it's very process focused on those documents. The interior is the one that you probably most think of the Internet effectively. It's like the layer three, I p v four, I p v six. It's sort of the middle the middle band of that technology. DNS falls into this DHCP. So it's that the IP layer, but the things that are sitting outside or are more around the edges go to different areas. Ops management, and it was I was at the ops management AD when I was an AD on the ISG a few years ago, which is why it's clearly the best area. And this one's also slightly unusual that you'd normally have one area director that's focused on operations and a separate area area director focused on network management. Most of other areas, they are interchangeable. They don't have that same split. I don't know if that's changing over time. It might do. And so network management's also about is all about how you manage the devices on the network. Things as the protocols to talk to those, getting data off. And the operation side is about how operators deploy networks and manage these protocols and things like that. So that's obviously a key part to this, is you've written the protocol. It's like, how do you actually deploy this? How do you upgrade it? What's the security concerns, etcetera, related to those? And that's that area. The routing area is a slightly bigger area, and that's why it has three area directors rather than two. And it's it's responsible for all the routing protocols, like BGP and OSPF and ISIS. So has responsibilities for those. The newer technologies like segment routing, SRV six, MPLS, traffic engineering. So it has quite a lot of quite a broadband related to sort of routine protocols and signaling and most of the sort of control about how the Internet sort of works and talks to each other and and all these devices communicate. Security area is, again, it's a larger area, still only eight two ADs, and it's quite cross cutting. So it has responsibility for security across all protocols, which is quite interesting. So all protocols have to be secured by design, and they will have to have a sort of security consideration section in the documents. And the security area directors and and the people working in the security area will review the documents to make sure that they are secure and point out any issues and things like that. But they're also responsible for any of the security related protocols that might be to do with certificate management or, like, secure transport TLS would be there. So anything to do with encryption, security, post quantum cryptography, all that sort of fits under the security area. And then the last one on this list is web and Internet transport. So this is, like, thinking of, like, HTTP, which is the protocol that the web browsers use to fetch web pages, anything to do with APIs related to using HTTP as a mechanism like that. So it fits at that layer. It doesn't cover things like HTML, which is the the language that you use because that's part of w three c. But anything below in terms of the protocols for doing web interactions falls into the WIT area today. And and then each of those areas is split into working groups. And now I'm not going going to go over every single working group and what it does. I don't even know, in fact, what they all do because they change over time. So these working groups come and go. So some of them are long lived. So Netmod and Netconf under ops area, those ones that I participate in quite heavily, those have been around for a long time, at least ten years, maybe twenty years, because they sort of exist for the same technology as the technology evolves. Other ones will write or pop up, do some error technology, and then they'll be completed, the working group will shut down so that other working groups can be can be recreated. And you can see from those lists that the working groups are categorized by the areas. And then you can see also in this list that some of them have been bolded. So dispatch on the art area, gen dispatch, and sec dispatch on the sec area. These are all dispatch working groups. So these ones are when new work comes into the area. So if someone's got a new idea and it's related to security, then one of the obvious paths to take it to would be to, say, send it the the new draft to the sec dispatch list and request the presentation slot and the sec dispatch. And then then within those dispatch working groups, what they try and do is not to advance the documents within that working group. They try and say, this is where you should take that new work. You know? Or and whether the wants to work in the work at all. So they might say, oh, you should go and take it to this this this existing working group if you didn't know about it. They might say, actually, this is a brand new area of technology. You need to we need to create a new working group first if there is consensus for doing that. Then a few other area ones like int area. There's ops AWG, and, actually, there's there's also now an ops area as well, and RTGWG. Again, all of these working groups that are bolded here sort of more cross cutting and cover more of the area level discussions, new work coming in, and sort of status updates for the area. So some of those are more approachable potentially because they're not actually necessarily going into the weeds of a particular protocol that's been around for ten years or something. Oh, and and ITV loves acronyms. So effectively, you'll find that when the areas when the new work group's been created, the ISG will try and come up with a clever name for it and a clever clever acronym. I can't even pronounce the word. So oh, So they'll come come with a clever title for their working group and things, and everyone refers to them by that. So it's worth sort of knowing those names. So how do you with, obviously, so many areas and so many working groups, how do you actually figure out your way of through all this? And this is where data tracker is one of the best tools for finding out. The other best way of finding out this stuff is to actually ask other people. You'll find other participants will know within the area what the working groups are doing, so the experienced participants. And, again, if you ask the the chairs of the working groups or the area directors and things, they will help point you in the right direction. But the data tracker has a lot of information about what a working group is doing, what area it is in. It gives you its name. You can see here. It tells you who the area director is responsible for that working group. So that will be the person who ultimately decides whether the work gets published and whether they're happy for it to be published. So so they have a large responsibility. And the area directors have responsibility for oversight of all the working groups within that area. So so they're there. It also data tracker lists all the documents related to that working group and new work that's targeted towards that working group, and that's particularly important. I'll come on to that in a minute. And tell you the status of those documents as well. It has details of the meetings that happened and the upcoming meetings, and it also has the charter listed there, which says this is the scope of what the work that the work group's allowed to cover. So if the the working group can't just go and decide it's gonna work on some random technology or go out of scope, it has to con stay cons constrained to the work that's in the working group charter. And the charter is agreed between the area directors with input from the community as to, like, almost like a contractor's, this is the work you're going to work on. This is the this is the priorities. This is the technology you're going to deliver. And then once that work's done or if the requirements change, then the charter the working group is rechartered. The charter's changed to whatever the new work is. Each working group has working with chairs. Normally, it's two. Some have three. Some only have one. And, again, those are listed in data tracking. You can find who those working chairs are. You can find out how to contact them if you've got questions. So if you know you've got some work that you're interested in that's that's targeted towards a particular working group as you know it's to do with network management, then you could email the network management chairs and say, I've got this idea. Can you help me bring it to IETF? What do I do? How do I progress this work? How do I present some things? So they'd be willing to help. I've got a link to the mailing list of of the the working groups. And the mailing list is a great place to see what's actually being discussed on the working groups is to track the work. So and and you've got new ideas. Emailing the the working group, mailing list is a great way to sort of interact and talk to them and get started. Also in data tracker, that's that's probably equally important as that previous page is the list of documents that working group is working on. And this is this is only showing the top section, and this is for the ACE working group authentication and authorization for constrained environments, which is a bit of a mouthful. So everyone's gonna say ACE because that's easier. And there's there's sort of four sections of these documents, only this top section shown. So the section of documents that that lists on the data track of the working group is the list of documents that have been adopted by the working group. So this is work that the working group's actually working on. You'll have a list of documents that the working group is finished with, and then the IESG is now processing. So it's in the latter stages of the of the sort of RFC cycle. Then there's gonna be a section of RFCs that's been published by that working group. And finally, at the bottom, which is perhaps most interesting, is is work that's been targeted to that working group. And anyone can target a draft towards a working group just by in terms of how they name it. So that's the key bit in terms of choosing who you think that your work might be aimed for. And on this, you can find the documents. You can click on one of those links for a given document. And, again, it tells you a lot of history and information about the document itself. So you can see here at the top, these these two bars shows the different revisions of that document from when it was an individual document, and then the point it became a working group document. It was adopted by the working group, and it shows you those revisions. And you can click on each of those and see individual revisions. You can also see the current version of documents in in text or HTML. And I recommend now, actually, for some of these new documents, HTML is a good choice because in terms of diagrams and and sometimes readability, lots of people still use text. And another thing that's sort of quite helpful is, like, the history tab there that allows you to compare between two revisions. So if you come back and this is your second or third IETF, you might have gone to some of these working groups and seen some of these documents have been presented before, and they've evolved. And you might not want to read a 100 page document from scratch again to see what's changed. So instead, you can see the diff between the differences between the older and newer newer revisions, and then just comment on those all. But everything's in scope. So having told you a bit about the IETF in terms of its structure, I'm now going to go through the standards process. Again, there's lots of detail here. Try and take the sort of the high level view of what's going on and know that it doesn't matter in terms of the details. There's always people that will help you at various stages of this process if you start taking a document through the IETF standards process. Before I get onto that, though, I want to talk about consensus and humming. So the IETF doesn't vote. Lots of different organizations have ability have this this idea of where you are a member of that organization, paid or through employment or through national governments and things, and you have the ability to vote on documents to decide to get published or not. But that's not the process the IETF uses. It uses this consensus process. And more than that, it uses something called rough consensus. And it's a bit nebulous as to what rough consensus actually means to that to the extent there's actually an RFC that tells you and describes a bit more about what rough consensus is. Some people think that it means that everyone has to agree, and that's not the case. It's trying to get a read of the room or or the people participating in that working group as to what's the general direction that the working group agrees and believes in this technology. And that's the direction it will will normally go in. But it doesn't mean that it necessarily is taking the most popular one. It might be that somebody's raised some objections for a different for a different approach, and nobody can refute those or stop those. Like, there's no counterargument as to how to mitigate that that objection, in which case, the working group may then go in a different direction and choose to say, well, actually, even though lots of people say we should go this direction, the issues and things stop it being published in that way. One of the things important with the IETF is that everyone who comes to the IETF is participating as an individual. So not they are they obviously have their names of the companies on their badge. I work for Cisco. But you're participating in the IETF as a as an individual participant, and you're trying to do the best for the IETF the Internet as a whole and for the technology as a whole. So you're meant to come here and say, actually, even though my employer would like me to do it this way, I think a better technical solution or better pragmatic solution is to do it different way. And so one aspect of that is that when it comes to these discussion and decision points, consensus checks, it's like, how do you do that? If you were saying, actually, I don't agree with the direction, but I don't put my hand up and say I disagree because if my employer or somebody else is in the room saying, well, why are you voting that way? Then you try and do it in a super sort of pseudo anonymous way. And there's two ways this is done. The old style is humming, and and we'll do a to sort of see what that's like. So and the idea here is to get a to get a feeling for what the room is thinking without actually identifying individuals. So so you all come to, like, to Vienna, and hopefully, it's a nice venue. And maybe in a working group, they're discussing whether or not we should come back to Vienna again, hold another meeting up here or not. And so the working group chair wants to get a consensus, a feeling for the room of what this of what the consensus is. So I'm gonna ask a question. I'm gonna say and then if you agree with it, you're going to give it a like this. I'm going to might say, you can do it louder or quieter. But, basically, give a hit a as to whether you agree with it. And then I'll do one for the reverse to see the reverse question to see if there's difference. So my question is is, do you think we should come back to Vienna? Do you think I should come back to to Vienna? So now how many of you think that's the case? And now the reverse question. Who here thinks that we shouldn't come back to Vienna? So how many of you think we should come back? So so, again, as you can hear, there's a few people who obviously opposed to it, but the consensus of the room is that we are basically supposed to come back back to Vienna. Now what's important with this is that when you're trying to figure out when something is free K. It's important to try and understand why somebody's objecting. So at this point, if somebody says, I don't want come back to Vienna, it might be a good reason for that, and you want to tease that out. So often a working group chair would then ask the working group, okay. So anyone who's objected to that, you want to come up to the mic line and explain, you know, what's your reasoning for not coming back to Vienna. And maybe somebody will come to the mic line and say, actually, the food's awful. I don't want to come back for this reason, whatever. And the working group can evaluate whether it's about a concern or not.
[02:10:21] Michelle: And I also want to point out that show of hands tool that we pointed out in MeetEcho earlier on is an attempt to include remote participants because obviously when you're in a working group room, you can't hear the hums of people that are participating remotely. So that's where that technology has come in to hopefully include the folks that are participating remotely.
[02:10:46] Rob Wilton: Yes. So so you won't really hear hummus very often now. Everyone will use the show of hands tool that Michelle's mentioning. But it's it's intended to achieve the same thing with the limitations of the technology and by also including remote people. But, again, you'll see that vote of hands doesn't tell you exactly who's voting. It just gives you that overall, and it's not a vote. It's a show of hands. And it's not like whichever gets the most is regarded as being the winner. If the if the two votes are very similar, then the working chair will probably say, well, the consensus is unclear. It's balanced. Or there's a clear strong consensus in one direction or another. So just give me a read. So on to the actual process. So on these next few slides, you see there's lots stages to this, but the key bit to it is there's really three fundamental stages of taking work through the IETF. And the first phase is the individual phase, and this is when somebody brings a new idea. They might be a new participant. They might be an existing participant, but they bring a new idea to the IETF, and they write up a draft. And they and they then, evolve that. They probably discuss and present it. And it gets to a point where, the working group will decide whether or not they want to take that work on. And at that stage, you then if the working group there's consensus that the working group wants to adopt the documents, then it comes into a working group phase. And the working group now logically owns that document. So it might even appoint a new editor for it. That's unusual, but it can happen. But you're responsible if you're the editor to represent the views of the working group as you progress these documents. And it sits in that stage and gets better and has reviews and is presented and will be across multiple meetings likely through this working group phase. And then at the end of that, at some point, you get to the point where you decide that the work group's done. It thinks the document's finished, and then it has another phase of reviews. There's a check at the end of the working group, and then it goes on to the IESG for processing. And they are responsible for doing some more checks, some more checks between the different areas, more reviews, a bit more processing, and ultimately, at the end of that process, assuming everything goes well, an ROC pops out of it. So I'm gonna talk through these three phases, but really understanding the earlier phases are more important than the later ones. I won't worry too much about the IESG processing. Because if you bring work to the IETF and you're going through this, you'll find that the working chairs will help you. Document Shepherds will help you. Other members of the community will help you. The ISG members, the ADs, everyone will help you through the process. So, initially, you have an idea of what happens. So you, anyone can publish an Internet draft. It's easy. And sometimes this causes confusion in the industry because people say, oh, the IETF's working on I p v 10 maybe. And the answer is it's not. It's not working on I p v 10 at all. One individual has posted a draft to the IETF, and they've labeled it I p v 10. And it looks it turns up in data tracker. It might be against the working group as a potential document to consider, but but it's clear there's no consensus to adopt that work. Nobody wants to change to a new version of IP at this time. You got this individual document. You start with your idea. You publish this document. You bring it to the working group. You you send it to the working group list as well. It'll go there automatically, but you'll send an email saying, I've published this new document. This is what it's about. Please, can you review this and send me some comments? And if these people are interested, they will review the document, and they'll send you some comments. And it's up to you as an individual individual document author what you do with that feedback. You're not obliged or required to incorporate it. However, if you want the working group to pick it up and these people who are commenting on it are part of the working group, it helps to try and understand their comments and incorporate them, understand their concerns, and discuss with them. It's actually actually, no. I don't think you're right. I don't think we we haven't done it that way for this reason. We should do it this way instead. Have these discussions. And so you get this phase of of evolving the IDs IDs, Internet drafts IDs as we call them, presenting at the IETF meetings, and they have lower priority in the sessions because they're not adopted work. And you get to a stage where you think as as the authors that you sort of you think there's interest in the working group to adopt this, and the working chairs will then decide, do we do whether or not to do an adoption poll for the documents? And so the working chairs do a call for adoption, and this is the first consensus check. They say to the working group, this document has been proposed. You get two weeks to review it, and people will review it and send feedback. It's like, yes. I think we should support this document, Or I think, yes, I support this document, I think these changes should be made. Or no, I don't. And then the working group chairs will evaluate what the consensus is of the working group as to whether to adopt that document. Now adopting a document doesn't mean it'll get published as an RFC. It just means the working group's interested in working on that currently. They can, it's unusual, unadopt documents. They might try and work on it in the working group because it's not finished at that stage. It's just some stage through the process. Then they work through the document and find there's some fundamental issue that means that that the solution doesn't really work. Some security thing you can't mitigate or concern mitigate, and ultimately, you say, actually, no. This is a failed thing, and you you wanna adopt the document stuff. Once it's been adopted, you have the same sort of cycle of evolving the document that you did as an individual individual author, but it's now the ownership is under the working group. So if the consents of the working group is you have to add in some feature a and you're opposed as the editor, then you have to add it in because you are just editing the document to represent the views of the working group. And, ultimately, if you are the editor of the document, you say, no. I'm not doing this. Would appoint another editor because it's not your document at this stage anymore. You might view author, and often you'll do most of the changes and work and things, but you have to represent the views of the working group as it goes forward. And then once the document's gone through the working group a number of times, there's no there's no count or limit. It just it depends when all the issues have been resolved and everyone thinks it's done. The authors will say, I think this work's done to the working group chairs, and then the working chairs will decide whether they agree or not. And then this the second sort of consensus check is done. First one is this working group last call. And what you're trying to do is is does the working group agree, have consensus, rough consensus, to publish this document as an RFC? And so they will do another round of reviews. Everyone gets gets an opportunity to review and comment on it, and the authors will incorporate and discuss those issues and things like that. And some people will say, actually, I'm a post this document being published occasionally in some of the working groups. Another one's working groups, actually, everyone's fine. They're just providing comments on how to be published. And there's another consensus check to like, does the working group have rough consensus for this document to progress and go forward? And that consensus check is on the on the working group chairs to evaluate that consensus. At this sort of stage, there are likely to be a document shepherd that's assigned to the document to help write up and check, check it for nits, check it for various things, check that, you know, all the t's have been crossed and the i's dotted. And then at that stage, it gets submitted to the ISG for publication. So it gets handed off effectively to the area director. And during this process or just after this process, you may get director reviews if you're in this. And that's the only reviews from either your area or other areas from other people who aren't in the working group. Like, a fresh set of eyes in the document said, okay. I read this document, but, actually, this bit is just not clear to me because the authors have been spending two years, three years discussing it in detail, and they sort of lost the fact that they've not written down the introduction or not explained it clearly enough. So these director reviews are really helpful to to to to pull out these sorts of things. They also it might be your document touches on a few different areas of, like, security or might be using a new transport port or something, and you haven't quite followed the rules there for what that area requires you to do. And, again, the director review would pick up and say, oh, wait a minute. You need to change this, or you can't have a port number allocated, or it needs to be something else. So so they will help. So the whole thing with the IETF process is is, like, how do you get lots of people to review your review your documents? How do you produce the best standard that you can and possible? How am I doing on time?
[02:19:25] Michelle: Yeah. Pretty good.
[02:19:26] Rob Wilton: Okay. Fine. Excellent. So once the working group's finished the document, it gets handed off to the ISG. And the first step of that is the area director does their review of the document to say, do I think this is ready to go forward? So they will review the documents. If they have concerns and things, normally, the authors will then address those, and it'd be fine. Sometimes they might have big concerns about the documents. Actually, I think some more serious changes need to be made, and they might go back to the working groups. So they need to do some more processing, goes back to the working group. They'll evolve it. They might do another second working group last call. In fact, that can happen even without the AD's involvement to try and get to consensus. So but at some point, assuming it's through that process, the the air director says, yes. I'm happy with this. And then they're also sort of at that point issue director reviews that they haven't done already and then schedule an IETF last call. So this is the point that the IETF technically checks consensus across everyone who's a plus participants in the IETF. So anyone gets the opportunity if they're in any working groups on the on the IT panelist to review that document and say, actually, yes, I agree. This should be published or not. Now in reality, most of the people who are interested in that technology will be going to the working group, and they'll be commenting there. And by far, the best time to get your comments and thoughts incorporated is as early into the process as you can. You'll find that people are far more willing to try and mitigate and make changes early in the process than later in the process because it's a lot more work. We won't be undoing other things that are done. But you get these director reviews, and they come back. And this and as it says here, anyone can comment to the IETF last call, even if you commented on the work group last call. And then it's up to the area director area director to then do another consensus check on that document. So they will say, effectively, is does IT have IETF have consensus to publish these documents? And that might just be nobody said I support it, but nobody said I I object. So at that stage, the IETF last call was nobody saying don't publish this. There's but it's assumed that the working wants to publish it, and that's fine. So that's the second sort of consensus check that's important. And the responsible AD makes assessment as to whether it's ready. And once they're happy, then it goes on to the ISG evaluation. So the second part like, the last part, really, of the final check of the of the draft that become RFCs is this IESG review. And at this stage, all of the area directors are invited to review the documents and and balance on the documents to where they think they they think it should be published. And, effectively, I'll cover the sort of how that balancing works later, You need to have the consensus of that ISG that, yes, this document's ready to go forward. And if they say no, they might they might end up going back to the working group to say, you know, you need to change these things. If the working chairs haven't been doing the job correctly and it's out of charter, then it's possible, like, an area director might say, wait a minute. You're doing work that's not in your working group charter. So you need to change the charter working group to bring it to scope or or something else or document doesn't progress. And the ISG can block documents. It doesn't happen very often. They do end up delaying them as they want changes to make them better, because mostly the people who are area directors are are people who are very experienced in their area and understand the concerns. So it might be I mean, the one for network management might say, well, actually, this isn't gonna work from a network management perspective. You haven't considered this. You need to add some information to the document to explain how you manage this document this protocol. And then then the ID gets revised with the comments from all the area directors and eventually then gets approved. And then it sits on a on a queue waiting for the RC editor for a bit to pick it up. And then finally, the RC editor will make some editorial changes to improve the text, improve the readability, etcetera, the end of the process, but not change the meaning of the protocol, not change the meaning of the document. They're only trying to make editorial changes until it finally gets published. So this is the whole process. These are all the steps. It can take you can do this maybe four months, slightly minimum, six. More realistically, two or three years. Can be longer. I've got documents that are going on a lot longer than that, but
[02:23:45] Sean Turner: we
[02:23:45] Rob Wilton: got about those. Yes. So it depends how long the it takes the technology to effectively become because everyone's happy with it and and understood that the documents are correct. So you don't need to know all these. The early ones are more important than later ones. So all the working groups tend to operate in similar ways. They all use data tracker, but there are some differences in terms of how individual working groups work. And sometimes you just have to join the mailing list and interact for a bit to understand what they're doing. I think over time, more working groups are using GitHub now than it was. There's a there's a trend to use more of GitHub. Certainly, the documents I do, I manage from GitHub as well. It makes it easy to track issues and things like that, but other ones might not. Some of them might do sort of some of the discussion via GitHub. Others might do it mostly on the mailing list, which I do. There is a sort of requirement in IETF that the mailing list is still a sort of primary way you interact in terms of so all the consensus discussions and things will happen on the mailing list. Working groups can have these plenary meetings, so they can choose to have one or two slots for here, but they can also arrange interim meetings. And, normally, interim meetings is like a virtual online meeting that is arranged by a working group. And some working groups will have a a regular cadence of interim meetings where they just sort of progress the work. Other ones might sort of range individual interim meetings for a particular topic. So there's some idea that's been discussed. One of these meetings is, actually, you've only had five minutes to present in this or ten minutes. We need to have a two hour discussion to eke out all of all of the issues and things like this and understand it better. So arrange for a virtual interim meeting. The downside to virtual interim meetings is it's hard to arrange a time zone that suits everyone because people from all around the world come to the IETF. So that's the bit that's tricky. Occasionally, some meeting some of these have interns in person. It's quite rare nowadays in my experience. Some working groups have a working group secretary or a technology expert assigned to them, and, again, data tracker lists who they are. You can sort of basically the the working secretary might do requests on behalf of the chairs, but you can always interact with the chairs as the first port of call. Some working groups may assign different editors to documents. I think, again, that's generally quite rare unless there's some contentious. Mostly, it's normally the authors who also pick up editing document in my experience. And then the last thing to say is design teams. So, again, design teams are quite interesting. There's an RC that describes these. So this is where you get a smaller subset of the working group to work on a particular topic or idea. And they then generally work in isolation for a while on a separate mailing list, and then they'll come up with a this is my conclusion to the design team. Now what's important to understand here is the design teams don't bypass any of the process. So the output of that design team is just the same as as as if an individual written it, except it obviously has a bit more consensus because it has a consensus of people on that design team. So the working group will still have to do an adoption poll for that document and say, does everyone else agree with it? As to why this is sometimes helpful is because because everyone who's participating in IETF from all different walks of life and different competing vendors, and they sometimes there's too much friction in a room, and somebody won't publicly sort of down from their position in a larger forum, whereas in a smaller team, those issues and things can be sort of melted away and it's gate mitigated in a smaller group. You you find that people are more willing to bend on their views when they discuss these things these things. So sometimes these things have helped sort of progress tricky issues forward. You're probably wondering where do you find out about interim meetings if you want these. So they'll be announced on the working group mailing list. They're also be announced, I think, when IETF announced as well, possibly. They're getting out somewhere. And, also, data tracker that also lists all the interim meetings. And not only does it list them, it has the links to the resources for those interim meetings, which should be published a few days before. It's it's not quite as necessarily as good as the plenary meetings or how strict people are. And, again, you'll find, like, the meeting notes of that, how to connect to the to the meet meet echo session for that interim meeting. So all of that is on data tracker. So a bit more on the ISG, IESG. So I talked about what they are. So the I ISG is sort of the leadership body responsible for standards development and the community revolve with that and the processes. They're very busy individuals, certainly during these these weeks because they are managing maybe ten, fifteen working groups, and they'll go to all those working group sessions. They'll have chatted to all the working group chairs beforehand to understand what the agendas are. They'll understand what the the hot issues and things like that are. So they're very busy during this week, and you may find that if you want to talk to them, that it's hard to hard to find time to chat to them. Often, they will have an office hours for a given area, and you can get you can see that in the agenda. It's a time when a half hour slot where anyone can go and chat to them about a particular issue. So that's one way of going to chat to them. They will should be around or some will also be around for the new participants' quick meet up later this afternoon. And, again, that's a good good idea to go along with that. I suggest that. Try and find the areas that you're interested in. Try to talk to people who are interested in the same sort of technology areas, and they'll direct you the right sort of way to go. So you don't have to necessarily know. If you just go into that room and ask anyone, they will either point you to the right sort of direction or or or somebody else to ask if necessary of of where the technology is. As as part of the balloting procedure of the documents, you have this this meeting that happens every two weeks called the tele chat. This is an a meeting that's open to all to to join that meeting, but you can't participate as you can't speak in the meeting unless you're invited to do so. But it's it's the meeting that the IESG holds every two weeks to discuss the documents, discuss how people have how the ADs review the documents and resolve issues effectively. So when the area directors review documents, there's there's sort of different choices of how they can ballot on the documents. The two common ones you see here are either comment or discuss. Our comment is just on that document. It's like the feedback from any other participant saying, I've reviewed this document, and I've got these comments I think will make it better. These things are unclear. And and sometimes, if you're new to this process, you've got the the document all the way through the working group process, your individual process, you think you're done, and you get to the ISG review, and suddenly you find you've got 50 more reviews with quite long comments and things from different people. But remember that that all they're trying to do is to make your document better. So they're not trying to stop you or or hinder your work, and they got the expertise in that area, and there are fresh set of eyes that won't necessarily know that document. So they're just trying to help. It's up to you with the comments on how you address them. You're not you're not formally obliged. You don't have to act on them, but they are there to help you. Sometimes an area director sees an issue with a document that they are so concerned with also concerned with concerned enough with that they think, actually, this has to be changed before I'm willing to let it be published. And it basically, a single area director can delay or stop a document from being published if they have concerns. And so they were bound to comment discuss blocking ballot vote, and they'll put the comments and their concerns in. So they'll clearly identify or address, these are my comments that's up to you how to address. These are the things that are blocking comments in this document. You're obliged to interact with the area director to find out how to mitigate those. Sometimes it might be, this is just unclear, and I need some more clarity of this. It might be, oh, you've missed this process step or something that needs to be addressed. You've not got this registry registry reference correct. But in all cases, even though it could be quite scary, it's worth knowing that probably the majority of documents that go through the IESG telechats end up with at least one discuss on them, maybe two. So so don't be disheartened if you see those, and it's not the AD saying your work is terrible. They're just saying you need to address these comments before happy for this to progress. I just I just have a discussion with them, so don't be scared or frightened by them. And the working chairs will help you. The shepherds will help you. The other area directors will help you, so it's all fine. And then the output of the status process, you know, that's taken four months if you're very, very lucky, six months or a few years and things is an RFC. And I don't think they they do particularly well. The RFCs are sort of showing you the differences between the different documents, but they actually have different statuses on the RFCs that get produced. And some of those make quite a difference in terms of what the consensus level is. So most of the documents you see published through the IETF stream is either proposed standard PS, which is basically this is a standard. It's done. Normally, like a protocol or something similar. And that has every has a strong consensus with the ISG from all different areas ready ready to be published. There's a higher level of proposed standard, which is Internet standard, And that's the final stage that an RCA ends up with, one of these proposed standards. There aren't many things that ever got that high, and that's because normally, by the time something gets to Internet standard, it's clearly obvious that the whole Internet or lots of the Internet is deploying it. So so I p v six is an Internet standard, but it was, I don't know, maybe five years ago, became an Internet standard, a long time after the RFCs have been published and it's been worked out. So I would ignore that one. So proposed standard, a lot of documents you see or quite a lot of are informational documents. So these aren't meant to be new technologies. There might be documents that are design documents or practices of how to use it and things like that, but they're not formal standards. So, again, they still have to have IETF consensus to publish them, but they don't necessarily people won't necessarily be so concerned that they're they're exactly right. The area directors, when they're balloting, they can ballot a more softly on informational documents. But those are two main categories that you see. The other ones that sort of pop up now and again are BCPs, and these are best current practice. These are slightly confusing because they actually cover two purposes. One of them is out to the Internet community saying, this is the best practice for deploying security. I recommend that you should be using at least TLS one dot two and probably TLS one dot three. So you might find there's a BCP that says something like that, then or maybe something different. But, effectively, it's to the community giving you advice, or I think you should deploy DNS in this way. This is what the the ITECH community believes is the best way of managing this this protocol. You also get BCPs covering the IETF processes themselves. So, like, the IETF standard that says about the processes RFC twenty twenty six is also part of b c p nine. So, again, you see BCPs for these reasons. But, again, unless you're very into the process, I wouldn't worry about those so much at this stage. And then the final one on this list is experimental, which, again, is you don't see very many of them. And it basically it's a technology that is not yet ready, but you want to try and see how it it acts on the Internet. And normally, for experiments, they expect, like, a bounded time frame. So it'd be an experimental document. It might be like, okay. What's the measurement of how you check whether this this experiment succeeded or not? What how are gonna evaluate? And then after a few years, if you get an experimental document, either effectively it becomes unused, or if you actually then think, yes, this is working. I need to tweak these few things. You might then publish a new version of that document, new RFC that picks up that technology as a proposed standard.
[02:36:03] Michelle: A little quicker in the next few.
[02:36:05] Rob Wilton: Okay. Fine. Bringing new work. Okay. Fine. So so one of the things that you care about mostly is about how if you well, you might be participating in IETF to see what's going on, or you might be trying here to bring your own work to the IETF. Some of you might have already written an Internet draft. Is there is there a show of hands of anyone that's got like, show of hands of people? Yeah. So some of you have written drafts and things like that, and you already parted through this process. I've got two people in the queue.
[02:36:36] Jay Daly: I think they're just
[02:36:37] Speaker 2: doing shawkins.
[02:36:38] Rob Wilton: Oh, fun.
[02:36:40] Speaker 2: Why? Okay. It's a different hand.
[02:36:42] Rob Wilton: New shawkins. Okay. But the thing with the IETF is there's various questions you have to address. It's like, is this some work that the IETF is interested in working on? You've got to get this consensus community, which can be hard to find. It's like, is this something the IETF wants to work on, or is this something that actually is out of our scope of expertise? So an example might be somebody says, we want you to work on crypto algorithms for cryptocurrency and things like that. So, well, that's not really in the domain of IETF's expertise. It could go in that direction, but you'd have to sort of ask the people within the IETF. It's like, do you want to move the IETF in this direction? And maybe you also know we're more into interested in networking than than crypto protocols, things like that. So so the first question you ask is, is the IETF the right place to bring it? It's important to understand is is this something that's gonna be used? So the IETF isn't really about, I want to publish my great new protocol and idea. I knew I would love to do this. It's about stuff that gets deployed and used in reality. So having I'll be able to show that there's people who are writing implementations for the protocol, showing that there's people who are going to deploy and use the protocol is is especially important when you're going through this process. And the last thing that matters to the IETF is is this actually engineering work, or is this just research? So if it's just research, there's the IRTF, which is the Internet Research Task Force, And that that's one where you take new ideas that are being discussed that are more researchy. And then the IETF is where you're doing the engineering. So this is stuff that's gonna get deployed on end devices, on people's phones, computers, on routers, on switches. So that's what happens to the IETF. But as it says here, there's loads of exceptions with this. These are these aren't hard and fast rules. If you're not sure, always have a conversation with someone and find out. How do you prepare for engaging in IETF? What do you do? So you have to do some work when you come here. So the best way is to write something up in an Internet draft. Now one thing that's changed over the last couple of years is the advent of AI and LLMs, and it's very, very easy to write a draft. And you'll see that some people are writing drafts with LLMs. You need to be really careful with that, in my opinion, because if you produce a document 15 or 20 pages long and it has little substance that is different on you, then you'll get sort of backlash for the community or they won't be very happy with that. So you're much better to you use LLM to help you formulate your English and things up, but keep your idea really short. It's really important to try and get the the to the nub of what you're trying to do or what the problem you're trying to solve is and have that very concise and short rather than saying, I've got this new great new protocol and full solution. You'll find that's much harder to get traction in the IETF. Because you've got to take people on the journey of what's the problem you're trying to solve, and do you want to solve it here? And if so, can we help you solve it? Rather than being a sort of fake complaint. It's important you understand about your intellectual property rights and things like that because everything that goes into the IETF is in the public domain. You share copyrights with anything you produce with the IETF. And if you need to want to apply a patent to your technology, you want to do that before you bring it to the IETF effectively. Now if you do decide to patent it, there's different ways that you could do that, and there's different rules of how you decide to license patents. So that's sort of out of scope mostly for the IETF. We have some guidelines and things, and it's worth reading that if that's something that that matters to you. Don't have the r c there. But it's it's important if you have any patents on your technology that you declare those in the process. That's important for your sake and for the IETF's sake. Because when people are evaluating technology, they'll they may want to look at those patents. They want to be able to look the patent licensing terms are to decide whether they want to adopt that technology or or that technology approach. They may go a different route if they decide, actually, this is too incumbent. You have to pay license fees. But if you fail, there's nothing that stops you. If you fail to declare your patents, the IT doesn't wouldn't know. But if it came to trying enforcing that patent, you'll find that the the courts might take a dim view of that. So be aware. And then finally, decide what you're trying to achieve in the IETF in terms of some people write an idea up just to say this is my idea. Just sharing with the community, and it's always a great way. Like, you want to write it up as an Internet draft rather than some PowerPoint slides. You'll you'll get a lot more traction that way. I've got this idea. I'm not intending to take this any further, I'm just sharing of community to see if other people are interested in something like this. I'm just also sharing ideas. You see quite a lot of that happening. You have to choose your path of how you go through the IETF, There's lots of different ways of bringing your work to the IETF. One of them was those dispatch mailing lists that I mentioned. If you know the working group that you're targeting, go and talk to that working group. Talk to the working chairs. Send your idea to them. They will help you bring the work in or tell you, actually, this works out of scope. You can check the charter if if it is in if it is in scope or not. Maybe the work group needs to be rechartered. That sort of thing. Talk to work group chairs to help you. Try and find other people who are interested in your idea. And that can be hard, but present it to a working group or dispatch working group. You'll get people to read it, get people to comment on it, and they'll probably come and find you or email you and say, actually, I want to work on this with you. And having a mixture of authors from different companies with different organizations helps show the broader interest in that work as well. So that helps. If it's a big idea, too big for existing working group, then you often have this thing called a bird of birds of a fella boff. And that's where you have a two hour meeting often. And there's a few of those happening this week. They're quite interesting. They're good for new participants because they're very open. So they'll be discussing the different technology at a high level without going to the weeds and details. There and then you have discussion about, is this something that the IETF wants to work on? Is it solvable? I'm going to slow.
[02:42:34] Michelle: I was just gonna say all those bots are listed on the agenda, so you can easily find them.
[02:42:40] Rob Wilton: And a and a few of those. So and they're gonna they're gonna find out is, like, is this something the IETF can work on, should work on? Is there enough people who are interested in working on it? Is there a solution? There's you know, if it's an intractable problem, it's might might be actually, you need to scope this down to something that we believe you can do in a reasonable time frame. And then there's also some unusual parts, AD sponsorship that that happens rarely nowadays. And finally, there's also the independent stream. You can publish RFCs not through the IETF, but it still ends up in RFC through its independent stream. And that's slightly separate different set of editors and reviewers from the IETF community will decide whether to take a document that way. So sometimes there's something that's very contentious, and the IETF can't get consensus. But there's still a view that publishing is useful, and that's where the independent stream can be particularly helpful. Last slide, I think, of the questions. How to be how to be successful? So I think what I see when people come to the IETF where they fail is is trying to bring a complete solution rather than trying to bring your idea. If you could convince the community here that your idea has merit and is interesting and there is a solution, you know, that they don't understand what it is, then you can take people on the journey with you, and you'll get a lot more traction. And if you choose to produce slides and present these sessions, I often see slides where people have lots of these slides, a lot of content on them. Whereas I recommend, again, that the people some of the people might have read your draft. Lots of them won't. So the slides keep them really crisp and to the point. And, again, focus on what you're trying to solve and get get get buying on that more so than this is the details of my great solution and how it works. People are less interested in that at the start. Later on, you'll discuss that to death. But, initially, that's what's most important. Do write it up as an ID, short presentation. Talk to other people. And, again, you want to publish your documents early on and get them discussed on the working group mailing list if you can. So if you can get them discussed, you would more like to get agenda time. If your document just goes to the agenda and to mailing list and nobody's interested, it's harder to get agenda time. So having discussion helps. There's hot RFC to present new ideas and the dispatch groups as well. So it's really about trying to solicit, talk to other people, talk to people in the same working groups and things offline in the hallways around them, and then try and build that sort of consensus there and people are interested in what you're trying to do. And lastly, it's important that people will provide you feedback. It helps to try and be as positive, incorporating that as much as possible. If you're like, oh, no. That's just silly. Don't do that. You know, we thought about it already. Then you're pushing other people off. You want to try and bring people with you. Maybe they'll offer it with you, and sometimes that's good to have different views. Don't have to do it on your own. And time for questions Yep. Ish. Like, no
[02:45:35] Michelle: Yep. We we we can have a couple questions. And if you have a question, if you could go to the microphone. Just introduce yourself. Okay.
[02:45:57] Rashid Buzir: I'm Rashid Buzir from Securus. I am the author of OdaHTTP. So my question is about the first presentation. Is the first presentation we show the idea or draft? This is the first question. The second question is we show the problem is for for the first presentation is only we we should show the the problem and solution without the policy or or the policy is required for the first presentation. Then if the if the policy, which is it? It's just a running code or source code? Which means it gets all?
[02:46:49] Stuart Cheshire: That's my other question.
[02:46:50] Rob Wilton: Okay. So you want to try and bring same sort thing I say. You want to try and bring the idea of the of what you're trying to solve is the most important thing. So people, if you bring a long detailed solution and you haven't convinced the community that the problem's worth solving, then then you won't get traction. So that's the most important thing. But but you want to bring you have to write up the draft. You'll get a lot more people will review it. The whole thing, how ITIF works is all about the drafts. And the draft should have very clearly, this is the problem statement. This is what I'm trying to address and an outline of the solution, but keep that document short. It's much better to bring a document that's, 10 pages or 15 pages at most for a new idea, and then people read it. If they see documents a 100 pages long, it's like, oh, I've got so many other documents to review. That's much harder. So to keep it short, focus on the problem statements and an outline of how you're gonna solve it. That makes sense. And, again, with the slides, keep them short, focus on the problem statements. Leave time. If you get a ten minute slot, present for five minutes and have five minutes of questions.
[02:47:53] Rashid Buzir: But in the in some time, for my case, I have I have four four drafts, for example.
[02:47:58] Rob Wilton: So you
[02:47:59] Rashid Buzir: have? I have four four drafts. Okay. For the and is improving by by feedback. Yep. So we can start by the the broad problem, and after that, we narrow it for for the specific problem. So so the first presentation is we show I show that present all those drafts or the history of of the idea or just the problem and. And the and the new constant that we have, we have only eighteen minutes.
[02:48:32] Rob Wilton: Let me chat to you offline afterwards. Oh, okay. Okay. Thank you.
[02:48:37] Rashid Buzir: Thank you. You.
[02:48:39] Sean Turner: Hi, boss. Hi.
[02:48:42] Tom Satter: My name is Tom Satter from Myoverge KK in Japan. I have a question on on the implementers who would be using these standards, they would need security reviews. They would need the conformance testing and and interop in order to make it inter con compatible with other players. And and where is that process of first doing the security reviews, then doing the conformance testing reviews, and and interop in IETF process.
[02:49:26] Rob Wilton: So so in the IETF process, the security reviews of the document of the protocol happen as part of as the protocol is being developed, and, like, at the last call stage, the security area will be reviewing the documents and commenting on security. And then finally, the IESG, the security area directors will review it for security concerns. So throughout that process of the standard, then they're checking that the the standard is secure. In terms of, like, implementation or reference implementations or deployment performance, that's out of scope for IETF. I just come in. It's just producing the standard in terms of what falls under the umbrella of this organization. However, you'll find that some people might have link GitHub links to reference implementations or implementations that people are working on, And and it's very good to be working on implementations at the same time as the stance progressing, but that's not under the scope of IETF. We're not an organization that does conformance checking or or anything like that as part of it.
[02:50:25] Tom Satter: In the security review, is there a formal formal pros process or standard that of doing this?
[02:50:33] Rob Wilton: So it's outside of my area. So my understanding is for some of the crypto algorithms and things, they might choose to do formal verification of those protocols and things like that. But most of them know they're not using formal methods, is my understanding. But it's not. If you if that's something you're interested in, go along to the meet and greet later on this afternoon. Find the security area directors. I'm trying to think who they are now.
[02:50:58] Michelle: I actually don't think they're gonna be at Quick Connections today.
[02:51:00] Rob Wilton: Oh, fine. Okay. Yeah. They won't be there. But I'll I'll go along for something else. In the security area, we'll be there. I'm sure they'll be able to explain. But I think for the protocols, they do form of verification, but not for other things.
[02:51:15] Tom Satter: Thank you very much.
[02:51:17] Sean Turner: Hi. My name is Greg DiBiase. I'm with ICANN. So there's different types of RFCs, experimental, BCP, Internet standard or Internet standard. Do you have to have an idea of what it would be in that initial draft? Like, is there a different form that you follow, or at the in an Internet draft stage, it's just the idea and you don't have to put it in a bucket?
[02:51:40] Rob Wilton: That's an excellent question. No. You don't care. So that you can change at any point. There's no there's really no difference on what's in the documents for all of these. If it if it's experimental, you need to describe the experiment you're you're doing. So that's the one difference. But you'll find that sometimes draft would start as a standards track, proposed standard, and then, actually, there's not enough consensus to publish a standards track, and it gets published as informational instead. Or it gets published as experimental. So these things can change up or down at different page, different stages through the process, and it doesn't make any difference.
[02:52:15] Sean Turner: And so you don't need to define what you think it is in the Internet.
[02:52:18] Rob Wilton: If you're if you're doing a protocol, choose proposed standard initially. If you're writing up your own co corporate protocol for for information, it's informational. If it's just guidance, it's informational, all that sort of thing. If it's a framework, prob I I would say don't write frameworks, but that's different.
[02:52:35] Sean Turner: Thanks. Cool.
[02:52:36] Michelle: I'm gonna close the queue at this time. We have two more people with questions. I did wanna follow-up and let you know the security area is having office hours tomorrow, so that would be a great opportunity to talk to them about, your question. It's on the agenda where those are. Okay? Christian?
[02:52:55] Christian Dikoff: Yeah. Christian. Yeah. Hi. Christian Dikoff, WDZ. I wonder what would the process look like if the problem I'd like to address already had a draft in the past by someone, but that draft expired. So
[02:53:13] Rob Wilton: That's a good question. So I would in that in that first instance, I would try and reach out to the authors of that draft. Yep. So their their email address will be listed. Now they might be no longer participating in IETF. They might not be interested, but reach out to them first and see what you get back because they might be willing to pick up that idea again and expand on it. If if you get nothing back, I would then email the working group and say, actually, I'm interested in this. This is existing draft. I would I'm thinking about doing a new draft. And then you can publish you can reuse that work because everything that's in the IETF Yeah. Effectively given to the community. The thing to be careful of is that some people are very picky about, like, who gets listed as an author in the documents.
[02:53:55] Michelle: Uh-huh.
[02:53:56] Rob Wilton: So that's the thing to be careful with. That's the bit where asking them helps if they've written something already or you're extending their work. But you don't technically have to do that. You can write an acknowledgment section saying, I'm building on top of this work, and I'm acknowledging this this this existing draft and existing people who worked on that. So that's the way you can do it. And, again, the way I would decide is if you're taking their protocol and tweaking it slightly, I'd give more through authorship to them. If you are taking a different start, but it's sort of close and you're rewriting it a lot, I would just acknowledge them, their work, and and just have your own document.
[02:54:32] Christian Dikoff: Mhmm. And if there's, like to the point. So if it's in that early stage that there was no working group yet, it's just up about finding the probably best matching working group reaching out to them, or how to tackle something like that? Because
[02:54:46] Rob Wilton: Yeah. That's interesting. So if you can't and you can't reach the authors Yeah.
[02:54:52] Christian Dikoff: I tried that.
[02:54:54] Rob Wilton: I got nowhere. Yeah. I don't know with that one. I would publish it. I in that case, I've just published a new draft. If you think there's a working group we would go to and chat go to the new participants one this afternoon and chat to people. They might help us have direct you in that. And then, yeah, just chat to some other people there. They'll be able to sort of direct you and guide you, having looked at your document and what it more context about it.
[02:55:17] Michelle: Right. Yeah. We can definitely find people you can talk to. Yeah. Okay. Fabulous questions. Thank you to Rob. We appreciate you. We're running over just a little bit of time, so I'm just going to take one or two minutes just to prepare the slides, and I'm going to bring our next presenter up. The next presentation is actually very short. It's a introduction to the hackathon, which happens at the same time as this program. So Stuart's gonna provide a quick introduction to the hackathon, and then we, are going to be providing lunch just outside this room. So, in the meantime, I'm gonna make sure that's getting set up, and then you can have a nice little break until our afternoon sessions. So just give me a minute or two, and I'll get the slides up. Thank you. Okay. I'd like to introduce Stuart, Cheshire, and, he's gonna tell you all about the hackathon. My
[02:56:49] Stuart Cheshire: name is Stuart Cheshire. I'm here to tell you a bit about the hackathon. Sitting here, I was hearing some good questions just now. One bit of advice I have because I see this happen a lot. When people come to the IETF as newcomers, they they often feels like they approach it like they're giving a presentation for their middle school science fair, and they're very proud of what they've invented, and they wanna get a gold star and be told how smart they are. And the reality is that is not making best use of the resources that are available at the IETF. You have a lot of people here who are the world's leading experts in networking, and you can get a lot more out of the IETF if you come with a problem description, and you say, I'm working on this or the company I work for is working on this, and we've run into this problem. Here's a description of the problem. Can anybody help us work it out to solve it? Now you may have an idea how you think you're gonna solve it, but I would strongly recommend not leading with that to start with because the reality is the people here who've been working in networking for ten, twenty, thirty years probably have a lot more experience than you do. And the thing you thought of that you think is a really novel idea, it might be something that's been brought up time and time again in the past. And maybe it has some flaws or shortcomings, which is why it hasn't been done. There's quite often good reasons why seemingly obvious things haven't been done, and it's because they have non obvious problems or security flaws. So so that's my advice is you may think you have the perfect solution, but maybe keep that to yourself to start with because a request for help gets a lot more positive reaction. Most of the people who come to these IETF meetings are very helpful people, and they love solving problems. And if you describe a problem to them, they'll be really interested in helping you try to solve it. If you come in saying, don't want your input. I already know how to solve it. I just want you to tell me that I'm great. Well, you're in the wrong audience. You know? Ask your mom and dad to tell you you're great if that's what you're looking for. The other question I heard was about conformance testing. Now the IETF is not like other industry standards bodies that have membership fees and legal agreements. And because of that, the IETF doesn't have conformance testing. And the reason for that is because the IETF has found that conformance testing actually doesn't guarantee quality. It's really you cannot test quality into a piece of software. You have to write good quality software in the first place.
[02:59:47] Rob Wilton: And
[02:59:47] Stuart Cheshire: conformance testing may find certain obvious mistakes, But just because you passed the conformance test doesn't mean that your software is perfect. And that is actually a great introduction to what I'm here to talk about, which is the hackathon. Okay. This is where we are. This is a little bit bit about me. I've been coming to the IETF for many years. Currently, I work at Apple. You can read that in the PDF if you're interested later. I wanna take this opportunity to give a sincere shout out, thanks and gratitude to the people who organized the hackathon. Their names are here, Charles, Benno, Barry. They work incredibly hard. I I volunteered to give this presentation today because they're all juggling so many other things that they were not able to be here right now. So I'm here representing them for the hackathon, but I wanna I I wanna acknowledge the the enormous amount of work they do to make it possible, and it is extremely valuable for the IETF. Now this is a slide you should have seen before, and you'll see it again at the start of every meeting. And it is really important that you understand the processes that the IETF works on. As a standards body, the IETF has been around for many decades, which is not at all common in this industry. Companies come and go. Standards bodies come and go. I remember a few years ago, the the big news in networking was the UPnP forum. Everybody's talking about UPnP, and and and now there isn't even a website for it anymore. It's it's imploded, and it's gone. It's defunct. So so the IETF survives because it has a really good work culture. Part of that, which is probably the most important thing, is showing respect for all of the participants. In the early days of the IETF, it was not always that good. We had a lot of grumpy old men who didn't like newcomers coming in and made it very clear. Thankfully, the the attitudes of the community have evolved, and we we make a conscious effort now to welcome old newcomers like you. Everybody should treat you with respect. If you have questions, I think you'll find lots of people who are very happy to talk to you in the corridor. If you have a lot of questions at the microphone at some point, it might be appropriate to say, well, we don't need to take up the whole working group meeting time for this. There's lots of time over lunch and breaks to to talk. And wherever you are in your career, I highly recommend you take advantage of this opportunity to be around some of the smartest networking people in the world. You can learn so much from from their experiences and and their history. So treating everybody respectfully is really important. If you experience bad behavior or you see anybody else not being treated well, we have a team of IETF ombuds representative. I was gonna say ombudsman, but they're not all men anymore. And they are that post was created specifically to ensure that we continue to have good respectful treatment of everybody in the IETF. We talked earlier about patents. If you or your company has a patent on a technology, then you are expected, if you're operating in good faith in the IETF, to be public and disclose that so that everybody making decisions can do that with full information. It is considered extremely poor form to secretly have a patent, suggest something to go into an RFC, and after the standard is published, say, we have a patent. You owe us money now. I highly recommend against doing that for two reasons. One is when the policy is so clear, you'll have a hard time enforcing a submarine patent in court. And the second thing is if you hope to have a long successful career in networking, do not tarnish your reputation like that. There is there is no quicker way to get yourself ignored than by doing that. Because if people know that you're not trustworthy, you will have no hope of getting any of your other ideas into any other RFC ever in the future. So that is career suicide. Come to the IETF honestly, act in good faith, be open and transparent and honest. That is the best approach. Now I talked about conformance testing. We do not have a formal conformance testing process, which is if you pass this, then you're allowed to say that you've done the RFC. Because we realize that those tests are fairly crude. It is remarkable that the IETF produces amazingly high quality work without conformance testing. We all have devices, whether they're phones or tablets or laptops or a printer or a thermostat or whatever it is that have, for example, a DHCP client. And when you think about it, DHCP is a phenomenally reliable protocol. Right? When have you ever connected to the Wi Fi at an airport with your phone and had it not get a DHCP address? It it is phenomenally reliable. And that is a result of people working together and testing, and it's not a result of some companies saying, well, we passed the conformance test. Stop complaining about it. Because we realized that just passing a conformance test is not the same as being totally, completely reliable, and dependable. And the hackathon is a valuable part of that whole process that people working on a particular technology get together in person. When I was young in this career, we were working on DHCP. That is mature and stable at this point, and not much is changing, but there are newer things. I was just in the hackathon this weekend working on l four s, which is a new low loss, low latency architecture for IP packet forwarding. We can do this work over the Internet. We can have open source projects. We can have video conferences and work by email, and those are all very effective. But there is no substitute for getting in a room face to face and having the equipment. And I've got my laptop, and Greg has his laptop, and he's got some packet gateway devices, and we're running TCP dump and Wireshark and getting packet traces and experiments with parameters, and we can get three months work done in in one weekend at the IETF. So the high quality of the Internet protocols that we all depend on day to day for so much of what we do comes from that working together and not not aiming for some artificial designation that, oh, you passed conformance test. I'm not looking at anymore. People will find bugs. Even when you thought it was great, somebody will find some case where it doesn't work, and that's when you get together and you look at the packet traces, and you might argue about whose fault it is, and and you you you might disagree with how you interpret the RFC or the draft. But you end up coming to some agreement and you make the changes so that it works. A big part of the IETF, you may have heard this phrase, rough consensus and running code, and that is a very important part of the IETF ethos. Again, this is not universally true of all standards bodies. There are certain organizations that will sit around and have meetings and debate things and make a document and then kind of throw the document at the engineers and say, implement this. And however smart you are, networking is hard, and I don't believe anybody ever gets it right first time. Even the people here with twenty, thirty, forty years experience, you get better with experience, but there are always things that you didn't think of that you didn't anticipate. So the IETF has got this very strong principle that we write code and develop specifications in parallel, and the information feeds back and forth. So we might start off by writing up a problem statement of what we think the issue is that we have to solve. We may come up with a proposal of what we think we're gonna do about it. But before that draft gets an RFC number, people will implement it. And ideally, more than one team because you wanna know that different teams can read the draft and actually come to an agreement about what the draft is trying to say. And and if they disagree, that's a good sign that the draft needs to be reworded. And in the course of trying things, inevitably, you will find things that didn't work the way you thought. There may be timing problems or other issues that you didn't anticipate. But because you tried them out before the spec was finalized, you have a chance to fix that. So there is this back and forth, write the code, find the bugs, update the spec, modify the code, try again, find another bug, and you go back and forth. And when that process slows down and different implementations from different people are all working smoothly together, everybody agrees that what the draft says is clear and not subject to misinterpretation or disagreement, then it's tiMeetEcho to RFC. Because once an RFC number is issued, there are no more corrections. RFCs are permanent. You can work on a successor RFC to update the old one if you find mistakes. There is an RFC errata process where if you find a typo or a mistake, you can submit that, but the RFC will never be revised. So we worked really hard to try to make sure that it is very thoroughly reviewed before we commit to giving it a number. The IETF hackathon takes place Saturday and Sunday. It is free, and they also generally provide free food, which is very nice. So don't abuse that, but that's part of the intention of the hackathon is we like to make things fun. Now writing documents and arguing about them is fun as well. But most of us, I imagine, in this room, if you're like me, we like programming. We got into this because we like computer programming. And the hackathon can be a great fun experience to be in a room full of other people who also like computer programming. And you're not just working on documents. You're actually writing code and running it and and seeing it work. And that is really rewarding. It's also a great way for newcomers to get introduced to the IETF process. And there are people in that room who get paid a thousand dollars an hour for consulting. And if you wanted to get their time to help you with something, you probably couldn't afford it. But at the hackathon, you might just be sitting next to them. I was in there yesterday, and somebody was looking at something on their computer, and and they there was something that was been puzzling them for a while, and they just asked me because I was sitting next to them, and they said, like, when there's no DHCP server, my my computer I don't whether it was a laptop or a phone, whatever. But it gets this IP address, one sixty nine dot two five four something. What's that all about? And I said, well, that's called the link local address. IPv four and IPv six have link local addressing, and it's like a safety net. When when the network's broken, when the DHCP server's not working, or you don't have a DHCP server, you might just have a laptop with an Ethernet cable plugged into some other device, and there is no network infrastructure, the link local address is better than nothing. It at least lets you communicate on that cable. You you can't connect to the whole Internet without gateways and routers and infrastructure. But two devices on the same desk and a cable can communicate, and that's what link local addresses are for. And if you wanna read more about how it works, r it's RFC3927. And he said, thank you, and and that was great. I didn't say I wrote that RFC. I didn't feel the need to mention that, but it was kind of weird that, like, he he was literally sitting next to me and asked this question, and the person who wrote the RFC was there to explain how it works and why it's like that. So so it is a great opportunity to rub shoulders with some of the people who've been working at the IETF for decades. And most of are pretty nice and friendly and willing to share. And and you you can you can just ask questions and and rather than asking AI or asking your friend, you can actually ask the person who wrote the RFC and they'll explain it to you.
[03:14:22] Michelle: I think
[03:14:29] Stuart Cheshire: I've covered most of this. It's a two day event. It's free. Right now, we have about 300 people. There is a wiki. So if you're just interested in doing some fun programming, you can look on the wiki, see the projects that are listed, email the organizers, and say, do you need some help working on this? So if you just go to the itf.org website and click through to the meeting information, you'll see the hackathon listed there with the wiki. Normally, it's fairly informal. You can see in the picture there, there's a whiteboard. When the project champions show up, they find an empty table, write the name on the whiteboard. So that's how the various participants can find the team that they're working with.
[03:15:22] Michelle: And I'll just add there on the wiki, if you find an asterisk next to a project, that indicates that it's a good project for new participants to look into because, it's a little more open, maybe not so detailed in in a particular, protocol or something that's maybe a little bit more collaborative for new participants. So any questions about the hackathon? I think everybody's hungry. Well, you, Stuart. We appreciate you stopping by.
[03:15:55] Stuart Cheshire: Thank you.
[03:16:01] Michelle: And, two more important things. When you head out this door, my colleague Tess is out there guarding the lunch with her life right now. Because space is a little bit limited out there, feel free to get your lunch and come back in here if you want to eat. You're more than welcome to come in here and just relax. And then after lunch, we'll be back with just a couple more sessions with more information. So we look forward to seeing you then. So have a nice break. Thank you. Stuart. I appreciate you coming by.