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

**New Participant Program - Session 5 - Internet Drafts and RFCs**

**Materials:** https://datatracker.ietf.org/meeting/120/materials/slides-120-newparticipant-sessa-new-participant-program-session-5-internet-drafts-and-rfcs-00

**New Participant Program Coordinator:** Okay, good afternoon, everybody. Just to confirm you're in the right place, this is the New Participant Program afternoon sessions. We're going to start off with Session 5, which is going to talk all about Internet Drafts and RFCs. I hope you enjoyed your lunch. Hopefully you're not too sleepy after lunch. Just a reminder—you've heard it a couple times now, we're going to say it again just so you have lots of practice—if you could scan the QR code that you see either on the screen, there's also some on the papers where the microphones are, and there's also some on the board in the back of the room and just outside the room. If you scan that QR code, you will be in the Meetecho room. This allows us to know who is present during this session and also allows you to put yourself in the queue if you have a question. So, we're going to go ahead and get started. I'm going to pass this off to Alice, and she's going to do some introductions.

**Alice Russo:** Here we are, Session 5. Welcome to Internet Drafts and RFCs. This session is about the documents, specifically the work items of the IETF and the core outputs of the IETF. This is the high-quality, relevant technical documents mentioned in the IETF mission. My name is Alice Russo. I'm part of the RFC Production Center team, where approved Internet Drafts are edited and published as RFCs. I've seen the ongoing evolution of the RFC Editor function and the document formats, and we'll talk about some of that today. I'm interested in how IETF tools and education help authors write clear documents. And my favorite RFC is RFC 8700, about 50 years of RFCs, about the history of the document series. And I'm presenting today with Alexey.

**Alexey Melnikov:** Hello, I'm Alexey. I've been Area Director a couple of times and published over 65 RFCs. I think I stopped counting at some point. Yeah, so we’ll talk about documents today.

**Alice Russo:** This is the "Note Well," which you've seen earlier today. By participating in person or remotely, you agree to these policies. You will see this a lot this week in each working group session.

So, RFC stands for "Request for Comments" because the historical purpose of this document series was sharing notes. And we keep the name today. And ID stands for "Internet Draft." To get a sense of your familiarity with these documents, please raise your hand if you've written an Internet Draft before. Okay. And please raise your hand if you have an idea that you want to put into an Internet Draft. Okay. How about, raise your hand if you've read an RFC or part of an RFC while implementing a protocol or an extension? Okay. So this is for you. If you have questions during the session, please feel free to come to the microphone. Also, we will take questions at the end.

This is an overview of what we're going to cover today. So, the who, what, and where of the RFC series. These are freely available, stable documents designed to support interoperability. There are almost 10,000 RFCs. The authoritative site is www.rfc-editor.org, and this website is about to be completely replaced this year to make it easier to find the documents you want to find and view them on the device that you want to view them on. Famous examples of RFCs: TCP/IP being very famous, TLS 1.3, and QUIC. But there are many, many more, clearly.

We'll talk about their publication formats and the way their status is labeled, what the subseries are within the RFC series, and we'll also talk about relationships between RFCs—how an RFC can be updated or obsoleted. In general, the RFCs don't change. If there's an error in it, then it's reported as errata. If it's an error in generating the RFC, then we can usually fix that by regenerating it.

In contrast to the Internet Drafts, there are many, many more. Over 40,000 archived Internet Drafts. As you learned today in the standards development session, the Internet Draft is a way for you to share your idea. datatracker.ietf.org makes them available in various formats, and the version history is there. In contrast to RFCs, the Internet Drafts are expected to change. This is the primary way that a working group advances a protocol or another idea. We'll cover today more about how they're structured and the tools to write them. They do time out after six months and are moved to the archive.

The document formats have evolved over time to provide more features for the readers. Originally, RFCs were typed and distributed on hard copy. This is predating the idea of online. 1969, as RFC 1 example here is showing. Once they were posted, they didn't change. So the metadata can't change. The diagrams are created with characters, ASCII art, and the line width is fixed. And there's nothing added to the text file to show when there's errata.

So the next step in the evolution is an HTMLized document. So this is processing the plain text to add links and to add a header at the top with some metadata. It shares some of the limitations of the plain text, and Data Tracker has HTMLized versions of all RFCs. The benefit here is you can jump to the section you want to jump to, or jump—the link takes you to the section in another RFC that it's pointing to.

There was a major format transition around RFC 8650. So this HTML is more flexible. The page layout adapts to your window size. You can put in a fancier diagram, not using ASCII art but using SVG, which is Scalable Vector Graphics. And it also has the added header at the top to show you if the metadata has changed. For example, on this one, it's showing "Obsoleted by 9429." That means after this RFC was published, it was later replaced. "Obsoleted" is the word for "replaced," in contrast to "updated," which could mean just a small part of the RFC was changed, not completely replaced. This gray header is also where there would be any link to errata. And this format—the way that you view this will change when the new website is available.

PDF is also available. It also uses the SVG diagram if it was supplied. This one does not have the post-publication metadata. So it won't show you if it's been obsoleted or if it has errata. So in that sense, the HTML format is best for a reader.

This is the source format. RFC XML is used to generate the publication formats. This is an XML file with a defined vocabulary, attributes that hold metadata. For writing an Internet Draft, you don't have to use this XML format. You can use Markdown, specifically a flavor of Markdown called kramdown-rfc, which we'll cover more later in this session.

All right. Getting into status, subseries, and streams. This is what kind of document it is and where did it come from. You saw this information earlier today, but each RFC has a specific status. "Informational" is used for use cases, applicability statements, framework documents—it's not the protocol itself. "Experimental" could be a new extension on an existing protocol. For example, IMAP Message Limit Extension would be an example of an experimental RFC. "Proposed Standard" is the first official stage of a standard, and many documents are published as Proposed Standard and never move forward to become full "Internet Standard," the last category on this slide. For example, all the WebRTC specs—the core specs—are Proposed Standards. QUIC is a Proposed Standard. TLS 1.3 is a Proposed Standard. The "Internet Standard" category, the final standard stage, is when the protocol has been shown to be interoperable and widely deployed. There are also protocols that are interoperable and widely deployed that are Proposed Standards. A recent example of an Internet Standard is Multicast Listener Discovery v2 for IPv6. And the "Draft Standard" category is no longer used, which was an intermediate category.

More status: there's a status called "Best Current Practice" (BCP). There are two different goals with Best Current Practice: one is about process—for example, IETF standards process is captured in a BCP document—or about technology. So for example, OAuth 2.0 Security is published as a BCP. And I'll talk a little bit more about BCPs later.

The "Historic" status is a specification that's been superseded. For example, Network Time Protocol v2 and v3 were moved to Historic. Every RFC that has been obsoleted has not necessarily been changed to Historic status, so it's not a comprehensive concept of deprecated.

And the final status on here is "Unknown." This is for old RFCs. For example, RFC 1, "Host Software" from 1969 that we saw earlier—its status is marked Unknown. They were published before the concept of status existed.

Subseries is a numbering sequence inside of the RFC series. So, some RFCs are Internet Standards. These form the "STD" subseries. For example, STD 5 is the Internet Protocol, and STD 101 is Multicast Listener Discovery. And similarly, there's another subseries with BCPs. So, some documents are status Best Current Practice, and they also receive a BCP number to be inside the BCP subseries. For example, on here, BCP 226 is about selecting the IETF meeting venue. So this is an example of a process BCP. A BCP or an STD number can contain more than one RFC. So in this case, BCP 226 contains four RFCs. Another example of a BCP is BCP 9, about the standards process. And what RFCs are contained in a subseries can change over time. RFCs can be added and removed. So for example, RFC 793 about the Transmission Control Protocol (TCP), arguably one of the most famous RFCs, published in 1981, was STD 7, part of STD 7. Then it was obsoleted, meaning completely replaced, by RFC 9293. And so when that happened, RFC 9293 became part of STD 7, and RFC 793 is no longer part of that STD. It's a secondary numbering system.

All right. This is the "where did it come from?" Where did this RFC come from? Each stream has its own process for approving an Internet Draft to become an RFC. 90% of RFCs in recent years are from the IETF stream, the first one on this list. It's by far the largest, and it's the only one that can publish Standards Track or BCPs. The Internet Architecture Board publishes documents in the IAB stream. These are usually workshop reports or about architecture. For example, an example of an IAB document is "Partitioning as an Architecture for Privacy." The IRTF is the Internet Research Task Force, and they're usually publishing results of research, and their documents go through a research group process separate from the working group process of the IETF. The Editorial stream is about the RFC series itself. And the Independent Submission stream publishes RFCs that are outside of the official process of the IETF, IAB, and IRTF but are relevant to the Internet community and achieve reasonable levels of technical and editorial quality. There is a person in charge of this stream; the Independent Submissions Editor is Eliot Lear, and there's also an editorial board. An example of a recent document that came from the Independent Submission stream is "Centralization, Decentralization, and Internet Standards." There are also documents that are marked "Legacy," meaning they were published as RFCs before these streams existed. These are typically older.

So let's talk about what the average RFC is. The average RFC is from the IETF stream, and its status is Proposed Standard. Over 60% of RFCs published in recent years are Proposed Standard, and it's usually on average about 30 pages or 28 pages. But of course, there are many RFCs that are not the average—very long or very short, from the alternate streams that are listed here, or that are not Proposed Standard.

So what content actually goes into these docs? That's the... Alexey's going to talk about Internet Drafts.

**Alexey Melnikov:** Right. Thank you. So, let's first talk about what's in drafts and what's the standard part of a standard template, and etc. So, each document, whether it's RFC or Internet Draft, has a header. And both types have a lot of common fields in it. So if you notice, so you have on the right, you have a title of the document—or here. You have a list of authors and or editors. You have publication date. You have status, which is "Category" for the RFC, which is Best Current Practice, or "Intended Status," which is Informational for the draft in this case. And you can also have a list of any updated RFCs and list of any obsoleted RFCs. I think on the right, there is only a list of RFCs updated and the obsoleted RFCs list is missing.

You'll notice that also some of the fields are different between Internet Drafts and RFCs. In particular, the working group intended or adopted is only present in Internet Drafts. So you see the working group DHC at the top. When the document gets published as an RFC, this information is stripped from it. You also have a stream. Stream, again, typically meaningful for RFCs. You have expiration draft date only for drafts because they expire every six months. And for RFCs, you also have International Standard Series Number and Digital Object Identifier. So ISSN is in RFCs. So this is a single number that defines a whole RFC series, so I think it doesn't change between documents.

So, after the header, there are several sections which are automatically generated by tools or from the information you enter in the source format for documents. So, one of them is "Status of this Memo." You don't, as a, you know, author or editor of a draft or RFC, you don't edit this text. This... there are several templates that come from different streams and depend on type of document. So if we'll be talking about RFC XML, for example, format, it has a field for intended status and the stream, and then this text will be automatically generated when it's rendered to plain text or HTML. There is also copyright notice. It's held by IETF Trust on behalf of IETF and describes rights granted to readers of the document. Again, different streams can set different rules about this. And then there is a table of contents. Is it always generated now? It used to be that documents of a certain size, you know, very small documents, didn't have table of contents, but I think now it's generated always.

Okay. So now talking about the content of the document that you put in in it, there are several sections which are required. "Abstract" is the section at the top of the document. It's a very brief overview of the purpose and content of the document. And this section is typically two, three paragraphs or something. And it's used in... when the document is announced as new RFC, this section is included in the announcement. Then there is an "Introduction" section that explains motivation, describes sometimes applicability. It should describe whether this document obsoletes or updates any existing RFC. Quite frequently, there is some text duplication between abstract and introduction. I kind of think of introduction as an expanded version of abstract, anyway.

Then later in the document, there is a "Security Considerations" section that should explore various security issues raised by the document—known risks, known ways to address or work around them. For procedural documents, it's okay to say that this document doesn't add any security risks, but in most cases, this section will have some text, you know, other than that in it.

Then there is "IANA Considerations" section. IANA is Internet Assigned Numbers Authority, which is an organization that assigns and manages number allocation and protocol name allocation. So, for example, if you have an IMAP extension, IMAP extension name will have... has to be unique, so it will be... it will go into one of the registries managed by IANA. So yeah, in many documents, IANA section describes actions for IANA to either update or or change something. And sometimes, if there is nothing to do for IANA, it just says, you know, "No action required from IANA."

And the final required section is "References." It has two subsections: one describing normative references and one informative references. One of them can be missing, depending on the document. But basically, normative references are references required to implement and understand the protocol or the specification, and informative references are other related information.

So. Who wants to write an Internet Draft? Don't be shy. Okay. Good. So, let's just talk about how you go about doing that. So, yeah, this is a slide... good reminder that actually just because something is an Internet Draft doesn't mean that, um, it doesn't mean a lot, to be honest. So, anybody can write an Internet Draft. Nobody checks its content, and no permission is needed to do this. Anyone can submit the draft. Again, no permission is needed for that. On the right, you see an example of a draft by one of our colleagues who basically added text demonstrating, "Well, this doesn't mean a lot, and, you know, I can write anything I want here." So, if you hear people saying, "But it is an Internet Draft," unless it's a Internet Draft in a working group, which is adopted Internet Draft, it doesn't actually mean a lot. So, it also, as it happened, some people write Internet Drafts and never submit them, so I've seen people, like, posting kind of proto-Internet Drafts on GitHub and just referencing them for discussions, but they might not... might choose not to submit them.

So, only once it's submitted through Data Tracker, then it becomes submitted Internet Draft. And once it's submitted, it cannot be removed or withdrawn. And with each submitted drafts, there are rights granted to IETF via the IETF Trust permanently. Um, so this means in most cases, like, that people can use other people's Internet Draft and build on top of them. And as I just mentioned earlier, Internet Drafts have no formal status in IETF until they... they are adopted. And there is a special process for that.

Okay. So, you have an idea of Internet Draft. First, you need to pick a language as in format and a toolchain you want to use to edit it. The two most common cases are RFC XML and versions of Markdown. Unless you know XML well, want to use it, has validation tools, recommendation is, if you start a draft, just start with Markdown or kramdown-rfc variant. But either way, there are templates available. Um, there are some other options. I think people used to do, like, Word documents templates. I'm not sure whether this is still workable, but, um, and there are some other formats as well. Um, some very old participants still use plain text, but again, this is quite rare. There is a very good website, authors.ietf.org, which has more information on this with various templates and guides. So yeah, you can... you can have a look and browse. And a lot of time if you are writing a draft, Internet Draft, you will be co-editing it with somebody else. So in this case, co-authors, you might just follow their lead and, you know, whatever their preference is, but...

