Markdown Version | Transcript | Recording 1 | Recording 2 | Session Materials

NEWPARTICIPANT

Summary

The afternoon sessions of the New Participant Program at IETF 126 featured educational tutorials on the document lifecycle, the structure of the IETF community, and practical guidance for participating throughout the week.

• Session 5: Internet Drafts and RFCs provided a comprehensive overview of how Internet-Drafts (I-Ds) are written, managed, and eventually published as RFCs, including the role of IANA and the RFC Production Center.
• Session 6: Power of the Community in the IETF focused on the cultural, organizational, and interpersonal aspects of the IETF, detailing the roles of leadership, the Nominating Committee (NomCom), the Code of Conduct, and dispute resolution.
• Summary and Wrap-up outlined key networking events, help desks, and social opportunities tailored for newcomers during the week.

Key Discussion Points

Session 5: Internet Drafts and RFCs

Presented by Alice Russo and Rich Salz.

• The RFC Series:

  • Alice Russo introduced the RFC series, pointing to the newly updated website at rfc-editor.org. RFCs are stable, freely available, and support interoperability.
  • Modern RFC formats include a responsive HTML design (supporting SVG diagrams), a compact HTML file, PDF (the only paginated format), and plain text. The primary source format is RFC XML.
  • Document Statuses: RFCs are categorized as Informational, Experimental, Proposed Standard, or Internet Standard. Proposed Standard is the most common maturity level (~70% of documents published recently).
  • Subseries: Some RFCs are also designated as Internet Standards (assigned an STD number) or Best Current Practices (assigned a BCP number). These numbers act as persistent containers that can encompass multiple or updated RFCs (e.g., STD 7 for TCP).
  • Streams: Documents originate from one of five streams: IETF, IAB, IRTF, Editorial, or Independent Submission (reviewed by the Independent Submissions Editor, Elliot Leer). Only the IETF stream can publish standards-track or BCP documents.

• Internet-Drafts (I-Ds):

  • Rich Salz explained that I-Ds are the working documents of the IETF. Unlike RFCs, they are expected to change and automatically expire after six months, though they remain permanently archived.
  • Anyone can submit an I-D via the Datatracker (datatracker.ietf.org). Submitting grants the IETF permanent rights to modify and publish the material.
  • Required Sections: Every draft must include an abstract, an introduction, security considerations, IANA considerations, and references (categorized into informative and normative).
  • Authoring Tools: Authors are strongly encouraged to write drafts in Markdown (specifically using the kramdown-rfc2629 dialect) rather than raw XML. Guidance, templates, and validation tools (such as author-tools for validating ABNF, XML, and YANG models) are available at authors.ietf.org.
  • Draft submissions freeze two weeks prior to each IETF meeting to allow participants time to read documents.

• RFC Production Process:

  • Once approved by the IESG, documents enter the RFC Production Center queue for copy-editing, formatting, and coordination of IANA actions.
  • Authors are given an opportunity to review the final edited text and must explicitly approve it during the final review phase (formerly known as AUTH48) before publication.

• Session 5 Q&A:

  • Nathan asked how authors coordinate with IANA for experimental versus standard protocol assignments. Alice Russo and Rich Salz clarified that IANA closely reviews drafts once they appear on working group agendas. Authors should use placeholders (like "TBD") in their drafts, and IANA will assign the actual values prior to RFC publication. Rich Salz noted that some registries have pre-allocated ranges reserved for experimental use.
  • Rachid El-Bariqi asked about creating new registries with complex logical relationships (e.g., lexical and semantic tokens for HTTP). Rich Salz advised sketching out the relationships in the draft and consulting registry experts during the drafting phase.
  • James asked if an RFC can be modified once published. Rich Salz confirmed that RFCs are immutable; changes require publishing a new RFC that explicitly "updates" or "obsoletes" the old one. In the interim, errata are collected.
  • James also asked for the best path to introduce a brand-new idea. Rich Salz and Michelle Cotton recommended presenting at HotRFC (a rapid lightning-talk session), submitting an initial I-D to an area dispatch group (e.g., SECDISPATCH), or consulting the IAB New Work Help Desk.

Session 6: Power of the Community in the IETF

Presented by Bron Gondwana.

• IETF Culture and Individual Contributions:

  • Bron Gondwana emphasized that the IETF is composed of individual contributors, not company representatives. To successfully progress an idea, authors must build "social capital" by listening to feedback, participating in other working groups, and building relationships outside of formal sessions.
  • Most leaders (Working Group Chairs, Area Directors, IAB members) are unsalaried volunteers sponsored by their employers.

• The Nominating Committee (NomCom):

  • The NomCom is responsible for selecting the IETF leadership. It consists of ten voting members chosen via a random lottery from a pool of qualified community volunteers.