So, you decided to write an Internet Draft. You picked the format you want to use. Uh, you are writing your ID in... you filled in some context. You defined required sections and some extra information, like use of uppercase keywords. Uh, now you are just about ready to submit the document. The next stage is validate your Internet Draft. Uh, there is a good website, authortools.ietf.org, that provide various validation and conversion methods. So, you upload your source format. It can render it to HTML. You can see what HTML output might look like or PDF output before it's posted... submitted. You can also use the diff tool to compare it with either two versions of the document or with previous version of the document. There is also a tool called IDNits that picks up on very common mistakes or things that need addressing. Again, it's in most cases, it doesn't prevent you from submitting the document, but it can notice that your diagrams are too wide, so they're not going to fit, and RFC editor will need to reformat it. Or, you are referencing some documents and don't have them in the reference section. So this sort of thing. So these things are nits.

Okay. And so, you checked your document. It seems to render okay. You know, maybe you have a few nits, maybe you didn't fix, you know, didn't fix all of them, but it mostly looks all right. And now it's time to submit your draft, Internet Draft. So, the submission tool, um, doesn't currently allow you to use the Markdown variant and kramdown, but if you use kramdown-rfc, it will generate RFC XML format that you can submit. Submission tool, again, will... will do validation on your Internet Draft to be submitted. Checks for, you know, a few things like you haven't tried to post the same version number as before. That if you're using RFC XML, that the year you put in the document is the current year, and a few other things. And then it will, if everything is okay, you can proceed with submission. Um, it will also, I think it gives you a chance to list to say, "I am this author," if there are multiple authors on the document, and your author will also be notified... co-authors will be also notified that you are submitting a new version.

Um, we still have a rule in force that two weeks before any IETF, submission of Internet Drafts is suspended. Uh, this is basically to let people... other participant have time to read your documents. Um, I think the submission is going to be resumed either today or tomorrow, so... Um, so people actually during the IETF week, they can post new versions to... to help in... in various discussions.

So, um, you have many more resources on authors.ietf.org. You have descriptions of various processes and tools that you can use. Um, there are many more validation tools for like if you use ABNF or YANG models. Um, yeah, some of these tools were developed internally by IETF. A lot of people... a lot of them were developed by community as well. Um, so you have templates, schemas, and you also have a document with full reference to RFC XML format. So if you're editing document in RFC XML and want to add a table and you forgot how to format the table, then you can go have a look at the reference and remind yourself, for example.

**Alice Russo:** So, if your Internet Draft has made it through the working group process that you learned about earlier today and it gets approved—for example, in the IETF stream, it's approved by the IESG, makes it through last call—then your document goes to the RFC Production Center in order to be edited and published as an RFC. So we're jumping ahead to the very end of that process. So, um, this is... we'll learn a little bit more about what happens in order to have the clear, concise, and easily understood documentation that's mentioned in the Internet standards process.

So, the RFC Production Center has this process, the flowchart that's on the right. So basically, your document's being edited, and then your document is, um, being sent back to you after it's edited for you to review it. And this is what we call the "Auth48" process. This is a historical name; it comes from "Authors 48 Hours," meaning you have 48 hours to review your document—your edited document. But in reality, it usually takes longer than 48 hours, and we wait to hear from each author listed in the header that you approve your document.

So what... what is the RFC Production Center doing? We take responsibility of the source document, source file. We've assigned it an RFC number, and then we're working with the authors to make sure that the, um, technical content is intact. So our goal is that your points remain. So if some edits have been made that change your point, then this is your chance to speak up and say, "Oh, this is what I'm trying to say here." We check all the references. We ensure that the IANA actions are clearly documented—that was mentioned earlier, that's the assignments, the protocol assignments. And sometimes there's a lot of back and forth. This is again only for the approved Internet Drafts that have made it through the process for their stream, and, um, we ask any questions we have at this time also about unclear text: "What did you mean by this sentence?" and it would be your chance to make it clear.

Um, I'm just going to go back one... a little more on this. So at this point, the RFC Production Center is the subject matter expert on English grammar, syntax, punctuation, and the authors are the subject matter experts on the content of their document. Um, so again, the... the technical content is, um... the goal is to make it as clear as possible. And this process is currently, um, done via email. So and there's an experiments with pilot process with using GitHub for this process, but usually it's by email. It's important to have your most up-to-date email address in your Internet Draft so that we can contact you.

Okay. If you have any questions, this is a great time to come to the microphone. Um, I will be here Monday through Thursday this week with my colleagues from the RFC Production Center, Sandy and Alanna. If you have questions about the content of this session or about RFCs, um, please come by the RFC Editor desk and ask. And, um, go to authors.ietf.org, grab a template, and... and start writing your idea. Any questions for us? Thank you.

**New Participant Program Coordinator:** All right. We recognize that that is a lot of information that they're throwing at you and it takes some time to digest it, understand it. So keep in mind these slides are available, um, online as part of the session materials. Um, this session was recorded, so you can always refer back to it by looking at the proceedings of the meeting. And as Alice said, um, they have a... a desk outside in the hallway out there, and you can ask any questions during the week. So stop by, say hello, ask a question. We're going to take a five-minute break here, so stand up, uh, stretch, go get some coffee, go get some water, and then we are going to have our next session, which is about the Power of the Community, um, kind of goes over how the community, um, impacts the IETF and how that all works. So we'll start that in about five minutes' time, so we'll see you back here shortly. Thank you.

**New Participant Program - Session 6 - Power of the Community**

**Materials:** https://datatracker.ietf.org/meeting/120/materials/slides-120-newparticipant-sessa-new-participant-program-session-6-power-of-the-community-00

**New Participant Program Coordinator:** We will be starting in just about 60 seconds as I see our presenter entering the room. Um, just to give you a... a quick overview for the next two sessions, um, Harald is coming to the stage and he'll be presenting the material for the Power of the Community. And just after that, we're going to do just a very quick, uh, 10-minute wrap-up session. I'm going to review some of the things that are happening during the week. And after that, the Quick Connection session will be starting, which is on the 40th floor. And following that, we'll have our Welcome Reception, which is just in the two large rooms—they've made it one giant room right next door. And that's going to be the Welcome Reception. There'll be, um, refreshments and food and just you can decompress with all this fabulous information that now is in your brain. Uh, so... um, I'd like to introduce Harald Alvestrand, and he's going to present the material for the next session. Thanks, Harald.

**Harald Alvestrand:** Thank you. I mean, you might wonder about what this title actually means. I mean, the first... first thing people ask if they don't know the IETF is, "What the hell is this community?" Well, if you've been at the IETF for a while, the other question... the next question is, "What the hell is power?" So, we'll go through that. You've seen the agenda, and this is me and Leslie, who have been presenting this slide deck or variations of it for a few IETFs now. I've been around the IETF since December 1991. That's a few years ago. So, if you want to... if you want to ask me about what the IETF was like in the ancient times, feel free to corner me at Quick Connections. But strangely, it was much like today. It's a very stable society in many ways.

You've seen the "Note Well." It's actually important. Most of this slide deck is about the... the way the community operates. Those processes are not likely to come out and bite you. You want to know why they happen and how they happen, but it doesn't affect your daily life that much. Usually. When you get caught up in things like an appeal procedure, it matters, but otherwise, well, you might want to ignore it. But what's on the "Note Well" are things that can bite you, especially the IPR stuff, which tends to be something that engineers' eyes glaze over. But if you're ever caught in a situation where your corporation is accused of having disobeyed the rules, this can be very, very expensive and your lawyers might be very, very unhappy with you. Just a warning.

Anyway, that's not what I'm going to talk about this time. Power of the community. You've noticed that the IETF... we used to joke that the IETF doesn't exist. But now... nowadays, we're being so formal; we've got the IETF LLC and all that. So in fact, we can't claim that anymore. But the IETF is not the LLC. It's the community. It's the people. Then people ask, "Oh, who is the community? Who's the members of the community? Where do I sign up?" You don't. And nobody else does either. But if you're here, if you're contributing, you are part of the community. And all the power the IETF has and all the power that it's exercised within the IETF leads back to the community. We call ourselves volunteers. It's one of the things I refer to as quite necessary illusions. We participate as individuals to make the Internet work better. That is necessary, and it's sufficient to bring the work of the IETF and to bring the work of the Internet forward. All of us have someone behind us, whether it's your wife that permits you to go on these trips or it's your company telling you that, "Yes, we're going to pay the bills for this trip too." Everyone has someone behind us. But when we stand here, when we contribute, we stand alone. We represent ourselves. And one of the things that the community does is to organize itself, including selecting who leads the organization, who makes the hard calls, who says you can't... can or cannot do something. Well, *we* do it.

This diagram is intended to daze and confuse, and it's the amount of interlinking is almost incestuous. I mean, everything links to everything else. One of the centers of the universe in this is the orange box—it's the NomCom. And we're going to talk a little bit about that. NomCom is one of the stranger ideas about Internet governance. And it was invented around 1993. Before 1993, the IETF was basically an "old boys network." Compared to us now, they were quite young, but still the "old boys network." And they selected each other and say, "Okay, we like you. You... you have the power." But we had what was called a revolution and invented this process called the NomCom. So the NomCom is the... is the group that decides who is going to lead the organization for the next few years. Ten people selected from the community. There are a few selection criteria. You must have been there for a while, as in showing up to meetings or having someone sign off that you're... that you actually should be eligible. And you've got to have volunteered for it. You're not going to be drafted to the NomCom without volunteering—lucky you. And we have a requirement that no... no more than two people should be from the same company. I think the slide is wrong; I think it's allowed to have two, but not three. So there's a nice little RFC that gets revised every 10 years or so about the process, "Operation of the IETF Nominating and Recall Committees."

And this talks about how you pick 10 people at random. And since we're engineers, this RFC 3797 actually has a procedure for doing the randomness. I mean, I think no other organization in the world would be so process-inclined as to document that first. But we do. We're the IETF. NomCom has representatives from some of the governing bodies: IAB, IESG, ISOC, IETF LLC, Trust. Not to... not to make the decisions, but to make sure that these 10 people who are selected randomly from the community have the adequate amount of information about what the jobs they are selecting for actually consist of. Of course, since this is engineers designing process, there's a huge amount of work involved. The... the ISOC President appoints a NomCom chair. The NomCom chair sends out the call for volunteers and lists up the volunteers and runs the random selection process to actually pick out the people who serve. Then we send out the call for nominations, get back feedback, and hopefully people are willing to talk about what they think about what the... about the candidates chosen... candidates that volunteer. The list of candidates that volunteer for the positions in the IESG and IAB and so on is public. But everything else about the NomCom process is completely confidential. What you tell the NomCom, the NomCom will not tell anyone else. Ever. And the NomCom will interview each and every candidate—except for a few exceptional cases, people who are completely not credible—and they will try to make up their minds about who will be the best for these positions.

The process is actually long-winded and complicated so that if it goes completely off the rails, we have safeguards. So once the NomCom has completed its work, it sends it to the confirming bodies: IAB for IESG selections and ISOC Board for IAB selections so that someone outside of NomCom has... has had the opportunity to say either, "Okay, we'll go with that," or, "Are you out of your mind?" Well, usually as in almost every time, the nomination... the confirming body says, "Okay, let's go with that." So this process takes a while, but around January or so, it's announced. The... the terms for most of the positions are two years. So half the IAB and half the IESG is selected every year. So some amount of continuity is always present.

So that's how leadership is selected. Confusing process? Yes. But the point is: the community is the one that selects. If the community, through their volunteers—those of you who get selected by randomness (the governing bodies do not control the randomness)—if the community really, really wants change and someone else to have power, well, in two cycles of the NomCom, they can do it: replace everyone. Usually it doesn't happen. Usually, the people... the reason for people leaving the IESG is because spending four years is enough. People just don't want to do it longer than that. And they're wise people. It's a hard job.

Anyway, the community is also charged with regulating itself and deciding what the processes are for its own regulation. So we have the Code of Conduct again, you've seen it on the "Note Well" slide. We have procedures for managing disruptive behavior—as in, if you actually stand up at the mic and call people idiots loudly, you're going to be smacked down somehow. The working group chair can say, "No, get out of this room." That's just about never happened. I mean, you're perfectly allowed to call someone's ideas incompetent, misguided, or just plain wrong. But we... we talk about the *ideas*, not the *persons*. This idea is stupid is an argument about the idea. *You* are stupid for making this... this proposal is a personal attack and we don't do it. We simply don't. And using the word "stupid" is probably going to be treated as if you have... as if you had said the other thing, so be careful with your language. If some... if some idea is truly broken, you can usually say that is broken and why it's broken without insulting the people who proposed it.

Every working group, every mailing list, every forum that we manage has someone designated as the administrator. Face-to-face meetings, mailing lists, chat rooms—every time, there's a moderator. Usually the working group chair for working group related things and appointed moderator in other cases. And that person has not only the right but the duty to tell you that you're engaging in behavior that's inappropriate. Stop doing that. And if you don't... if the person doesn't stop, to enforce that. We don't want to do it. We want people to be rational, behave. But the tools have to be there because otherwise, we've got experience that things don't go that well.

Anti-harassment procedures—that's outside of the scope of ideas. This is about someone saying that... someone in a meeting say, "Oh, you look so beautiful, but you're making such a stupid argument," or... you're group had to consider that. I mean, completely unprofessional behavior. Or, late at night in the bar, "Now that we've had that discussion, would you mind considering other options for dialogue?" Well, this is the matter for the Ombudsteam. If you're subject to that kind of behavior, behavior that makes you feel that this is not right, this is not how I want to be treated in the IETF, we have an Ombudsteam for you. This is the Ombudsteam. None of them could be present physically at the moment, but they're all available by other communications means. So the Ombudsteam is the other place in the... apart from NomCom in the IETF where what happens there is confidential. You're not going to be told what other people have complained about. The Ombudsteam deals with it. They have processes, they have means to deal with what happened, take appropriate action. But they are confidential. I mean, in other contexts completely outside of IETF, I have been in the position of being informed of what an ombudsperson had to deal with. And some of it, I wish I had a brush to brush it out of my mind afterwards. These people are heroes just for being willing to deal with that stuff. But they're there for you. If you need them, call them.

Now, disagreement. Now everyone has behaved civilly. Everyone has... had... has had their say at the mic and on the mailing list. And the working group has come to... come to a decision or a rough consensus or the working group chair has declared a rough consensus and that means that the working group has decided something. "I still don't agree. This is the wrong decision." Then you have a dispute and you might want to file an appeal. That's not uncommon. Happens all the time. The reason we call it "rough consensus" is that sometimes you're in the rough. Sometimes, most of the working group agrees that this is the right way to go, this is the decision to make. This bit should be reserved for this purpose. This particular algorithm should be allowed. And there's like one, two, three, four people who loudly and clearly has said, "This is the wrong decision, we object." And if you think that the working group has come to the wrong decision, you can appeal. There are two ways to appeal... or two bases for appeal. One is the process thing, saying that my... my objections were not heard, my points were not addressed, I was not permitted to have my input into the process. And there's a technical error, says "This... this result is broken. This is not something that we can make the Internet work better."

And the first thing you do is to try to solve it at the level that the decision was made. You mail to the working group, you stand up at a meeting saying, "I think the decision we reached on the mailing list two weeks ago was a wrong one. I want to reopen the question." You might want to talk to the working group chair privately and say, "You... you ruled that we had consensus but I... but you hadn't given me time to formulate my argument about why it was the wrong decision," and so on. Very often, you can get the right thing to happen just by talking. The working group chairs are sometimes opinionated. I mean, nobody bothers with being a participant in the IETF unless they have opinions, right? So sometimes you want a second opinion. Talk to the AD. That's one of their duties: to listen to people who think that the working group chairs are wrong. And if we can... can resolve this informally, that's fine. That's beautiful. Then we can reach a consensus that includes a larger part of the participants. Sometimes it says... it results in, "Okay, I accept. I was in a rough. You go ahead, do this and reap the consequences, good or bad." But sometimes, even after discussing informally, you must go on. And then that's the time for the appeal. Appeal to the IESG publicly in writing, saying, "What is the problem? What does the decision I am appealing? What is the reason why it's appealable? What is the actual argument made for saying this was the wrong decision?"

The IESG has a... a specific timeline for having to consider the matter and reaching a decision. It's one of the things that the IESG doesn't like to do because many of the people who make appeals are very good at making long-winded documents that are hard to penetrate to what the actual dispute is. And yeah, it's troublesome. But that's the reason why it's... that's one reason why it has a defined timeline so that the IESG will have to get around to it and answering the appeal. The appeal... the appeal result is usually one of two things: decision stands or go back to the working group and try again. And if it says "Go back to the working group," that's a message to the working group chairs that you'd better come back with either a different decision or a more well-founded decision. It doesn't mean that the objector was ruled correct; it means that the decision is annulled. And of course, if the IESG says that, "No, this is stupid, this is... just don't bother," the decision stands, then we can appeal to the IAB. IAB is the... for technical objections, the final... final arbiter. If you didn't manage to convince the working group and didn't manage to convince the IESG, IAB is your last chance. And all this is public. It will be preserved on the Internet forever. In some... some circumstances, you can claim that the process was not followed. And then it's possible to appeal even the IAB's decision to reject your appeal to the Board of Trustees of the Internet Society. But that's more or less saying that the I... the IESG and IAB behaved in a way that was not... was a violation of procedures as documented in the BCPs and so on. And that can be tough. It happened very rarely, if at all.

So these are some names of appeals, including the names of the appellant. And as you can see from the numbers, most appeals go to the IESG and stop there. And some appeals... only... a lot fewer go to the IAB where they have to say yes or no. And every appeal and every response is recorded and available on the website as everything else. This is a public process.

So to recap: the IETF community is you. You can't exactly define the boundaries of inside and outside, but it's you. The IETF community selects its own leadership. The IETF community makes decisions. Decisions can be appealed to the leadership to say this was the right decision or this... or go back and try again. Everything is public except for two things: NomCom deliberations when choosing the leadership, and Ombudsman deliberations about inappropriate behavior. Those two things are secret because in those contexts, people need to be able to speak their minds without any fear of retribution. This is the IETF. This is an open process. This is who we are, and this is how we behave. Questions? Comments? I hope someone's awake. Or coffee. Okay. We’re done.

**New Participant Program Coordinator:** All right. Thank you, Harald. Thank you very much. Oh, I saw somebody about to clap. Yeah, we'll give Harald a round of applause. That's a... a lot of important information that he covered. Necessary and important. Um, Jay's coming up to the stage here. We're just going to do a very quick 10-minute wrap-up session. I'm going to review some of the things that are happening during the week. I'm just going to switch the slides over real quick. 

**IETF 120 Wrap-Up**

**New Participant Program Coordinator:** So, thank you all for coming today. Um, I hope you found that useful and interesting. Um, that was the easy part, of course. Um, now the more difficult part is writing the technical standards. So that the goal of today was to have you leave here with a general information about the IETF and how it all fits together; to give you some useful information for this meeting, your first IETF meeting; to give you an overview of the leadership and the resources and tools that are available to you; to introduce you to the hackathon that took place; to give you a basic understanding of the standards process and get you started writing your first Internet Draft and to give you some idea how to be effective in the IETF. Um, hopefully this has worked and you have found that useful, um, as a way going forward. We will be sending out a... a questionnaire later, a survey about this, to have your views. And we're very interested in your views because we are, um, regularly updating the agenda and this... this program to help people.

Okay. Um, just a quick look at the rest of the week ahead. Um, following this session, we have our Quick Connections session up on the 40th floor. Um, that's a session where we have experienced IETFers from the leadership, and it gives you an opportunity to meet them and ask questions and maybe they can guide you in certain directions if you're looking for particular working groups to go to. So, uh, that's a little fun event tonight. Um, Monday we have the new participant dinner. I believe there are five spots left open; otherwise, it's going to be sold out. And that's just a very informal dinner just to get to know the cohort of new participants that you're here with. On Thursday, we have a new participant social hour. Uh, that is a chance again to meet with some leadership, talk about your week, what went well, uh, what kind of things can we do differently to help you as a new participant at the IETF, and it's just to relax and... and chat with, uh, other new participants as well. This information is all on the agenda, and I do send out daily emails to the new participant mailing list with this information. 

Um, other activities happening: uh, we have the Welcome Reception after Quick Connections. It's happening in the rooms just right next door. There will be refreshments, uh, food, drink, and, um, just a chance to unwind after this very, very long day, um, let your mind just relax a little bit. Um, after the Welcome Reception, we have that Hot RFC Lightning Talks that was mentioned earlier. Uh, it's not a question-answer type of session. It's just, um, a couple-minute talks very quickly, let people, um, express some new ideas, maybe gain some interest. So if that's something you want to, uh, again see how Meetecho's used and just hear people give some presentations on some fun ideas, definitely, uh, attend that. We have a Sister's Networking Breakfast, uh, that is Monday morning. We have Wednesday night is the IETF Plenary. That's when the IAB, the IESG, and the LLC Board, uh, come to the stage. It's an opportunity to get information about, uh, the administration part of the IETF. And there is an open mic session for each of those leadership bodies. 

Um, then on Thursday, we have a host speaker series. More information on the agenda there for who's talking and what the topic's about. Sisters has a lunch on Thursday, and then we have our farewell reception on Friday. Again, all the information is on the agenda. This is just a list of some, um, other things that might be helpful if you didn't catch it in an earlier email. There's this blog post of new topics that might be interesting to new participants. Got a lot of great information. Please, uh, go ahead and read that. Um, and we mentioned too that during the week just outside in this hallway, uh, next to registration, you're going to have some help desks out there. Um, also the IAB will have two different time periods where you can talk to them about new work, and I'll be sending emails again to remind you of the day and time. Um, also happening is we have the social event on Tuesday night. If you have not purchased a ticket, there are still plenty available. So that's going to be a really fun evening, and it's just, um, in the conference hall, um, just a short walk from here. Wednesday night we'll be having a game night. Uh, if you're interested in playing any games, we bring some of our own board games, um, card games, all different kinds of things, um, and IETF participants also bring games themselves. Just a chance to get to know each other. 

I think I have covered everything else for the week, talked about the desks. Um, also if you have any issues during the week, support@ietf.org is an email address that you can send, uh, questions to or any issues to, and we will do our best to get to those tickets as soon as possible. Above all, I think Jay said too, we want you to enjoy your week. A lot of information, it's a little bit exhausting. We are here to help you, um, accomplish whatever goal you're setting out for coming to the IETF meeting. And so find us with green shirts. We're happy to guide you, help you, talk to Jay. And we do wish you a wonderful, successful week here at the IETF meeting. So thank you, and we'll stick around for a little bit for questions. Otherwise, we'll see you at Quick Connections. Thank you. (Applause)

---

**Session Date/Time:** 15 Mar 2026 01:30

**Michelle:** Good morning everybody. We're going to get started in just a minute.

(Clapping)

**Jay Daley:** Good morning. And welcome to the IETF.

(Clapping)

**Jay Daley:** So today will be a program for new participants to help you understand the IETF. The IETF is a complex organization, and so we provide this training to help you understand the IETF from the beginning. I will be presenting this first session. I will explain who I am and more in a minute. And then you can see we have these other sessions throughout the day. At the end of the day, we have a special networking session for you to come and meet members of IETF leadership and talk to them more directly about any interests that you have.

### Session 1: [New Participant Program - Session 1 - Introduction to the IETF](https://datatracker.ietf.org/meeting/125/materials/slides-125-newparticipant-sessa-new-participant-program-session-1-introduction-to-the-ietf-00)

**Jay Daley:** So this is who I am. I am the Executive Director of the IETF. I have been doing this work, this job since 2019. I've been working in the internet a long time. I started networking actually in the 1980s, and then working then in the 1990s on schools networking and then the domain name industry for many years. One of the things that you will see a bit in this presentation is some data from surveys. That's one of the things that I'm, I feel is particularly important is using data for good decision-making. And also, like many people in the IETF, I believe that we need a free and open internet for the future of the world.

So this is what you can expect from today. The IETF, as I said, is a complex organization. It is very broad in scope. It is large in activity and there are detailed practices and rules. And so for new participants, this can be a problem to get involved. And so what we aim to do today with this program is teach you all the important things for you to become a productive and effective IETF participant and to reduce the chances of you giving up. We also hope to build a cohort of new participants that can engage, support, and work together throughout their IETF journey. There will be people in the IETF who have known each other for 40 years and who work together on many projects. And if you get to know people through this program, then that will help you on your journey in the IETF. We also aim to give you a head start in meeting people, including leadership and long-term participants, and to find out what the hot topics are.

So before we go into the details, we're just going to start with Meetecho because this is such an important tool that we use throughout the meeting week. So Meetecho is the IETF custom tool for remote participation. It's actually produced by a company, Meetecho, who all of the workers there are IETF participants. It's a small company in Napoli in Italy, and they have been part of the IETF process for many years. And they have built some open-source tools and then this tool on top of it that we use for our meeting participation. So all sessions are linked off the Datatracker agenda page, and there is this QR code in every working group session for you to scan. 

Now, Meetecho is important because we use it to track who is in every session. You need it to be able to join a queue to speak and participate. And also it provides the chat facility for people to talk to each other. And it also allows you to get to the materials that you need. 

So here are some just very useful buttons for you to understand. We have the normal controls that you might expect on the top line, but our special controls are on the bottom line. We have our chat facility. We have our show of hands tool. So in some sessions, the chair may ask people to express a preference to understand the way forward. It is like a voting tool but we do not call it voting. It is simply to help us understand the feeling of the room, and so we use that. And then we have the map, we have access to the materials, participant list, all the things you might expect. 

So when we during this session for today, if you want to ask questions, we have two microphones there. You can come up and ask the questions. It is best if you use Meetecho to join the queue to ask questions because then we know about it. But because this is your first day, first session, if you forget, that's fine, you can still come up and ask a question.

Okay. So about the IETF. The IETF is a standards development organization focused on internet technology. So that is the core purpose, is to create technical standards. It has no formal membership. Anyone can participate. People participate as individuals, not as representatives of their employer. Now, what that means is that just because you work for a particular employer does not give you any greater voice in the IETF than anybody else. 

The standards that are developed and the IETF is driven by market-based adoption of the standards. A real standard is one that people use. The IETF is not here to create technical standards that nobody uses. It is here to create technical standards that people find valuable and use on the internet. 

It is a bottom-up community-controlled organization. So many of the things you will see today have been created by the community here, creating the rules for the way the IETF works. My role is to support the community, not to tell the community what to do. This is very different from other organizations. 

Most decisions that we have here are made by rough consensus, not by voting. So we want to get to the position where most people agree with the way forward. And there is no formal role for governments. There are government people here, but in the same way that with companies they do not have any special authority, governments do not have any special authority in the IETF. 

And the best bit, you may have noticed, there are no sales booths outside, there are no marketing people. This is all largely engineers, researchers, policy people, you know, people here to do the work, not people here to sell things to anybody. Okay? So this is a very comfortable environment.

So this is the mission of the IETF: To make the internet work better by producing high-quality, relevant technical documents that influence the way people design, use, and manage the internet. This is a very low-key, very simple way of explaining the role of the IETF.

So a brief history of the IETF. The IETF was formed in 1986 by the then Internet Activities Board as an engineering activity. So this is engineering. The first IETF meeting was attended by 21 American federal government funded researchers in 1986. Outside, I just saw Lixia Zhang, who was one of the original researchers that was there. And there will be another man Bob Hinden and Mike StJohns I think, or maybe, oh he's not here, no, who are, who are here, who were there from 1986. So they are around. 

The internet standards process, the procedures for developing internet standards were formally documented in 1992 and have then been revised. The IETF initially met four times a year, now it meets three times a year. So today, this week we are in Shenzhen. Then in July we will be in Vienna, and then in November we will be in San Francisco. Our meetings are always open to the public. Anybody can come. You do not need to be a member. 

Now, the RFC series is older than the IETF. RFC 1 was published in 1969 by Steve Crocker of UCLA to organize the working notes of the original research project. And we are now approaching RFC 10,000. And again, Steve Crocker still participates in the IETF. These people are still here participating, many of them. 

Interestingly, online data access in the form of FTP was defined in early RFCs, and so the RFC series became the first online publication series because you could access it by FTP in the 1970s. So and for 28 years, the RFC series was managed and edited by the internet pioneer Jon Postel, who is one of the original inventors of the internet.

So I'm now going to tell you a little bit about the other people that come to the IETF. This is based every year we run a survey of everybody in the IETF, and this is based on the survey from December 2024. We did our survey in December 2025, but we have not yet finished analyzing the results, and so this is a little bit out of date, but still very relevant. 