• The IETF "Immune System" and Professionalism:

  • The community operates under a Code of Conduct designed to ensure professional, respectful, and productive collaboration.
  • A newly established community moderation process and an active Ombuds team (including David) help address harassment and disruptive behavior.
  • Working Group Chairs hold substantial authority to manage discussions and judge consensus.

• Disputes and Appeals:

  • Participants who disagree with a decision can initiate a formal appeal process. The ladder of appeal starts with the Working Group Chairs, followed by the Area Directors (ADs), the IESG, the IAB, and finally the Internet Society (ISOC) Board of Trustees.

• Session 6 Q&A:

  • Nico Caballero asked about the formal requirements for becoming an IAB member. Bron Gondwana and Leslie Daigle (former IAB Chair) clarified that there are no strict academic or institutional requirements. The NomCom looks for candidates with a broad, generalist technical understanding of the IETF ecosystem and the ability to manage external liaisons (e.g., with ICANN).

Summary and Wrap-up

Presented by Jay Daley and Michelle Cotton.

• Jay Daley noted that the IETF is primarily an engineering-driven organization characterized by direct, pragmatic technical dialogue.
• Michelle Cotton highlighted key newcomer-friendly activities scheduled for the week:
  • Quick Connections: A speed-networking session where newcomers can chat briefly with leadership, IAB/IESG members, and experienced working group chairs.
  • New Participant Dinner and Meetup Spot: Social options for self-organizing dinners and coffee meetings.
  • New Participant Social Hour: A feedback session held on Thursday afternoon.
  • HotRFC: An evening session of rapid-fire talks on new, unchartered ideas.
  • Sisters: A dedicated networking group and lunch for women and nonbinary participants.
  • Help Desks: Newcomers were encouraged to visit the Secretariat registration desk, the IAB New Work Help Desk, the IANA desk, and the RFC Editor desk for guidance.

Decisions and Action Items

• No formal standards-track decisions or consensus calls were taken during these informational tutorials.

Next Steps

• New participants are encouraged to download templates from authors.ietf.org to begin drafting technical ideas.
• Participants interested in introducing new work should monitor the schedule for the IAB New Work Help Desk and relevant Area Dispatch sessions.
• Attendees should monitor the daily morning email updates from Michelle Cotton for daily newcomer highlights and room updates.

Session Date/Time: 19 Jul 2026 07:30

NEWPARTICIPANT

Summary

The New Participant Program at IETF 126 offered a multi-part introductory track to orient new attendees. The program provided an overview of the IETF’s history, organizational structure, culture, and administrative operations, followed by deep dives into standard development processes, meeting technologies, and the collaborative philosophy behind the IETF Hackathon.

Key Discussion Points

Session 1: Introduction to the IETF

Presented by Jay Daly: New Participant Program - Session 1 - Introduction to the IETF

• History and Mission: The IETF was formed in 1986. The RFC series pre-dates it, beginning in 1969 with RFC 1 by Steve Crocker and edited for 28 years by Jon Postel. The mission is to produce high-quality, relevant technical documents that influence how people design, use, and manage the Internet.
• Organizational Structure:
  • Internet Engineering Steering Group (IESG): The peak technical body responsible for the standards process, composed of Area Directors (ADs).
  • Internet Architecture Board (IAB): Provides long-term architectural oversight, manages liaison relationships, appoints leadership roles (such as the IRTF Chair and Independent Submissions Editor), and serves as the primary appeal body. Key recent RFCs include RFC 8890 (The Internet is for End Users) and RFC 9413 (Maintaining Robust Protocols).
  • IETF LLC: The legal and financial entity that supports the administrative operations of the IETF.
  • Internet Research Task Force (IRTF): A parallel stream focused on long-term research rather than engineering standards, structured into 16 research groups.
  • IETF Trust: Separately protects and holds the IETF's intellectual property.
  • Internet Society (ISOC): The parent charity organization providing core funding.