So we have approximately 53,000 email addresses subscribed to our mailing lists. And we know that we have 7,000 active participants a year. That means people that come to IETF meetings, people that send emails to our mailing lists, people that are authors of documents or people that contribute to GitHub repositories. So 7,000 of the 53,000 are active. 

And this is our breakdown of the 53,000. We see roughly 12% consider themselves active participants, which roughly aligns with the 7,000. We then have another 24% who are occasional participants. So they will read the mailing lists and sometimes send things. Then we have the people who read and the people who only occasionally monitor mailing lists at almost 50% of the email addresses. Now that shows us that IETF standards and the IETF process is very important to people if we have, you know, 25,000 people watching the IETF but not participating in the IETF. And then 6% are new participants like many of you here today. 

Then we have the breakdown by region. And as you can see, the two largest regions are Europe and North America, which are approximately 40% each, reflecting the historical origins of the IETF. And Asia is at 11%. And Asia is growing as a proportion of the IETF, but currently still much lower than the other two large regions. And just a note, Oceania, which is Australia, New Zealand, and the Pacific Islands, is over-represented. So your first presenter today is me. I'm from New Zealand. And your second presenter is Bron, who is from Australia. So you know, we control the first bit of this presentation. 

Okay. So this is the breakdown by age. As you can see, the median is somewhere in the 45 to 54 age range. This is a very old set of participants compared to many other organizations. And that is because people once they enjoy the IETF, they stay in the IETF. There are lots of people who when they move from one company to another company insist that IETF participation is part of their role. They try to keep IETF participation going while they change companies. 

Then we have the not-so-good story, which is our gender breakdown. So as you can see, approximately less than 10% of our participants are female. This is changing over time. We have many more women coming into the IETF in new participants, but still this is a very male-dominated community. That will change and it is changing, but that is the truth at the moment. 

Then we look at how people are employed and where they are employed. The majority of people, as you can see, are have are employees of an organization. Then we have business owners, people who run their own company, small, medium company where internet standards are important to them, and they will come here to understand those those standards. Then we have independent contractors. We have lots of people who have been involved in the IETF for many years and have become an independent contractor doing work for lots of different companies because standards is such a specialist subject. Then you see we have still retired people. 9% of people are retired. They love the IETF, they still come. And then we have the students and others. 

When we look at the employment sector, we see that business is the largest sector, but academia and the research sector is the next largest and quite large. We also see civil society, the non-profit, as a large part of this. People who come with policy objectives to work on the technology match here. And then government at 12%. So we have a, you know, a good spread of employment sectors. 

Now we ask people when did you first participate in the IETF? And we do this little chart. And as you can see, we have 25 people who answered who first participated in 1986. So we do have, you know, long history of people involved in the IETF.

So the structure of the IETF. The structure of the IETF is very simple. Okay? Easy to understand. So on the left, right, we have the I will go through these groups. We have the IESG. Then we have in purple. Then we have in red the IAB. Then we have the nominating committee. I'll explain that as well. Sorry, on the left is the IRSG, sorry, the Internet Research Steering Group. Then in yellow in the middle we have the IESG. And we in the middle the blue there is the IETF Chair, the very special role within the IETF. Then next to that we have the IETF Trust. Then we have the IETF LLC, which is what I work for, and my role is in there. And then on the right we have the Internet Society. I will explain all of these, and there will be a short test afterwards about this diagram. Okay, for everybody.

So the IESG. The IESG is the peak organization within the IETF. It has overall responsibility for the standards process and technical management of IETF activities. The IESG is made up of the area directors and some liaisons. The IESG is chaired by the IETF Chair, and the IETF Chair is the chair for the whole IETF community. That is Roman Danyliw. He is unfortunately not able to come on site, but he will be presenting and working remotely throughout this week. 

Then we have the Internet Architecture Board. This provides long-term technical direction for the internet architecture and I will go into more details about them later. And responsible for external liaisons and some key leadership appointments. That is chaired by the IAB Chair Tommy Pauly. 

Then we have the Internet Research Steering Group, which manages the research part of the IETF, the Internet Research Task Force, which is focused on long-term research issues. And that is chaired by the IRTF Chair Dirk Kutscher. Dirk is here. Dirk actually works for the for a Hong Kong university based on mainland China. So he is here.

We have one person in the queue. Would you like to come up and ask your question? Benjamin? No? Okay. We'll carry on.

So then we have the IETF Administration LLC, which is so I'll go back to the diagram. So we have done the IESG, the yellow, the standards body that controls the internet, and that has the areas underneath it. In yellow has the working group chairs and has all the working groups down below. That part there. 

So the IESG there, the areas there, the working group chairs, and these are the working groups that do the work, mainly within the IESG, within the IETF. 

This here is the IAB, and we can see the programs and other things which I will explain later that the IAB runs. 

And so now we have the IETF LLC. The IETF LLC is the administrative organization for the IETF. We are the legal representative of the IETF. We manage the finances, we provide the we run the meetings, we provide the tools that you use. That is the role of the LLC. 

Then we have the IETF Trust. The IETF Trust is unusual organization. That holds the intellectual property of the IETF separately from the IETF to protect that intellectual property. We will talk more about intellectual property later to explain that. 

Then we have the Internet Society on the right. So this is the global Internet Society. That is technically the parent organization of the IETF. For many years it did the role of the IETF LLC, and that provides much of the funding to the IETF for the IETF to operate.

So just to give you some faces for you to see later. This is the IESG, the Internet Engineering Steering Group. I think five of them are here maybe, who you can meet this evening. 

And so now we move on to the IAB. The IAB is has a new chair now, who is Dhruv Dhody in the top right there. Dhruv is here and seven of these members of the IAB are here and you'll be able to meet those as well.

So a little bit more about the IAB. The IAB has a long history. It was previously called the Internet Activities Board, now it is called the Internet Architecture Board. It is a committee of the IETF and an advisory body of the Internet Society. So it is part of the IETF. 

But it has a very specific role within the IETF. First part of that is architectural oversight. So it looks to the future about the big things that are changing the internet to understand those and help shape how those are then brought into the IETF as part of the standards process. And it does that through technical programs and through workshops. 

It also does liaison coordination. So the IAB is responsible for working with other standards bodies and with other external organizations in the internet space to provide the relationships with those. 

It does some appointments work as well. We have we have a complicated process for appointing people to positions of leadership to ensure that there is no opportunity to capture the IETF and to ensure that the right people are chosen for the right role and that if there is a problem, there is a mechanism for addressing that. 

And then the final role of the IAB is it is the final part of the normal appeal chain if somebody wishes to appeal a decision.

So this is some recent work of the IAB. There are some things missing from this that I forgot to update. So the IAB runs programs. It did one on evolution, deployability, and maintainability of the internet. It also just ran a workshop on age verification, an important one, and the AI Control workshop is now a a working group looking at AI preferences and things. The there are some very important RFCs that have been produced by the IAB. RFC 8890, The Internet is for End Users, is an example of such an important document.

So the IRTF. The IRTF is we call it the sister organization to the IETF. It is both part of the IETF and parallel to the IETF. It is the research organization. There are these 16 research groups within the IRTF, many of whom are meeting at this meeting. 

It, as I said, is headed by the IRTF Chair Dirk Kutscher. He is appointed by the IRB, sorry, by the IRTF, sorry, say that again, he is appointed by the IAB. Okay? 

The IRTF operates similarly to the IETF but with some key differences. Research groups are do not have deliverables, they do not have milestones. They are genuine research groups which are expected to live for a long time and expected to find their work as they go along. 

Research groups, the IRTF can only publish informational and experimental RFCs. They cannot publish technical standards. They do not follow consensus. So research groups may publish two RFCs that fundamentally disagree with each other. 

And the IRTF has an additional code of conduct covering academic integrity and research ethics and more. 

So here are some examples of recent RFCs published by the IRTF. RFC 9620, Guidelines for Human Rights, Protocol and Architecture Considerations. Some interesting ones down here, the Ristretto 255 and Decaf 448 groups which is cryptography related. A lot of cryptography things take place there. So but all of these are informational or experimental, so not technical standards.

So now on to the administrative people. So we have the Secretariat. Michelle is a member of the Secretariat here. So they are the team that plans and manages IETF meetings. They are the people walking around wearing the the green tops and wearing the tie-dye on Fridays. They are the people who organize the meeting and run the meeting. If you have a problem, you know, ask Michelle. Okay? 

Then you have me as the Executive Director who does nice talks like this and will be walking around checking you're all happy. 

And we have IETF LLC staff. We have our some of these staff are here, but the important thing the on the bottom three, Kasara, Matthew, and Rudy are here. They are three senior developers, and they will be on a desk outside here at some points during the week, and they can help you understand how the IETF tools work. And if you're interested in contributing code to IETF tools, they can explain to you how to do that and how that works. All IETF software is open source. It is all on GitHub. It is all available to anybody to use and to contribute to.

We have some specialist technical services here as well. We have the RFC Production Center. They are the team of staff who edit and publish the RFCs. So when you have done your work within a working group on an internet draft and it is ready to be published, it goes to the professional editors who then work through it to make sure that it reads well, to make sure that everything is correct in it, all the references are correct, and then they publish it. 

And then we have IANA, the Internet Assigned Numbers Authority. As you know, many technical standards have protocol parameters, you know, numbers that mean different things for different protocols, and we need registries of those. And IANA maintain, I think it is about 8,000 registries of protocols for the IETF. And they are here because so much work is generated for them through the IETF.

One team which we we want to tell you about because it's important is IETF Sisters. As I mentioned earlier, we have low participation from women compared to the IT industry or compared to the overall population. So we have this special team, Sisters. We have a a breakfast and a lunch where women come along to meet other women to network and understand learn more about the IETF.

So finally about one slide about funding. The IETF is a not-for-profit. The IETF is very different from other standards development organizations. You cannot buy any form of influence in the IETF. In other standards organizations, you can pay money and you can have a seat on the board or you can have an approval role, but in the IETF, money does not buy influence. 

And so we receive money entirely as donations or as sponsorship for the meeting and some fees for these meetings. So we receive approximately 7 million, 8 million this year from the Internet Society. Our fees for the meetings are about two and a half million. 

And then our corporate sponsors. So we have CNIC and a number of others. We have sponsoring this meeting ZTE, we have parts of CCSA, we have Huawei. They are our corporate sponsors that help us operate these meetings. And as well as giving us money, they also give us free equipment and services. 

And then the donations we receive are about 300,000 a year. So that is how we operate. We make a small surplus each year, but we are not a profit organization. There is no nobody gets the profits from the end of the organization. We are a not-for-profit.

So almost into the last part of this. Because you come to the IETF and because you participate, there are some policies that you must follow, and we want to make sure that these are very clear to everybody. We put this slide up, the IETF Note Well, at the beginning of every session. You will see this up on the screen. This is to remind you of the policies. This is the only session that does not begin with this slide. Every other session will begin with this slide to remind you these are the policies in place. 

And the first policy that you can see there is to behave in a professional manner and extend respect and courtesy to colleagues, to other people's here. That is the first one. 

Then we then talk about rights and intellectual property and other things. This is because there are we have companies here who are competing with each other in the marketplace. And we need to have rules about intellectual property to ensure that those companies can come here and talk openly. We need to do that to meet government regulation and we need to do that to make sure that those companies are working fairly with each other when they are here. 

And then finally to note the the bottom one, the IETF is a very transparent organization. We publish almost everything. So this video session now will be online forever. We will put it available to to watch it. And so people are sometimes a bit surprised by that, but we make everything so so public.

Starting off on the intellectual property side because this is important for you to understand. When you come to an IETF meeting, anything that you write or say in an IETF session in one of these sessions or on one of our mailing lists is we consider that a contribution to the IETF. 

And we consider that you have given us a license to use that contribution for the creation of standards and for for us to publish it and for us to do other things with it. So if you are participating, you are automatically sharing with the IETF and we are able to use that information within the IETF. That is the way that standards organizations must work.

Now, as I said, we are an exceptionally transparent organization. So we publish the following things and almost never censor or redact these. We publish the names, organizations, and country code of all meeting participants. We publish audio, video, and transcripts of all sessions. Some, well, there are some private sessions, but everything else we do. 

We make available messages to most mailing lists and our chat messages are available. And we also publish all communications that we receive, official legal communications such as subpoenas or letters from lawyers. 

We do not sell your data at all. And we do keep certain things confidential related to application to roles, feedback, grants, financial information. Generally we keep confidential. And this doesn't matter so much, but for the Europeans who wonder if this is GDPR compliant, yes, this is GDPR compliant. Really, we are experts on GDPR.

So patents. Just to be clear about those as well because that is again very important. The IETF works on the basis that people need to disclose patents that they are aware of that might have an impact on the standards process. Though these are the rules under which those patents must be disclosed. Okay? 

We do not check the disclosures, and we so if you think a disclosure or a patent is false, you have to speak with your own legal department and do that. But what we are after here is transparency. Okay? So people tell us about tell us about patents so that we know that they exist and so that participants when they are developing the technology can make an informed decision about whether or not they wish to participate and that working groups can make an informed decision about whether or not they wish to move forward with a particular technology based on, you know, patents there. 

So this is what an IPR disclosure looks like. We have a web on Datatracker our main website, which Bron will go through. We ask people to declare patents. So this is important to us. And this is the the simple form that allows people to disclose how patents work for us. 

Right. So do we have any questions at all? You can invent a question. If you want to know where the bathrooms are, please come and ask. Any questions at all?

**Michelle:** And we'll take this as an opportunity that if you haven't yet scanned that QR code that Jay mentioned before, we have them on the microphone there. There's also some boards in the back of the room. If you could make sure you scan that, let us know that you're here.

**Jay Daley:** Okay. We we never have questions normally. Except, you know, people who are stuck with the power or something. So that's fine. So just to remind you, we have the sessions today and I hope to see you at the quick connections for new participants today and at the welcome reception as well later today. Okay? Thank you all very much.

(Clapping)

**Michelle:** Our next session will be starting in about 15 minutes. If you do want to test your Meetecho to join the queue and you can take yourself out of the queue just to make sure it's working, this is a great opportunity to do that as well. 10:30 is the next start time for session two. There are some beverages just outside the room for you all, so please help yourselves.

### Session 2: [New Participant Program - Session 2 - Participation in the IETF](https://datatracker.ietf.org/meeting/125/materials/slides-125-newparticipant-sessa-new-participant-program-session-2-participation-in-the-ietf-00)

**Michelle:** All right everybody, we're going to go ahead and get started with session two. I'd like to introduce your speaker here, Bron. And yeah, if you haven't already, please make sure that you scan that QR code so that you're in the Meetecho room. You'll hear that reminder a lot this week.

**Bron Gondwana:** All right. Thank you Michelle. I think I'm required to say "G'day" as as an Australian, even though I live in the United States now. Welcome to the second session of your introduction. This is a long day, I'm sorry. Hopefully I will say interesting enough things that you will you'll feel that you're getting value out of this. 

So this is the second session of a large section of things. I'm going to be talking about mailing lists, how to use the Datatracker, and a bit more about IETF meetings. I'll give you the spoiler up front: We come here in person to build the relationships that let us get the work done for the rest of the year. So most of the work at the IETF happens...

Oh yeah. Let's talk about me. This slide is now slightly out of date. I no longer write C and Perl. I talk to an AI that writes C and Perl and then I read it. So some of the things I will be mentioning today are the fact that the world is changing pretty fast and telling you where maybe I think AI is a good thing to use and isn't, but let's not talk about that the whole time. I've been doing this email for over 20 years. I've been coming to the IETF for nearly 10 years. When I saw that graph of the times the years people have started at the IETF, I was in one of the least years. There were not many of us started in 2017, but there's a few.

All right. The Note Well. This will come up in every single session. You don't need to read it every time because it doesn't change, but you do need to read and understand this. As Jay said, anything you do here is a contribution to the IETF. Anything you stand out up at a microphone and say might get used to build the future of the internet. That's a good thing. But do understand what this means. 

All right. Have you read it? Quick show of hands. Hey, nice. This is another thing I'll be talking about: reading things at the IETF is a superpower. Most people won't. So if you show up to a meeting and you have actually read the documents, you're ahead of most of the people there.

All right. Email. Jay gets a lot of information about what happens at the IETF and showed you a pile of information. I think this is the only statistic I have for you: mailing lists are by far the most popular way for people to communicate at the IETF. Looking at all these things that people say how they like to be involved, mailing lists are where it's at. Everything that goes to the mailing list, it's a contribution just like everything you say here. All decisions are finalized on the mailing lists. So you can join any one of these mailing lists and you have as much authority there as everyone else. Thanks Barry for joining me in the hat brigade. You have to take it off later in this, it's very important. 

All right. There are a lot of mailing lists. I would recommend joining some of the ones on here or at least looking at them and any area you're interested in the work. You can go and you can read all the discussions that have happened over the last 50 years about that topic. So you can understand what's been looked at already, what people thought about it and come to the meetings prepared. It's definitely worth joining the mailing lists. It's worth understanding how your email program works to allow you to filter them so you don't have to read everything in real time. But these are these are the place where a lot of the work happens.

All right. This is just a detail, you can read this slide later. It's Mailman 3, it's a fairly standard way that mailing lists work. The one interesting thing is once you subscribe to one mailing list, that means you have agreed to the Note Well, the thing that you saw up there, the thing that you said you would obey by coming to this meeting. And from there you can send to any of the mailing lists once you've joined one of them. And in highlight down there, agreements we make in this room or in the other rooms here during the week are not final. The final decision is always made on the mailing list. So you don't have to be here in person to contribute and to have an equal voice. 

So why we're here in person? We're here in person to build the relationships, to build the trust, to meet people so that when you are this random person on the email list, the other person thinks, "He's someone who understands things. I know this person, they're they're sensible, they're not an idiot. They might have something worthwhile to say." That makes a big difference, yeah? Because there's a lot of people in the world and you have no clue whether they understand what they're saying. All you have is what they've written in text. People come across as jerks in text. You come across worse than you do in person, the other people come across worse than they do in person. And so building this relationship here will mean that what you do on the email list will get you, as Jay said, paying money won't get you listened to. But showing other people that you understand, that you know what you're talking about, that you make sensible technical tradeoffs, that will get you listened to. So that's the kind of bribe that actually works. And I will certainly take those bribes in my working groups. 

All right. This is what the mailing list looks like on the web. You can go through, you can see all the messages, you can search, you can sort, you can filter. Go play with it. Log into the Datatracker. That's another thing I'll say a lot today: log into the Datatracker, poke around. You mostly can't break things. If you do break things, that's a problem for the tools team and they will fix it and it will be their fault. So it's fine. Poke around, look at things, try it out, figure out what how it all works.

This slide tells you how to write email. I'm sure you all know how to write email. The one thing I'm going to add to this is: don't use AI to write a long email. You're wasting everybody's time. Write your own words, keep it short, keep it to the point. Try to do one topic per email. If you do lots of different topics in the same email, it's more likely people will miss one of them. And think about the fact that every email you send is going to be read by hundreds, possibly thousands of people. Respect their time and they will respect you more. All right. And then some little details about what's nice, but people often top post and do rich text formatting and it works just fine. So don't think there's hard and fast rules. Work out what works in the working group you're in.

All right. The Datatracker. You've all been to this site already because this was the login site that got you to scan your QR code and you're all logged into Meetecho, right? Of course you are. Yes. All right. Again, look around. There's details on all the people, there's information about every single working group. It's all linked to from the agenda. And I think I've got a slide on that later that shows you the agenda for this week and how to find what to get to. 

There are nine, I think eight or nine parallel tracks every single day. There is far too much to get to every single session in person. It's all recorded. You could spend the next three weeks catching up on everything that happened at the IETF. I recommend anything you're interested in, go to the meeting, meet the people, see what's being discussed in the room. Use your time here to meet people because that that's what it's all about. 

All right. When you log into the Datatracker it looks like this. Across the top there's some menu items, it's a standard website. Right in the middle there, search. You can search for any keywords, authors' names, technologies in the Datatracker and it will show you current drafts that match that. It's a way to find things. I really only use that when I actually know already which document I'm looking for and I tend to normally go through the working group to see the list of what they're discussing. And you can find that from the agenda. But it's there. Again, play around. You probably won't break it. If you do, it's not your fault. So see what you can find there, see what interests you. There's even a report a bug link.

Authentication. Everything logs in through Datatracker now except the mailing lists which still have their own. Sometime late in 2025 or early 2026 it says, so who knows? It might happen this week. But for now you still need to log into Mailman with a separate password, but everything else is done through the Datatracker login. So that one password gets you into all of IETF resources, including the notes system that we take notes during the meetings, the wikis which I'll talk about in a second, and obviously the registration that got you into this meeting.

All right. Meetings. This. You're here at an IETF meeting. There are three of them per year and as Jay said, we'll be in Vienna and we will be in San Francisco later this year. There are so many sessions happening and go to them. 

A session the rooms are different sizes. This is one of the kind of a medium size room. I think there are bigger and smaller rooms than this, but the arrangement is the same. There are microphones you can speak locally. There is the remote system where people will connect in. I think you'll see someone join later today so you'll get to see what that looks like as well. And remote and local participants have the same rights. You enter the queue using your phone, using your laptop or maybe asking the person up front nicely if all of your technology's broken, but you are in the queue with the remote people and it will alternate between them. So standing at the microphone no longer gets you special rights. You need to enter through the system. 

All right. Everything as you can see, the AI is telling you what I said down the side there. This is also recorded. All the sessions are recorded. You can find them online later and people will be taking notes. And everything pretty much works like this, a really it's a really good system. This is one of the most remote friendly conferences I've been to.

All right. Hats. Ready, Barry? Are optional. When you're here you are representing yourself. You might be also representing a company. Obviously I represent my company, my company's interests are part of what I'm doing and I state who I work for so that people understand that when they hear my contributions. But I don't get special rights due to it. You don't get special rights due to the company you work for. You are one person with a say same as everybody else. 

It is worth reading and understanding how rough consensus works at the IETF and asking people if you're not sure, because what it comes down to is good clear specifications and running code. So it has to be technically understandable, it has to work with the rest of the internet, and you need to persuade the other people here that you know what you're talking about, that your thing will work. And so the rough consensus is everybody gets heard, everybody's objections get heard. It doesn't necessarily mean that you can block work from going forward just because you personally hate it if you can't articulate a good technical reason why it won't work. But if you do have a good technical reason, you will be listened to and people will take that into account. And that process is slow. 

I don't know if there's slides later about how long it takes a document from idea to final delivery to take at the IETF, but it's about four years, give or take. Yeah, there you go. Next session you'll hear all about that. It takes a while for documents to get through this process, but they come out better. And the fact that you're all here, the fact that the IETF has been around for 50 years, the fact the internet is built on that is a testament to this process working. So you're in the right place to build the future of the internet and your contributions will last a long time. It's slow but it also it's the foundations that everything else is built on. 

All right. And then some other details there which are definitely worth reading. I won't read them out to you. Most of you have the new participant thing on your badge. You'll also see that people have colored dots. I have the blue dot which says working group chair and thankfully no other responsibilities other than this session. But you can see from there. Other important thing, this is white. This means I don't mind having my photograph taken. If you're wearing a red lanyard, please do not photograph people with a red lanyard, they would prefer at least a little bit of privacy. There is a professional photographer taking photos around here as well and they will be obeying these as well.

All right. Meeting technology. The Datatracker has an agenda. This page lists all the sessions where they are. There are also a bunch of icons down the side and they link to different things about the meeting. So they'll give you the materials telling you the agenda, any slides that have been proposed. You can download and see somewhat in advance. They might come through pretty close to the meeting. You can also connect to the tool. If you didn't scan the QR code, from every single agenda item you can connect to the same tool from your phone or from your larger device and you can join the meeting through there. You can even go sit in your room and join multiple meetings in different tabs in your browser and listen to all the sound streams at once. It's very painful, don't do it. But you can see all the things that are happening on this page. I spend a lot of time on this page during the week, you probably will as well. 

Meeting network. On the back of your badge there's a password. If you haven't got that working yet, do try to log into that so that when you need it you know that it works. And that will connect you to the IETF 125 network or IETF 125 hotel which works throughout the hotel. The IETF 125 works inside the meeting rooms themselves.

Zulip chat. So there's a chat system built into the Datatracker, sorry, built into the Meetecho that shows you some kind of side text conversation that's happening alongside the meeting itself. That is also available between the meetings and it has you can join any one of the working groups and you can see the chat that's happening during the meeting and also in between meetings occasionally. It's worth having a look at setting that up. You can install it on all your devices, it's available as an app. And that echo is what's happening inside the meeting. So you can be in there or you can be logged into the meeting and it will be the same chat.

There's a wiki. It has a bunch of information about every single one of the meetings. This slide is the previous one but there is information about the venue, about the area as well. It's worth having a look at that. You can propose edits to it and the Hackathon also has its own you'll see more about that later has itsown wiki as well. All right. I think we're getting close to the end here.

This tool Meetecho, you'll be spending maybe just logging in through the QR code but if you're presenting in any sessions then you'll be using this to get in and and upload your slides. Oh no, you upload slides through the Datatracker. They will appear in here. You can also see who is speaking, who's got questions. I see someone has popped up their hand now. Would you like to hop up to a microphone? All right, Grace, welcome.

**Grace:** Thanks. I'm a little bit confused about the Zulip chat versus the Meetecho chat. So like is all the Meetecho chat in Zulip and then it just has more persistence? 

**Bron Gondwana:** Yes. So this this chat will when the meeting closes, you won't be able to use that URL to get there anymore, but the persistent chat will be there with everything that happened in the session. 

**Grace:** And then you can also continue to chat between meetings. 

**Bron Gondwana:** Yeah. You can continue to chat in the in the session itself or there's a general chat for each working group as well. 

**Grace:** Okay. Thank you.

**Bron Gondwana:** Cool. Thanks for the question. All right. And that is the end of my bit. So if you do have any questions, please do pop up or, you know, come and find me throughout the week. I have a hat, makes it very easy to see. Don't confuse me with Barry. Bron is the taller chap with the hat and the funny accent. All right. Thank you very much.

(Clapping)

**Michelle:** Again, we're going to be hanging out in this room all day for all of these sessions and in between the sessions it's a great opportunity if you want to put yourself in the queue, test out your Meetecho. I'd like to remind you if you do come to the microphone, just please state your name nice and clearly so perhaps somebody is doing something else on their laptop and they can hear who's actually at the microphone. And yeah, if you're having having any troubles, please come on up in between the sessions, we'll try to help you.

The next session we have, session three, which talks about the standards development process. It's quite a heavy session and it's a lot of the meat of the IETF and how the documentation gets developed from an idea all the way to a published RFC. So you have a little time for a break now. Again, test out your equipment and we will see you back here shortly. About 15 minutes from now. I'm going to double-check and I'll announce that in just a moment. So thank you.

(Clapping)

**Michelle:** So actually we have scheduled a little bit longer of a bio break right now from 11:00 to 11:15. The session three will be starting at 11:15, so you have some proper time right now to use the facilities, get something to drink, catch up on email, close your eyes for a couple minutes and get a little nap in. So we'll see you back here at 11:15. You could pop over to Disney World or something. High-speed train. And please if you have any questions, do not hesitate to come up and ask. We're here to help you.

### Session 3: [New Participant Program - Session 3 - Standards Development Process](https://datatracker.ietf.org/meeting/125/materials/slides-125-newparticipant-sessa-new-participant-program-session-3-ietf-standards-development-process-00)

**Michelle:** Okay, we are going to get started. Just as a reminder, if you haven't already, please scan the QR code that you see on the screen. There are some QR codes on the microphone in the middle and there's also some posters in the back of the room that you can scan the QR code. Let us know that you're attending this session. Again, this is session three of the new participant program. Going to be talking about standards development and I'm going to pass it off to Barry.

**Barry Leiba:** Yeah. Hi, I'm Barry Leiba. I want to be the only person in the room who is not scanned that code, so everybody be sure you scan the code. The one on the screen here will disappear soon but there are other places to do it. Bron scared you with saying that it takes four years to have a standard published. So I'm going to go through the process that makes that happen. And I'll say that we've had some that took four months and we've had some that took 12 years. So, you know, four years is probably a good middle ground but they can happen faster and they do. And it's all up to you. So let's proceed. 

You don't need to see that one, you definitely don't need to see this one, this is who I am. I will note though that when you look at the slides, I have all these roles that I have now and have had in the past and none of them apply here. I'm talking for myself and telling you my thoughts and the thoughts on the slides. Note the note well, well. You've agreed to this about 30 times already and the week is only just begun. 