• Funding and Demographics: The IETF is a non-profit, non-membership organization. Funding is derived from ISOC, meeting registration fees, corporate sponsorships, and hardware/service donations (e.g., Cisco, Juniper, Cloudflare). Survey data shows Europe and North America remain the dominant participating regions, with a median age range of 45–54. Female participation is below 10% overall but is approximately 25–30% among new participants.
• Intellectual Property and Note Well: Participants operate as individuals, not corporate representatives. Contributions (spoken words, emails, or draft uploads) grant perpetual, irrevocable licenses to the IETF Trust. The patent regime is based on timely disclosure; the IETF does not police patents but requires disclosures so working groups can make informed technological decisions.
• Q&A:
  • Sam (University of Toronto) asked about the high median age range of participants and how the IETF plans to bridge the gap for younger researchers (Ph.D. or Master's students). Jay Daly clarified that because the IETF cannot directly select or fund participants, it relies on organic outreach and structural support systems (like the New Participant Program) to ensure that students who do engage are listened to and integrated.

Session 2: Participating in the IETF

Presented by Sean Turner: New Participant Program - Session 2 - Participating in the IETF

• Communication Mechanics: Email is the primary mechanism of IETF operations. There are over 500 active mailing lists (announcements, working groups, general administrative lists, and meeting-specific lists). Good email etiquette requires writing concisely, using informative subject lines, trimming excess text ("snipping"), and replying below the quoted text.
• Administrative and Technical Tools:
  • Data Tracker: The centralized document management system used to log in, track draft statuses, view working group charters, and customize meeting schedules.
  • Meetecho: The bespoke on-site and remote participation tool that integrates Zulip chat, handles queue management, and executes consensus checks.
  • Chat Note: Leonard Gebauer asked in the chat if missed sessions can be viewed later and if Birds of a Feather (BoF) sessions are accessible remotely. Laura Scalone and Michelle Cotton confirmed that all sessions (including BoFs) use Meetecho, are recorded, and are uploaded to the official IETF YouTube channel.
• Meeting Etiquette & Identity: Rules for the microphone queue require joining the queue on Meetecho before speaking at the physical microphone. Lanyard colors and badges signify roles (e.g., blue for secretariat, red for "no photography").

Session 3: Standards Development

Presented by Rob Wilton: New Participant Program - Session 3 - Standards Development

• IETF Technical Areas: The standard work is split into seven areas: Applications and Real-Time (ART), General (GEN), Internet (INT), Operations and Management (OPS), Routing (RTG), Security (SEC), and Web and Internet Transport (WIT). "Dispatch" working groups (such as sec-dispatch or art-dispatch) serve as entry points to direct new work.
• Consensus and Humming: Decisions are reached by rough consensus, which prioritizes addressing technical objections over simple majority voting. The traditional practice of "humming" to gauge the room has shifted to the Meetecho "show of hands" tool to fully integrate remote attendees.
• The Document Lifecycle:
  1. Individual Phase: An author publishes an individual Internet-Draft (I-D). The author incorporates community feedback at their discretion.
  2. Working Group Phase: The WG chairs issue an adoption call. If approved, the draft becomes a WG document. The authors act as editors to represent the collective consensus of the WG. Work culminates in a Working Group Last Call (WGLC) and a Shepherd write-up.
  3. IESG/Publication Phase: The responsible Area Director reviews the draft and issues an IETF Last Call. All Area Directors review the document during a bi-weekly "telechat" and ballot "comment" or "discuss" (which blocks progress until specific concerns are addressed). Once approved, the document is polished by the RFC Editor.
• RFC Track Classifications: Documents are published as Proposed Standard (PS), Internet Standard (IS), Informational, Best Current Practice (BCP, e.g., BCP 9/RFC 2026), or Experimental.
• Q&A:
  • Rashid Buzir asked how to present complex, multi-draft ideas within limited presentation slots. Rob Wilton recommended focusing strictly on the high-level problem statement and keeping draft lengths short (under 15 pages) to maximize community reviews.
  • Tom Satter (Myoverge KK) asked where security reviews, conformance testing, and interoperability sit in the lifecycle. Rob Wilton explained that security reviews are continuous (e.g., via the security area and SEC AD telechat ballots), but the IETF does not conduct formal conformance testing.
  • Greg DiBiase (ICANN) asked if initial drafts must declare their intended RFC status. Rob Wilton confirmed that while a draft should state its targeted track (typically Proposed Standard for protocols), this status can change at any point before publication based on WG and IESG consensus.
  • Christian Dikoff asked how to handle a situation where a newcomer wishes to revive an expired individual draft but the original authors do not respond. Rob Wilton advised publishing a new draft that acknowledges and builds on the expired work while clearly citing the original authors.

Session 4: Introduction to the Hackathon

Presented by Stuart Cheshire: New Participant Program - Session 4 - Introduction to the Hackathon

• The Hackathon Ethos: Built around the philosophy of "rough consensus and running code." It occurs on the weekend preceding the IETF meeting week. It is a free, hands-on event designed to run implementations, verify protocol interoperability, and identify specification bugs before finalizing RFCs.
• No Conformance Testing: The IETF relies on multi-vendor testing and real-world implementation reviews rather than official conformance certificates. Stuart Cheshire used the historical reliability of DHCP and current work on L4S (Low Loss, Low Latency, Scalable throughput) as examples of how iterative, face-to-face packet analysis and code modification produce stable standards.
• Newcomer Projects: The Hackathon wiki uses asterisks to flag projects that are welcoming and well-suited for first-time participants.

Decisions and Action Items

• No formal technical decisions or action items were taken, as this session was informational.

Next Steps

• Quick Connections: New participants were directed to attend the Quick Connections networking event on Monday afternoon to meet Area Directors and Working Group chairs.
• IETF Sisters: Female and non-binary participants were invited to the networking breakfast on Tuesday morning and the lunch on Thursday.
• Security Area Office Hours: Participants interested in security or cryptography standards were directed to attend the SEC area office hours scheduled for Tuesday.