Okay. The way the IETF works is in working groups and the working groups are split into technical areas. We have here a list of the six technical areas plus the general area that has process-related things going on. I highly recommend you don't spend much time on the process stuff until you really get deep into the weeds of the IETF. So you have seven technical areas ranging from the application layer, which is where I live, to the routing and internet layers, which is where a lot of my colleagues live, and then a couple things like operations and security that span the different layers and address special things. Security gets its little fingers into everything. And never mind how many working groups there are or what they're called, like on this slide there are places you can look this up. 

And on the looking it up, I have to learn how to say "Datatracker" because that's not how I would normally pronounce it but I love the way Bron says it so I'm I'm working on that. Datatracker. Thanks, mate. When I started in the IETF we didn't have a Datatracker. Bron doesn't know from an IETF that doesn't have it. It changed our lives because the Datatracker keeps track of everything that goes on in the IETF system. It has all the information about the working groups, all the information about the documents, all the information about everything that's happening. And when you look at this, what you see here is the Datatracker entry for a working group, for the ACE working group. And it tells you about the structure of the working group, but up at the top where it says adopted IDs and current status, there's this line there of documents, meetings, history, etc. You can click on the documents link and get this list of documents that that working group is working on. And it's divided into several sections. There's the ones that are actively being worked on right now, the active internet drafts. There's then a section of the RFCs that have already been published by that working group and then way at the bottom there's a list of other documents that have not yet been adopted by the working group but they are related to this working group. People who are working in that working group have proposed them and they may eventually become working group products. So that gives you a good list of of what to read. 

When you come to an IETF meeting, you will need to know what of those drafts they're going to be discussing and if you have brought yourself up to speed on them and understand what the issues are that are going to be discussed, you'll have a better time following what's going on in the meetings. My first IETF meeting was in 1998 and I went to Los Angeles not knowing what I was doing and found that the working group I went to work on was great, but all the other working groups I went to I had no idea what was happening. The next the my second meeting I prepared better. So word to the wise. 

So the documents' Datatracker page tells you everything about that document, what its status is, how far along in the process it has gone and I will talk a lot more about that process and then has the text of the document. So here's that process. Barry, don't back up. Just for those of you who don't know, I'm about 8 centimeters from the edge of the stage here. 

So everything we do in in working group documents has to represent rough consensus of where the working group is on that document, what we think, as Bron put it, what's the the working code that's going into this, what's what's going to make this protocol work correctly. And different people will have different views of that, there's no one right answer. So we sometimes everyone can agree on something and that's fabulous and that's always what we aim for. Lacking that, we go for what we call rough consensus, which means that we have considered the options, we've considered the objections to the path that's written in the document now and either changed the document to reflect a new rough consensus or explained why the path we're on is the right one and and moved on ahead. 

A good participant strongly supports their own views of what the right path is but graciously accepts that they're on the rough side of the consensus when that happens and allows the document to represent the rough consensus of most of the people and and most of the technological statements that are being made. 

So we don't vote. It's not I've mentioned objections and that's the point of this is that you can raise an objection that says "this will not work. It's broken. And here's why, here's the technical reason why," and that one objection can change the rough consensus because you've pointed out a fatal flaw. There's also the "I think this is a better way to do it," and that's a valid objection also but it has a different strength in the it's a lesser strength of argument. But none of it is voting, none of it is saying "okay 10 people want it this way and 8 people want it that way so the 10 win." It doesn't work that way. Everybody represents themselves with that. Don't try to get 15 of your favorite colleagues to come in and support your view. The working group will very quickly see through that and they don't like it. The idea is: give us your best input and let that stand on its own strength. 

So rough consensus as this says is achieved when all issues are addressed. That doesn't necessarily mean that we change the document to accommodate them, but they have been addressed, they've been discussed, the technical balance has been decided. There's a thing called humming. We used to do that a lot more than we do now, particularly with Meetecho and the increased use of remote participation, the humming doesn't work the way it used to. We actually used to say well here, those of you who are women in the room, hum now. Just go "hmmmmm."

(Audience hums)

Those of you who are men in the room, hum now. 

(Audience hums)

And so I hear the the men hum is louder than the women hum so there are more men than women in the room is how I interpret that. That's what we used to do. And that we still occasionally do it, but it's a way to get the discussion started. Choice one, choice two, choice three. Hum for those three choices. Choice two got the loudest hum, let's start the discussion there and see where we go. But it's definitely not a vote, it's not the end of the discussion, it's just the beginning. Consensus is where we're headed. 

So what this there we have an RFC, it's referenced on the bottom here, written by my good friend Pete Resnick, RFC 7282 that talks all about this process. The idea here is that five people against something or even one person against something can not be rough consensus because that one person has raised a significant issue that hasn't been addressed. 

Okay. So a typical and this isn't universal, this is a typical process flow. Typically an individual who has an idea writes it up as an internet draft and submits it to the working group for consideration. Ideally that one person has talked with other people beforehand. You can just write up a draft and dump it into the system, but more commonly and more effectively you discuss this with other people who are doing related work and they inform what you write in that and they will support your work once you do present it to the working group. So that starts off as the individual phase, an individual internet draft. 

The working group will discuss that for a bit and at some point they might decide to adopt your document as a working group product. And at that point, you resubmit it with the name of the working group as part of part of the name of the document and it becomes a working group document. And the working group may discuss that for a month or a year or four years or however long it takes to develop it to the point of rough consensus and where they think it's solving the problem it's intended to solve. You have a lot to do with this. We've done a little analyzing of where the delays in the process happen and there are delays in every phase, but the main thing is the author of the document does not always is not always prompt about updating the document and reflecting the changes that the working group has proposed. So it's on you as the author of the document, the editor of the document, to keep this going, to keep updating it and reflecting what the current working group discussion is saying. And that will lessen the time it takes to get through this process. 

At some point the working group chairs will decide that it looks like we're about done. Let's call a working group last call on this. And again, that doesn't have to happen, but it generally does, that the working group is put on notice that we're ready to publish this, give it a last read, give your last comments on it before we send it to the IESG to request publication. 

So after that, the area director responsible for your working group is given the document, the chairs do a publication request. And that area director reads it over and probably the area director has comments and there's some iteration with the working group going back and forth making changes making the area director happy with the content of it and the fact that it has rough consensus of the working group. 

So here's a summary here: The individual had an idea, individual internet draft, the working group and the individuals discuss it. Next step, the working group does a call for adoption on this. Is this document in a state where the working group is ready to continue with that as its own product? It becomes adopted. Now again, when the working group adopts it, it's not done. The working group isn't deciding that that it's ready. They're deciding that it's in a suitable state for them to proceed with it. And so it goes through the working group discussion, it gets working group rough consensus, goes to working group last call, submitted to the area director to the IESG. 

That's the process. I'm going to pause here and ask if anybody has a question about the life of a document within the working group. And I all I see is the the code wobbling back and forth, there must be some air currents going on there. All right. 

I'll make another point here. There's a thing called a document shepherd. As I said, a lot of the delays that go into this system have to do with the authors not being as responsive as they ought to be. Once it gets up to the next stage, there are a lot more cogs going on. There's various area directors making comments, there's IANA making comments, there's a lot of pieces and somebody needs to make sure that this all gets these cats all get herded and that the delays don't continue. So that's where the shepherd comes in. Document shepherd's job is to write up a summary of the life of this document and give it to the area director for support and then follow it along the way and make sure that if somebody has raised an issue, somebody responds to that. It doesn't just sit there and things move forward. 

Also, there are things called directorates, which are groups of experts in certain sub-areas of things that are asked to review this. Make sure that if there's a Yang I never remember whether it's model or module, um, that there's a Yang thing, make sure it's right. If there's XML in there, make sure the XML is right. If there are issues with IoT concerns or security concerns, make sure that they got that them right. So that's the directorate reviews part of this, the last bullet. 

And I have a person in the queue. Please ask your question. 

**Hatman:** Yeah. Hi Barry. Not Pantsman. 

**Barry Leiba:** Steady. 

**Hatman:** I had a question about how you choose which working group to take your work to because we've jumped straight to the working group adoption but how do you decide which working group should adopt your work? 

**Barry Leiba:** That's something we should tweak on these slides. Michelle, please take note. Um, yes. The way at the beginning of the process I said that you take your idea to a working group. What working group do you take it to? Well, presumably you have started looking at Bron said subscribe to some mailing lists, read what's going on. The best participants, the best new participants, do a lot of reading and looking and listening before they speak. So you've got some idea of what working group you're interested in. If you have any questions about what working group is suitable for this work, there are two ways to deal with that. One is to talk to relevant area directors and other working group chairs and that sort of thing. And another is to take it to the burgeoning number of dispatch working groups that exist in the IETF now whose job it is to figure out where this belongs. 

The other thing that should have been in my presentation that I realized here is that each working group has a charter which describes what it is supposed to work on and also what it doesn't work on. You can go and read all the charters for all the working groups or find things in your area and see, "is the thing I want to do in charter for this working group?" and I think that's a good way to choose. 

**Hatman:** Yeah. I kind of think of that as pounding your toe with a hammer. But, um, the charters can be pretty dense and hard to figure out. As I said, likely if you've been watching, reading, listening for a while you have some sense of where you want to go and there's always advice from others and, um, dispatch working groups: DISPATCH, SECDISPATCH, GENDISPATCH, that kind of thing. Or the area working groups like, um, the transport area working group and things like that. Yes. 

**Audience Member:** Yes. I have a question regarding to the rough consensus. I think I want to learn more about how the chair decide the rough consensus. For example, I can assume a scenario for certain discussion or certain question different people may have different idea. They are either A or B. In this kind of situation is the chair's responsibility to make decision we we will go to A or B, or chair just to listen to people's discussion and then I just want to learn more about the process here. 

**Barry Leiba:** So it's hard to hear the speakers up here because they're aimed out at you. So I think you're asking how the working group chair decides where the consensus has gone and whether we have consensus. Yes. That's why we get paid so much as chairs. A thing. It's it's experience and, um, following the discussion and seeing how it's gone. The chair will say "we've we've had a discussion going on in a room for 30 minutes or on the working group for a couple of weeks or whatever." And the chair can say, "All right, it looks to me like most people think that choice two is the right answer. Is that what we all agree on?" and then let's see if the discussion supports that continuing. 

So they do it by observing the discussion and making their analysis of where the discussion has gone. They do it by asking further questions and seeing how the answers to those go. And ultimately they will say, "I see that this is the rough consensus we have. If anybody objects to that, speak up now." And either then you get no objections or you get objections that have already been come up and been addressed, or you get somebody raising a new objection and then you continue the discussion. 

**Audience Member:** Okay, okay. Thank you. 

**Barry Leiba:** Okay. Thanks for the questions, those are that that was a particularly important question for me to answer. So thank you for asking it. 

All right. So we've got the document shepherd, the directorate reviews. Now we have the AD review. The area director responsible for your working group reviews the document as I said iterates on that, we get a final result, and then the AD says, "Okay, I'm happy with it. I see that the working group still has rough consensus on it. It's time to put it out to the general IETF community for last call." And that's done by posting a message to the Last Call mailing list, which is a huge mailing list that gets every last call in the IETF. The full community now has an opportunity to look at this, all the people who have not been following that working group yet or ever or whatever will be informed about this document and given a chance to comment. 

Sometimes there's nothing. Sometimes there are no last call comments. Sometimes there's a lot. Sometimes the working the document has to go back to the working group because the last call raised issues that need to be addressed by the working group. So here's where the document shepherd needs to follow what's going on and help the chairs keep track of what's happening during the last call and make sure that that goes smoothly and that the issues get addressed. 

That's also when any directorates that have not already been asked to do earlier reviews are asked to do reviews now. We generally try to get all of the directorates and review teams to participate in the last call. Not always successful, but we give it a try. Anybody can make comments at this point and many do. 

So when that goes back and forth and eventually the typical a working group a last call from a working group document takes two weeks. When that's done and the issues raised by it have been addressed in the document, it goes to the IESG as a whole. It's put on what's called the telechat. It's there every two weeks the IESG meets to discuss documents. And this document will now be read by all however many 15 area directors we have right now, and they will all ballot on it. Now this sounds like a vote, right? We specifically call it a ballot, not a vote, and "no" is not an answer that's acceptable on there. The ballot can say "yes" or "no objection." "Yes" means "I support this and would be the would be one to fight for it," and there has to be at least one "yes" ballot. Usually the sponsoring area director is the one who gives it a "yes" ballot. We've had some documents that had six "yes" ballots. That means it was a very popular document that was considered important and lots of area directors were willing to fight for it. But most of the time everyone else gives it a "no objection" ballot. 

The other common ballot is "discuss." And that doesn't necessarily mean "this is a disaster," some people think that's what it means. It means "I have something I want to discuss with the authors and the working group before I ballot no objection." That discussion has to happen. If there are any open discuss ballots that have not been addressed, the document won't move forward. So be sure that any non-discuss comments that area directors make should also be strongly considered, but they don't have to be addressed. The ones that have to be addressed are the discusses. So you keep track of that, the document shepherd makes sure that the discussion moves ahead. When all the discusses are cleared off and all that's left are "yes"es and "no objection"s, it's ready the document is ready to move on. And it you a note comes out, it's put in a state called, um, "announcement to be sent" and then "announcement sent" and an announcement goes to the community "this document is done." It goes into the RFC editor queue. 

Now that process can take anywhere from a couple of weeks to a couple of months to a long time if there are document dependencies. Often documents make reference to each other and all of the documents in a set that make references to each other have to be ready for publication in order for the RFC editor to proceed with them. 

So here we've added to the process flow. We've added the IESG portion to the process flow. Don't need to go further on that because we've already gone through it all. Are there any questions about the IESG process? 

Now the interesting thing about the IESG process is you're going to be getting people from, if you're submitting a document in the routing area, you're going to be getting people from the security area, you're going to be getting people from the applications area, you're going to be getting people from the operations and management area all reviewing this and giving their own take on what this routing document is doing. Sometimes there the discusses come simply because they are not experts in the area of this document and they're asking questions. Sometimes they come from experience they've had that says the last time I saw this it was a problem. So don't get frustrated. It's very easy to get frustrated. A lot of people do. Don't be that man, don't be that woman. 

Okay. Not all working groups work the same way. There are different tools that can be used for all of this. And it used to be that everything, everything, everything was done on the mailing list, with discussions in face-to-face meetings boiling down to "let's go back and put it on the mailing list again." But now we have other tools. We have GitHub and a lot of working groups are using GitHub, which is a nice way of collaborating on the content of the document, having a place to do issue tracking and all that sort of thing. So your working group might or might not use that. 

We have a lot more interim meetings, mostly online, than we used to have. So in between face-to-face meetings we'll have Meetecho calls or sometimes using other tools. Some groups still use Zoom for that. Meetecho has since been enhanced to do really well with the interim meetings. And all the working groups that I participate in that use interim meetings use that. 

So different tools. Different roles. The I talked about working group chair, I talked about document shepherd. But there's also some working groups have a working group secretary that can help out the chairs by keeping track of things and being an alternate, an alternate person who can manage a an interim call if the chairs are not available, that kind of stuff. And sometimes a secretary position is used to prepare someone to be a new chair. 

Okay. Has have they already talked about how chairs get appointed? Okay. So I don't know if this will it be later? Okay. Well maybe I'll introduce it now that the working group chairs are appointed by the area director responsible for the working group. And they can be changed by the area director responsible for the working group. There's no term limit for chairs. Some people have chaired the same working group for 20 years. Some area directors prefer to swap the chairs out periodically and just get new ideas and new thoughts in. There's nothing wrong with being replaced as a chair, there's nothing wrong with staying in as a chair for a long time. It's all up to you as a chair and the area director responsible for it. 

But one thing that when I was an area director that I liked to do was to try to find an experienced chair and a new chair to be co-chairs for working group. We normally have at least two chairs for each working group because somebody gets busy, somebody has a conflict of interest, somebody needs backup, and it's always a good idea to have multiple chairs so one can back the other. And with the new chair old chair idea, it it lets the experienced chair help to teach the the newer chair how the Datatracker works and what the different processes and roles are. 

So also the chairs assign document editors. Most of the time if you're the one presenting an idea to the working group and you wrote the individual draft that comes in, most of the time you remain the author editor of the document when it becomes a working group product. But not necessarily. And I've had working groups that I've chaired where I thought that for various reasons a neutral chair, sorry, a neutral editor should be appointed to be the editor for that document rather than having it be the original authors. So it's up to the working group chairs what will work best for this working group and this particular document. 

And design teams. The working group will often have an issue that needs to be resolved that's been discussed for a while and it hasn't been resolved yet. And the working group chairs will say "you three go off and form a what we call a design team. Have a couple of conference calls, drink some beer, do whatever it is you want to do and discuss this and come back to the working group with your answer to what the best path is." It's still the working group's decision. The design team doesn't decide anything. The design team just comes up with something that they can present back to the working group as their view of the right answer. The working group still decides. 

All right. Here's interim meetings. Again, the Datatracker is your is your friend. All that stuff on the right that says meeting resources are things you can click on that I never remember what any of those icons mean and you won't either. Hover over them and they'll tell you. But they get you to things like the notepad for the meeting and the agenda for the meeting and all that kind of stuff, the reading material for that meeting and and that sort of thing. And the Meetecho link for that meeting. 

Okay. More on the IESG. I told you they have this call every two weeks called the telechat. And what that the entirety of that meeting is processing all the documents that are queued up for that that week, that biweekly. And discussing whether is there anything the IESG needs to discuss? Now it used to be that every document was talked about for a while by the IESG and that has now gotten streamlined. Everybody's expected to have read it, everybody's expected to have sent out their comments by email and it's we only discuss a particular document if there's a reason the IESG needs to have an extended conversation about it. Otherwise it's pretty boring. Which is a good thing, boring in a good way. And then at the end there's some there may be some management items that the IESG needs to deal with. And that's what a telechat involves. Telechats used to be closed, they're now open, they've been open for quite a few years now. Anybody can dial into the telechats and see, as we say, how the sausage is made. Again, it's it's interesting to do it once. It may be interesting to do it if your document is on the agenda for that telechat. But it does get it is kind of boring. It's routine. I shouldn't say boring. It's routine. 

So you might want to talk to ADs during the meeting. Don't be put off if they're really busy because they are really busy. I used to say when I was an area director that I had to put bathroom breaks on my calendar or I didn't get them. So it's quite hectic for the area directors. But most of them are happy to talk to you if they can find the time and if you can catch them. And more and more the area directors are holding office hours where they say "the routing area directors will be sitting in this room for an hour and a half at this time of day. Come come talk to us." Take advantage of that. It doesn't hurt to meet them and get to know them. When I first started in the IETF, the area directors were gods up on Mount Olympus. And then after I was doing this for a while they became people I knew and no longer up on Mount Olympus. And as I did it for longer, they became my friends who were now area directors. And that's cool and we're hoping that Bron becomes an area director soon. So I will add that the area director office hours are listed on the agenda. So if you are interested in talking to a particular area, look on the agenda to see if they are holding office hours this week. And you'll also find area directors milling around in the Hackathon, milling around this afternoon in the newcomers quick connections and after that the welcome reception. The new participant social hour on Thursday will have some area directors there and you can recognize area directors by their yellow dot on their on their name tag. So and IAB members if you care about that will have a red dot. And I have a blue one because I'm chairing a couple of working groups. So... 

All right. When we are finished with this whole process, we now have RFCs. And an RFC, it originally stands for Request for Comments, they are no longer requests for comments, the requests for comments came way before that. They're now finished documents but RFC is a brand so we keep it. An RFC can be on standards track, which means that it is it starts at a proposed standard and might at some point become what we call an internet standard. There less and less of a thrust to do that. The original idea was that a proposed standard was a little more raw and wasn't quite ready to be said that that it's fully baked. And when we thought it was fully baked, we upgraded it to what then was called draft standard and then internet standard. These days we say the internet runs on proposed standard. The standards standards's not a good word for that. The criteria for approving a proposed standard have gotten tighter and tighter such that proposed standards are pretty well baked as they are most of the time. So that's the standards track. 

There's I'm going to skip one. There's best current practice. And that's generally either a process-related document, "this is how we do things in the IETF," or it's something that is not not technical enough to be a standard but describes how to use the standard or that sort of thing how we do something on the technical side. And that has the same ranking as it were of standards track. They're both considered standards. 

Informational is not at that level. Informational is just "this is not a standard, this is just giving you information that's useful to you." It may describe, uh, there are some standards have so many documents that are parts of them that areas have decided to give you a roadmap. If you're trying to figure out how IP works or how BCP, sorry, BGP works or how DNS works, there may be there's a document that says "here's a roadmap of of how you piece these documents together." That sort of thing will be informational. Some working groups like to do a problem statement document. "This is the problem we're trying to solve and here is the process we want to go through to solve it," that would be an informational document. 

And experimental is where we say "we have an idea, it's not baked enough to be proposed standard, but we'd like to try it out for a while and see if it does what we think it does and whether it needs changes" and that that might be published as experimental. There is the thing that some people will say to you that that anything with an RFC the world considers to be a standard. And that's a little bit of a problem. We've had people proposing solutions to that of giving giving things that are not standards a different name other than RFC. They've never that's never taken root. People are not enamored of that idea. 

So, how do you bring new work into the IETF? We start at the internet layer and work up. Internet, routing, transport, applications, with security and operations interleaved. So we don't do the stuff that IEEE does for instance, of hardware and that sort of thing. Make sure that what you are looking for is covered by what the IETF does. We do software protocols that get into routers, that get into applications and that sort of thing. So start start making sure that the that you think the IETF is the right place for this. 

Then there are ways of asking the IETF if they think it's if the rest of the IETF thinks so. Is this something that a small group of people need or is this more broader applicability? Is this something that the industry as a whole will use? The more broadly this is likely to be implemented, the more the IETF will be interested in working on it. Are there already things that do this or something similar? Can this be recast as a tweak to an existing protocol? Those are all questions you need to ask yourselves. Why is this what is the advantage of this idea over what's already out there? 

And then the other bit is that we have the IRTF, the internet research task force, that looks at more advanced, more future stuff, what what might be coming along. Is this ready for engineering? Is this ready for being a standard now? Or is this more something that we need to look at and see whether a future standard would be appropriate? So but again, it's all judgment. There's a lot of exceptions. 

When you I mentioned dispatch working groups and area working groups, that's where you can go to see if the the rest of the IETF thinks your idea is suitable for the IETF. A typical thing in a dispatch working group will be you present you you have your draft has been published, you present a summary of what your draft does and talk about the technology. And then people will get up on the microphone and sometimes have quite a long line asking you questions, making comments and saying, "Well, I think this work belongs in working group X" or, you know, "I think this work belongs in a different organization. Maybe W3C should work on this or maybe IEEE should." So that's where they recommend to the area directors what path should be taken for processing this idea, where it can go anywhere from form a working group to ask the person to take it somewhere else. 

So this says no shortcut for doing the work. You you've got to write the idea up as an internet draft. As I said at the beginning of this, talk to other people, don't just write it up and throw it over the wall. Talk to other people, get people to collaborate with you on it. But ultimately, it's going to be published as a working group draft. That's where people are going to go to see to read what you have to say and read what your idea is. 

Understand they the what the note well says, right? There's certain intellectual property, uh, concerns that need to be followed. Make sure that this that you've met those concerns, that you've met those requirements. You are required to disclose if something you propose has a patent pending on it or a patent issued on it or that sort of thing. So be sure you've followed that and I I am not qualified to give you details on that. There are RFCs that will do that. 

And then you have to decide what you want. You you might want an experimental result. You might want it to just be informational or you might be looking for a standard that can be built upon by other standards. Aim aim properly and when you present that to wherever you're bringing it, make sure you're clear about that. 

So here we go, this is the summary of everything I've just said. Area dispatch group, get a community of interested participants before you start with this. One that I didn't mention is it's useful to ask the area director that might be responsible if your document's in the routing area, find a routing area director and discuss starting up a working a non-working group mailing list. So there's a central place to discuss this. Very common. No nobody thinks anything of creating these things. They're easy and they they give a good place to meet to have the discussions. You can have birds of a feather sessions which are more formal meetings at an IETF meeting that are not working group sessions but they are on the agenda, they're there to discuss a particular topic and you can either propose a new working group or just present a technology that you want to discuss in the IETF. Ask an AD about that. 

For things that are not very complicated and not very controversial you might even just get an area director to sponsor your document outside of the working group process. That happens also. Ask the area directors about that. Sometimes the output of a dispatch request says an AD should just sponsor this. 

And then there's this thing called the independent stream. It way back in the day there was someone called John Postel who just decided to publish stuff. That that has in recent years become what's called the independent stream and we have a special volunteer from the community, Eliot Lear is the current one, called the independent stream editor. And they can also publish anything at their discretion that doesn't conflict with IETF work. 

So how can you be successful as opposed to falling on your face? As I said, start by writing up an internet draft. Really start by getting people getting other people to think that your idea is worth proceeding with and then work with them to publish it as an internet draft. Make a short presentation you could give in a working group session. "Short" is is really an operative thing here. I've seen presentations that go on for 45 minutes and you lose people on that. Try to keep it brief, get them interested. Don't get them bored or don't get them upset. Socialize your idea, talk to talk to more people than just your collaborators. There's a session now, at the end of the welcome reception, the last half of the welcome reception, called the hot RFC talks. You have like five minutes to just present your idea. There's no questions and answers, it's just "throw it out there, I'm I'm entertaining comments, find me during the week, we're having a side meeting about this," whatever it is. And get other people to be interested in it. 

If you ask for time on a working group session's agenda, realize that the agendas may be very busy. So make sure that your presentation is tight and make sure that your work is ready to present to them. And realize that people, even if they sound rough, they're trying to work with you on this. We are not always socially, um, sensible, let's put it that way. People are volunteering to do this, they want to work with you, try to work with them. 

Okay. How did I do? 

**Michelle:** Did very well. Um, I do want to add something to what Barry just said about, if you have an idea and you're not quite ready to write it down, um, there are two points during the week where the IAB has a new work help desk. Uh, there's a time on Monday around 11:30 and then Thursday around 4:00 and I will be sending a message to the new participant mailing list with these days and times. But there's a desk that's just outside in the hallway here where some IAB members will be there if you want to talk about a new idea and you're not sure where to start. It's an opportunity to talk to some of the leadership and um, they can give you a little bit of advice. So you can keep that in mind. 

**Barry Leiba:** Okay. Shulei Wen?

**Shulei Wen:** Hi, thank you very much Barry for the presentation, it's very clear and informative. So this is Shulei Wen from ETH Zurich and I want to ask a question that in case that multiple individual drafts were submitted around at the same time then what would the working group typically do? Like would it encourage authors to collaborate or like they will treat them as competing drafts? Thank you.

**Barry Leiba:** Excellent question. Yeah that that might also need to be stuck on the slides somewhere. That happens a lot. We often have either multiple competing ideas at coming in at the same time or somebody presents an idea and others say, "Oh, well, I have alternatives" and they come in after. Either way, depends on what the technology is, what the working group is doing at the time, but the two most common things to happen with that is either they are asked to merge their ideas into one draft or the working group is asked to pick which direction to take depending on exactly what the angle is and whether they can be merged or whether they are independent paths. Occasionally it may be it may make sense for the working group to adopt two different paths to the same end. Um, that happens occasionally but less often. 

**Shulei Wen:** Okay, so it's like a case-by-case?

**Barry Leiba:** It's up to the working group chairs to determine the right path based on input from the working group. And some where something that I can stress on that is that the chairs do not decide things. The chairs exercise judgment to figure out what the working group has decided. 

**Shulei Wen:** Yeah, okay. Thank you, it makes sense. Thank you. 

**Barry Leiba:** Okay. Thanks for the question. Others? Yes?

**Audience Member:** Hi Barry, this is Chao, nice to meet you. Uh, my question is, uh, prior experience, uh, how does it usually take, uh, from an internet draft to the final standard? 

**Barry Leiba:** Okay, yeah. How long does it take to go from from an internet draft to an RFC? As I said, we've had some that we've been able to do in in two or three months. We've had some that take less than a year. And we've had some that take multiple years. It depends on the urgency, things that are more important to get done quickly may just get done quickly because that's what has to happen. Um, sometimes it's just a complicated technology that takes a long time and sometimes as I said, it takes a long time because the people involved just don't do things quickly. And so a lot of that is that the the people who are interested in moving the document forward, if they're very responsive and and update the document and keep the discussion going, that will shorten the time. So it's very variable. There's certainly a built-in minimum of two to four months that it's not going to be quicker than that. Um, but it does not have to be much longer than that if it's a simple idea. So...

**Audience Member:** I have a second, so based on that, uh, which part consumed the most time? Is the is the consensus reachment part is the longest, takes the longest time? 

**Barry Leiba:** Yes. The longest time is definitely the part between getting the working group to adopt it and getting it out of the working group with working group consensus. And as I said, you you can make that happen more quickly by being responsive and in updating the document and keeping the discussion going. But sometimes working groups just take a long time to hash out all the differences and and have the discussion. So. 

**Michelle:** Next we have Benjamin in the queue. 

**Benjamin:** Hi I'm Ben Curtis. Uh, if we are working with another standards organization such as IEEE in this case, is there any special processes that are required as far as coming in to with the operational standard that we'd like to create with IETF around that?

**Barry Leiba:** Working with other standards organizations can be simple or complicated depending on the issue and the organization. We have formal liaison relationships with some other standards organizations. It's not always necessary to invoke those relationships. Uh, the best thing to do is when you have participants who participate on both sides, you just work together, you agree on what makes sense and and there it is. But sometimes there needs to be a formal liaison statement sent over to the other organization to say "we're doing this, we're taking this path, we want to let you know" or "we have a question for you" or "we need your cooperation on a particular thing." There are some things that happen where work has to happen on both sides at the same time and, um, you know, so the liaison relationships can help coordinate that, the common participants can help coordinate that. So we get that a lot both between IETF and IEEE and between IETF and W3C, those are two very common ones where that happens. 

**Michelle:** Next we have Bron. 

**Bron Gondwana:** I put myself in the queue for something else, but the this liaison question was was something that I think needs to be answered more specifically as well. Once you bring an idea to the IETF and it is adopted by a working group, you no longer own it. The IETF has change control, the working group has the right to take it in a completely different direction and you have a say same as everybody else but you don't own the idea anymore. You don't own the document anymore. The IETF owns the document. So in the case where it needs to interoperate with something else, the IETF certainly takes that into account. The IETF might also decide we don't want to do anything in this space or we want to do something completely different and the other organization's going to have to negotiate with us about it. At the end an IETF document has to be adopted and useful to the rest of the world or it's just a meaningless number in a Datatracker unused and unloved and so obviously the IETF cares about making things work with other areas. And that came to the answer to the other question that Barry gave about how long does something take and what are the roadblocks. A lot of it is persuading other people that your idea has merit, will work, will be adopted by the rest of the world. No body no working group wants to generate documents that don't go anywhere and that sit in the Datatracker unused and unloved. And so the thing that slows things down is people not believing that your idea has traction and so coming with evidence that there's interest in this in the outside world and that it will get adopted is valuable. Coming with persuasive evidence that you understand what you're doing and that your technical ideas are sound has a lot of value. And just socializing your idea around, getting the rest of the IETF to understand what it is, why it is, why it's necessary will mean people are less likely to bring up objections and questions later, particularly once it comes out of the working group and goes to the rest of the IETF last call, everybody in the IETF can see the document at any time but particularly there's a mailing list where your document will go and people can look at it and go "hang on, why are they doing that?" and if your idea hasn't already been socialized, you might get stuck in a whole section of discussion around "why should it be done this way?" and particularly if it's a controversial topic. There's a document I've been following in the email space that has been delayed for a long time over whether it "must" or "may" or "should" require TLS only or require implementations not to support TLS because it's a controversial topic and because there's a lot of history and a lot of people know things in that area and so there's been a lot of debate. You can look ahead to these things, socialize your idea and things will move more smoothly if you get people on board. So that's important. There's work to do there and it's real work and that's why we're here to meet people so that when it comes time to do that work, they believe in you and they know you. 

**Michelle:** Okay we're almost done with the session, we have three more people in the queue though. Jing Shu Ma. I'm sorry if I said that incorrectly. 

**Barry Leiba:** Okay and just quickly, bringing bringing things to the Hackathon is a good way to show that there is some interest in implementing your idea. 

**Jing Shu Ma:** Hi Barry, I'm C Shu from University of Edinburgh. Um my question is I wonder if um one proposal got rejected at first um and could we like pitch it again later? Um I mean is that definitely no like not interested from IETF people at all or like if we make some make more progress on that work and make that design better, um can we like try again in the future? 

**Barry Leiba:** Um you certainly can. It depends on what the idea is, what the working group's response to it was, whether they've sort of allowed room for "well make it improve your idea or clarify it or whatever and bring it back" or whether they just say "no this is completely out of scope for our working group." Um you've got to listen to the response, there's no one answer to that. 

**Michelle:** Next we have Christian. Christian are you remote?

**Christian:** Hi Barry. Christian. Uh I'm still a bit uncomfortable if you have a draft in an area which the the working group doesn't exist anymore or is inactive and uh yeah how to to push this. and especially things are already implemented but need an update and yeah. 

**Barry Leiba:** So that's where the DISPATCH or area working groups are your friend. You bring this to an area-wide discussion. Sometimes the working group that used to exist on this topic, their mailing list is still active and you can post there and have some discussion there. And then the dispatch group will decide well maybe we need a new working group, maybe we can reopen the old working group, maybe we need to have some maybe this is a simple idea that the area director can just sponsor, um but it's we have frequently reopened working groups to take new work after they've been closed for years. So it happens. 

**Christian:** Okay. Thank you.

**Michelle:** Thank you. Fabulous questions. Um thank you Barry for a fabulous session, very informative. Um we are going to um go right into our next session which is a very short session. As Bron and Barry mentioned, sometimes a good place to take an idea is the Hackathon and we have Benno here that's going to do a quick introduction to the Hackathon. And so I'm going to pull up those slides and we'll get started right away on that and then just following this very short session, we're going to have lunch and lunch will be just outside this room. So just give us one minute to change over the slides and we'll get started.

### Session 4: [New Participant Program - Session 4 - IETF Hackathon](https://datatracker.ietf.org/meeting/125/materials/slides-125-newparticipant-sessa-new-participant-program-session-4-introduction-to-the-ietf-hackathon-00)

**Benno Overeinder:** Thank you. Thanks Michelle. Um yeah. I'll try to keep it within 15 minutes, maybe shorter even. So my name is Benno Overeinder and well give you a short introduction into the IETF Hackathon. Um yeah. I can skip this for now. Um the Hackathon is not yeah it's organized by three of us, you just saw Barry, Barry Leiba, um together with Charles and myself we're organizing the IETF Hackathon every every IETF meeting the weekend before the IETF starts. Um and of course with great help of the IETF Secretariat because important part of the IETF Hackathon is of course food and drinks and these are all provided and arranged for by the by the Secretariat. Good. Um yeah you can read the CVs the biographies later on the slides, I won't go into details here. 

The note well I can skip I think, yes. It's important the note well you heard about it probably. And also for the IETF Hackathon the note well applies actually. But what is the what is the running code part of the IETF Hackathon? I think Barry Leiba already introduced the IETF standards process. And important part is well, kind of the one-liner we use is we believe in consensus, rough consensus and running code. And this is all about the running code. So um it's important, so the running code is important if you have to have high-quality standards and standards that are being used, make them relevant, hey, not only used standards are relevant. Um running code is very important. The quality, yeah, you've written it, I can read it and write code, someone else writes code and it can interoperate, then the specification is clear and not ambiguous. If I have questions it doesn't work, I have to go back to the author and they have to refine the specification because it's not a good specification, people interpret it differently. So that's about the quality, but about the relevance, you want to have protocols being implemented and used in equipment. By having code, maybe proof of concept code, of reference code, people use that different names, prototype code, that can all be used by manufacturers or production code developers to test their implementations or they can be inspired and can help the development of production code, code that can be really used by you and me in well, in our laptops, in servers, in routers, etc., etc. So that's the importance of running code in the whole IETF standardization process. And oh yeah I can skip the second bullet. 

Some of the working groups are very strict, they want to have two implementations for interoperability test, other working groups are more relaxed and for some drafts is not relevant. So it's not always the case that every draft needs running code. Um and that's interesting. Uh the internet drafts will also have sometimes an implementation status. So reviewers can read okay, have there been implementations, how does it behave? Um the implementation section are quite often co-authored by the implementers, so they give feedback to the to the draft authors to see what's the status. So during the IETF review people can see "this a good specification it has been implemented," etc., etc. Um so this is about running code in the IETF. 

There's also here um another contribution of you is sometimes developing tools not only for the drafts and for the standards, but also tools like Datatracker. So there's also an initiative every Saturday there will be is the a code sprint. You and I can contribute to the tools the IETF is being used is using. Um but this is not about the Hackathon, this is the code sprint is a different initiative. You can contribute too. Good. 

The Hackathon, the Hackathon is two days, Saturday and Sunday. And um well, yeah, one of the number of things I already mentioned, what is the goal? So the goal is of course to have make progress on on drafts to become a standard, an RFC. Um and an excellent opportunity is the IETF Hackathon, is to work together with the writers of the drafts maybe and then the implementers side-by-side and they start working on an implementation to test the interoperability, ambiguity, "is do I understand this text correctly?", maybe you can change some of the text. So that's a very good part of the IETF Hackathon. Um and the other thing is also the IETF wants to attract new people, young people. And that's an excellent way, so young developers they can also become standards developers. Uh so if you have this IETF Hackathon, we combine these two talent groups and um well as mentioned, hey, get them exposed and interested in the IETF so the next generation IETF engineers well will be will grow in that in that respect. So that is a a nice combination of different aims and and we're pretty pretty successful. It's very, I'll go to the next slide, we're pretty successful. Over the past 15 years Charles started with the IETF Hackathon. It grew from a small group of maybe 15 people to 300 on average, sometimes even 400 people. It's um pretty pretty popular and it's a great great way to start the week, the whole IETF week. It's not only about maybe talking about or writing documents, it's also discussing ideas. So maybe before you start a draft you can also start go to the IETF, exchange ideas, talk about it, flesh out some some ideas and maybe submit that to a working group. Um so you see all kind of different activities during the IETF Hackathon weekend. 

Um and the other good thing is it's free to participate. So you don't have to pay a registration fee. You pay the registration fee for the IETF the full week, but if you only attend the IETF Hackathon it's free. So it's good for students, uh they can join without any costs, uh have dinner, have food, lunch, uh and have fun and and work with with the other people in the IETF community to make drafts or to help with a draft or to make a reference implementations. 

Um typically we have 45 40 to 50 projects, this time we have around almost 60 projects. And that's a challenge, because at the end of the Hackathon weekend, we do a presentation of all the projects. So we have only 2 hours for all these projects, giving 60 projects that's only 2 minutes and that's not counting switching between the slide sets. So that's a challenge for me, for us as organizers but also for the people participating because they have to pitch their idea, pitch their project in only 2 minutes. So uh it's fun to see. 

But the good thing is on Monday we have the hack demo of happy hour. And all the participants can present their their project to the full IETF community for an hour, so they can discuss it much more in depth. So if you have still around here on I guess you are around for the full week, on Monday evening around 6:00 or 7:00, between 6:00 and 7:00, please go to the level 2 foyer and there is the presentation of the of a number of the of the Hackathon projects and the participants are happy to discuss their ideas with you. 

Typically projects are published on an Hackathon wiki, um so describing who is in lead, we call it the champion of the project. Uh that's the the contact person can help you to introduce in the topic, connect you with one of the other participants, introduce you to the literature, etc., etc. So uh and sometimes we mark projects with a star as easy to to enter, easy for for first-timers. Um and that works very well. So this is typically a project. So the champions, the project info, you can have all kind of links to the drafts, to code repositories, etc. So this kind of project wiki is really really helpful for people to figure out where they want to well, first to attract people in for your project, or for people that are interested to contribute to look "okay, this is really topic I'm really enthusiastic about that, I want to contribute there." Um nowadays we see also that similar project is being worked on over different IETFs. So uh we are also thinking to introduce project wiki pages for these larger projects, they're consistent, they have a goal and they work over a number of IETF to achieve that goal. So that's uh that's very effective and uh we we hear a lot of positive feedback on that. 

All right. So oh maybe I can see. So this is a typical these are some pictures from the Hackathon. We have a whiteboard because there's 300 people. How do I figure out where is who is sitting where? So we we use old technology, a whiteboard with all the tables and an indication which project is on which table, so you can walk over to the to the table and talk with the people you want to talk. Um in the middle the picture typically we have kind of how do you call these well kind of A3 posters where people is working on so it's can already explain a little bit what they're working on, easy to find. And at the right bottom, also for you, uh these are the presentations at 2:00 this afternoon, uh so everybody has this 2 minutes to pitch their project. Um it's also possible to do remote participation, so we have tools like Gather Town, well it's it's a platform for people to join remotely to have discussions, share ideas. Uh we have sometimes hybrid setups so some of the people are in the room, some people are remotely working. And that works all very fine. 

Um yeah. Any questions actually? So this concludes my presentation. Um hope to hope to see you next time in the IETF Hackathon room. Um and if you see myself, let's see or Charles or Barry you just met him, if you have any questions, please tap me on the shoulder, ask questions, how you can join. Yeah? All right. Um...

**Michelle:** Just to add on to what Benno said, um on the wiki often the organizers of the project will indicate if it's a good project that's welcome to everybody, um and new participants, something that if you want to go to the Hackathon and you're not quite sure where to contribute or what to work on, um the wiki will have information of whether it's a good project for maybe a new participant or anybody can work on. Yeah, indeed. And um all of the um follow-up events that Benno mentioned, the presentations and the hack demo happy hour, um I'll be mentioning those in the emails that go to the new participant list, so if you're unable to go to the new participant dinner, which I think was sold out at this point, hack demo happy hour is happening around the same time so that's a good place to go and check out and see what people accomplished at the Hackathon, get some ideas of what it could be like at the next IETF. Yeah. 

**Benno Overeinder:** Thank you. Yeah. It's it's again it's a great way to start the week, but also to introduce yourselves to to others and vice versa. So you get starting learn people working and maybe collaborating in the next years on on drafts. Yeah, yeah. 

**Michelle:** Any questions about the Hackathon for Benno? Are we ready to eat and get re-energized? and maybe warm up a little bit? We acknowledge it got a little cold in here so I can actually feel it getting a little warmer. 

Okay well thank you Benno. 

**Benno Overeinder:** Thank you very much.

(Clapping)

**Michelle:** Okay so this concludes the morning portion of the new participant program. Um there is going to be lunch just outside the doors here and you're welcome to bring the food and eat inside this room if you'd like. But we have a fairly long break, uh over an hour, to do whatever you need to do and have some lunch and then we'll meet back here for the afternoon sessions at 2:00. All right. And I'll be up here for a couple minutes if you have any questions. Thank you everybody.