Markdown Version | Recording 1 | Recording 2

Session Date/Time: 02 Nov 2025 19:00

NEWPARTICIPANT

Summary

This session provided new IETF participants with an in-depth understanding of Internet Drafts and RFCs, including their structure, publication process, and associated tools. It also delved into the "Power of the Community," explaining the IETF's self-organizing nature, its governance, leadership selection via NOMCOM, code of conduct, and appeal processes. The session concluded with a look ahead at the week's activities and resources available to new participants.

Key Discussion Points

Internet Drafts and RFCs (Session 5, presented by Alice and Rich)

• RFCs Overview:
  • RFCs (Request For Comments) are the high-quality, relevant technical documents forming the core output of the IETF.
  • They are freely available, stable, and support interoperability, spanning the internet's birth (e.g., TCP/IP) to modern standards (e.g., TLS 1.3, Quick).
  • Documents are immutable once published; corrections are submitted as Errata (RADA).
  • The RFC series is approaching 10,000 documents, with RFC 8700 (50 years of RFCs) highlighted for historical context.
• Publication Formats:
  • Plaintext: Original format, ASCII diagrams only, fixed line width, no hyperlinks, no dynamic metadata updates.
  • HTMLized: Available for RFCs under 5xxx, includes a gray header for post-publication metadata (updates, obsoletes, errata), links within and between documents.
  • HTML: For more recent RFCs, adaptive layout, supports SVG graphics, includes dynamic gray header for metadata (e.g., obsoleted by 9429).
  • PDF: Paginated, similar look to HTML, includes links, but lacks dynamic metadata updates like the HTML versions.
  • RFC XML: The source format for generating other publication formats, contains metadata and content.
• RFC Statuses:
  • Informational: Use cases, applicability statements, framework documents (e.g., path computation elements use cases).
  • Experimental: Time-limited experiments, new extensions (e.g., IMAP message limit extension).
  • Proposed Standard: First official stage of a standard, where many documents remain (~60% of recent RFCs) (e.g., Quick, TLS 1.3).
  • Draft Standard: Deprecated maturity level, no longer used.
  • Internet Standard: Full standard, widely deployed and interoperable (e.g., Multicast Listener Discovery for IPv6 - STD 101).
  • Best Current Practice (BCP): Dual role for process (IETF standards process) or technology best practices (e.g., OAUTH 2.0 security).
  • Historic: Superseded specifications not to be used (e.g., NTP V2/V3). Note: Obsoleted RFCs are not always marked Historic.
  • Unknown: RFCs published before statuses existed (e.g., RFC 1 from 1969).
• Sub-series:
  • STD (Internet Standards): Numbering for Internet Standards (e.g., STD 5: IP, STD 7: TCP). Can change over time as RFCs are updated/obsoleted.
  • BCP (Best Current Practices): Numbering for BCPs (e.g., BCP 9: IETF standards process, BCP 226: meeting venue selection process, composed of four RFCs).
• Streams: Indicates the origin of the document.
  • IETF Stream: Largest, publishes any status, only stream for STD and BCP sub-series (~90% of recent RFCs).
  • IAB (Internet Architecture Board): Informational, experimental, historic RFCs related to architecture.
  • IRTF (Internet Research Task Force): Informational, experimental, historic documents from research groups.
  • Editorial: Policies of the RFC series.
  • Independent Submission: RFCs outside official IETF/IAB/IRTF processes but relevant, with a conflict review.
  • Legacy: RFCs published before the concept of streams existed (~2000 documents).
• Internet Draft Structure and Content:
  • Common Elements (Drafts & RFCs): Title, author/editors, publication date, status, updates/obsoletes (e.g., TLS 1.3 obsoletes TLS 1.2).
  • Draft-specific Elements: Working group, stream (implied for adopted drafts), expiration date (archived after 6 months).
  • Auto-generated Sections (for RFCs): Status of the Memo (boilerplate), Copyright and IPR, Table of Contents, Abstract (short summary), Introduction (motivation), Security Considerations (must-have), IANA Considerations (protocol registries), References (normative and informative).
• Writing Internet Drafts:
  • Anyone can write and submit a draft; no permission or pre-checking required. Can be used for technical discussion.
  • Once submitted, a draft cannot be removed (with rare historical exceptions).
  • Submission grants rights to the IETF Trust for distribution.
  • Naming Convention: draft-username-short-blurb-NN (individual), draft-ietf-wg-name-short-blurb-NN (working group adopted).
  • Recommended Tooling: Cramdown-RFC Markdown is strongly recommended for writing. Avoid direct RFC XML, Enroff, or Microsoft Word.
    • Cramdown-RFC adds metadata (references, working group, GitHub repo) and stylistic conventions (e.g., `` for automatic linking).
  • Language Guidelines: BCP 14 defines keywords like MUST/MAY/SHALL (all caps, bold in output). Inclusive language is encouraged (e.g., primary/secondary instead of master/slave).
  • Author Tools (authors.IETF.org): Provides guidance on toolchains, style guides, and special content (diagrams, formal languages like ABNF, Yang).
  • author-tools.IETF.org: A site to upload plain text/XML, render it in various formats (PDF, HTML, XML), run diffs, and perform IDNITs (Internet Draft NITs) to check for style violations, missing sections (abstract, copyright), or content errors.
  • Submission to Datatracker (datatracker.ietf.org): Click "Submit a Draft," browse and upload. Tool validates, checks with authors, and sends confirmation email.
  • Cut-off Dates: No new drafts can be submitted two weeks before a plenary meeting; submission reopens after the meeting.
• RFC Publication Process (RFC Production Center - RPC):
  • Once an Internet Draft is approved for publication, the RPC takes control of the source file, assigns an RFC number, and performs professional copy editing.
  • AUTH48 (Authors 48 Hours): Authors review the edited document before final publication, ensuring technical accuracy and clear meaning.
  • RPC ensures IANA actions are clearly documented.
  • Each author listed in the header must approve the AUTH48 draft.
  • RPC creates various final formats and announces publication on IETF announce and RFC dist mailing lists.
• Resources: authors.IETF.org, I-D-Template (GitHub tooling by Martin Thompson).

The Power of the Community (Session 6, presented by Harold Alvestrand)

• IETF Mission: "Make the Internet Work Better."
• Nature of IETF:
  • Volunteer-driven, contributing to documents to achieve the mission.
  • Self-organizing: The community is the final arbiter of its activities.
  • No defined membership: Participation makes one a member of the community.
• Governance Structure: IESG (Internet Engineering Steering Group), IAB (Internet Architecture Board), IETF LLC (legal entity).
• Nominating Committee (NOMCOM):
  • Selects IETF leadership.
  • Process: Volunteers (must show participation in 3 out of the last 5 IETF meetings) are selected randomly. No two members from the same company.
  • Consists of 10 randomly selected volunteers and 5 non-voting liaisons (from IAB, IESG, ISOC, IETF LLC, IETF Trust) for historical context and questions.
  • A new NOMCOM is selected annually, with a chair (usually an experienced community member) appointed by the ISOC President.
  • NOMCOM calls for nominations, interviews candidates, and selects based on qualifications.
  • Selected "slates" are sent to confirming bodies (e.g., IAB for IESG) who can reject but rarely do.
  • Selections are announced, and new leaders are seated at the March IETF meeting.
• Code of Conduct and Disruptive Behavior:
  • Core Principles: Extend respect and courtesy, assume good intent, focus on technical arguments, avoid personal attacks or non-technical comments.
  • Managing Disruptive Behavior: Forum chairs can intervene (e.g., "step down," suspend mailing list privileges).
  • Ombuds Team:
    • Handles interpersonal issues (harassment, intimidation, belittling behavior).
    • Operates with complete confidentiality: Investigates, recommends actions, and ensures follow-through without disclosing details.
    • Members are publicly identified and available for contact.
• Consensus and Appeals:
  • IETF strives for "rough consensus" (or just "consensus"), often indicated by humming in Meetecho.
  • If a participant believes a decision is wrong (technical or process error), they can appeal.
  • Appeal Process (multi-step):
    1. Working Group Chair: First decision-maker. Can reopen discussion or uphold the decision.
    2. Responsible AD (Area Director): Informal discussion.
    3. IESG (Internet Engineering Steering Group): Formal appeal (public). The entire IESG deliberates and delivers a public decision (denied or sent back to WG).
    4. IAB (Internet Architecture Board): Appeal of an IESG decision (public).
    5. Internet Society Board of Trustees: Third level of appeal, only on process, not technical content (very rare).
  • Appeals are time-consuming and taken very seriously by leadership.

Wrap-up and Next Steps (presented by Michelle and Jay)

• New Participant Program Goals: Provide general IETF information, organizational overview, useful meeting info, leadership/resources, hackathon intro, basic standards process, Internet Draft writing guide, and effectiveness tips.
• Feedback: A survey will be sent out for feedback on the program.

Decisions and Action Items

Decisions:

• The IETF operates on a self-organizing, volunteer-driven model with a leadership selected by the community through the NOMCOM process.
• RFCs are the primary output, immutable after publication, with various formats and statuses.
• Internet Drafts are the working documents, versioned and temporary, with specific tools and processes for creation and submission.
• A Code of Conduct and an Ombuds Team are in place to ensure a respectful and productive environment.
• A formal multi-level appeal process exists for addressing disagreements with technical or process decisions.

Action Items for New Participants:

• Attend Events:
  • Quick Connections (immediately following this session on 21st floor).
  • New Participant Dinner (sign-up required) or Hack Demo Happy Hour (tomorrow night).
  • New Participant Social Hour (Thursday, no sign-up needed).
  • Welcome Reception (tonight, immediately after Quick Connections).
  • Hot RFC Lightning Talks (tonight, after Welcome Reception).
  • Sisters networking event (Monday morning).
  • IETF Plenary (Wednesday night, Q&A with leadership).
  • Host Speaker Series (Thursday).
  • Farewell Reception (Friday).
• Stay Informed:
  • Check the agenda frequently for session updates/cancellations.
  • Read daily morning messages for new participant-relevant information.
  • Identify and attend working group sessions of interest.
• Utilize Resources:
  • Visit help desks: Registration, Technical Help Desk, RFC Editor, IANA Desk, Ombuds Team.
  • Explore authors.IETF.org and author-tools.IETF.org for writing Internet Drafts.
  • Consider the IAB New Work Help Desk (Monday & Wednesday) for new ideas.
  • Attend Area Director office hours for specific topics.
• Engage with Peers:
  • Use new participant activities and the mailing list to connect with fellow new participants.
  • Look for a new participant meetup spot sign in the hotel.
• Provide Feedback:
  • Complete the survey for the New Participant Program to help improve future sessions.

Next Steps

• Immediately Following Session: Quick Connections networking event on the 21st floor, followed by the Welcome Reception.
• Throughout the Week: Numerous IETF activities, working group sessions, and social events are scheduled. Participants are encouraged to consult the agenda and daily messages.
• Program Improvement: Feedback from the upcoming survey will be used to revise and enhance the New Participant Program for future IETF meetings.

Session Date/Time: 02 Nov 2025 14:30

NEWPARTICIPANT Session Minutes

Summary

The NEWPARTICIPANT session provided a comprehensive introduction to the Internet Engineering Task Force (IETF), covering its structure, mission, unique characteristics, operational processes, and mechanisms for new participant engagement. Speakers included Jay Daly (IETF Executive Director), Bron (IETF participant and hackathon co-chair), Rob Wilton (former Area Director), Benoit (Area Director), and Charles (Hackathon co-chair). The session aimed to demystify the IETF's complex environment, foster a cohort of new participants, and provide a head start in understanding how to contribute effectively, from initial ideas to the publication of RFCs. Key topics included IETF's community-driven nature, the rough consensus model, the document lifecycle, IPR policies, and the role of running code.

Key Discussion Points

• Welcome and Program Overview: Jay Daly introduced the New Participant Program, emphasizing its value in helping newcomers navigate the IETF's complex structure and participate productively. The program aims to demystify processes and build a supportive cohort.
• IETF Characteristics: The IETF is a standards development organization focused on internet technologies with unique traits:
  • No formal membership; anyone can participate as an individual.
  • Market-based adoption drives the success of standards.
  • Bottom-up and community-controlled, with decisions made by "rough consensus," not voting.
  • No formal role for governments, and no sales/promotional booths at meetings (an "engineers' conference").
• IETF Mission: To produce high-quality, relevant technical documents that influence the design, use, and management of the internet. Adoption of IETF standards is voluntary, necessitating high quality and relevance.
• Brief History: Formed in 1986. The Request for Comments (RFC) series began in 1969, becoming the first online publication series. John Postel managed the RFC series for 28 years.
• IETF Participant Demographics:
  • Annual surveys track participation. Of ~53,000 subscribed email addresses, ~7,000 are active participants (sending emails, attending meetings, submitting documents).
  • Breakdown of participation types: ~12% regular, ~24% occasional, others as readers, monitors, previous, or new participants.
  • Regional distribution: ~40% Europe, ~40% North America, ~11% Asia (growing).
  • Gender: 85% male-dominated, with ongoing efforts to address this through initiatives like IETF Sisters.
  • Age: Top-heavy, median in the 50s, reflecting long-term engagement and the learning curve.
  • Employment: Most participants are employed, primarily in business, with a significant portion from academia.
• IETF Structure: The community is at the top, supported by key bodies:
  • Internet Engineering Steering Group (IESG): Peak body for the IETF process, responsible for standards process and technical management. Consists of Area Directors (ADs) and led by the IETF Chair.
  • Nominating Committee (NOMCOM): Instantiated annually, selects community members for positions of authority (e.g., IESG, IAB).
  • Internet Architecture Board (IAB): Provides long-term technical direction for Internet architecture, manages external liaisons, and makes key leadership appointments (e.g., IRTF Chair). Offers architectural oversight and is the next appeal body after the IESG.
  • Internet Research Steering Group (IRSG): Manages the Internet Research Task Force (IRTF), focusing on long-term research issues.
  • IETF Trust: Holds intellectual property (IP) for the IETF.
  • IETF Administration LLC: Provides corporate and administrative support (finances, services, meetings), led by the Executive Director.
  • Internet Society (ISOC): Parent organization, promotes and protects the internet globally, provides significant funding to the IETF LLC. The ISOC CEO chooses the NOMCOM chair (a non-voting role).
  • Support Staff: Secretariat (runs meetings), RFC Production Center (edits/publishes RFCs), IANA (operates registries for IETF protocols).
• IRTF (Internet Research Task Force): A parallel organization to the IETF, consisting of 16 research groups with a broader research focus. Key differences from IETF working groups: no deliverables/milestones, longer-lived, publish only informational/experimental RFCs (not standards), do not require consensus (may publish competing ideas), and have a supplementary code of conduct.
• IETF Funding: A US 501(c)(3) non-profit, does not distribute profits, and is not a "pay-to-play" standards organization. Funding sources include the Internet Society, registration fees, corporate sponsorship (including in-kind equipment), and direct donations.
• IETF Policies ("Note Well"): Participants agree to IETF processes and policies. Key aspects include:
  • Professional conduct, respect, and courtesy.
  • Mandatory disclosure of patents known to cover IETF work (authored by self/employer/sponsor, financial benefit, individual contributor). This is a transparency mechanism, not a validation of patents.
  • Adherence to dispute and appeal processes.
  • High transparency: Routinely makes public written, audio, video, and photographic records (e.g., mailing list archives are public). Contributions grant the IETF Trust a perpetual, irrevocable, non-exclusive, royalty-free license to copy, publish, distribute, and make derivative works.
  • GDPR compliant, but does not sell data and keeps certain personal/payment information confidential.
• Participation Tools:
  • Meetecho: Custom tool for participation, used for session access, joining the queue to speak, and polling. Integrates on-site and remote experiences.
  • Datatracker (datatracker.ietf.org): Central repository for documents, history of drafts, meeting agenda. Functions as an identity provider for other tools.
  • Mailman: Standard mailing list manager; all decisions are confirmed on mailing lists, and all messages are contributions.
  • Zulip: Chat system used for real-time coordination and communication during meetings and for hackathon projects.
  • Wiki: Provides information, including about meetings and hackathon projects.
• Effective Participation:
  • On-site Meetings: Occur three times a year. Parallel sessions require prioritization; remote access via Meetecho is possible. Human interaction is crucial for building trust and agreement.
  • Speaking as an Individual: Participants represent their personal ideas and expertise, not necessarily their employer's official stance.
  • Rough Consensus: Decisions are made once all technical input has been heard and addressed; it does not mean everyone agrees or gets their way. In-room consensus is gauged via "humming" (to avoid putting individuals on the spot) or Meetecho polling for remote participants.
  • Preparation: Read drafts and materials before sessions.
  • Reviewing Documents: A great way for newcomers to engage, learn, and build "social capital" by providing constructive feedback.
• IETF Areas and Working Groups:
  • IETF is split into seven functional areas: Applications and Real-Time (ART), General (GEN), Internet (INT), Operations and Management (OPS), Routing (RTG), Security (SEC), Transport and Services (TSVWG). Each has 1-3 Area Directors.
  • Working Groups (WGs) are specific to areas, chartered for specific topics, and are created/closed as needed. "Dispatch" WGs (e.g., GENDISPATCH, OPSAWG) act as entry points for new cross-area or general work.
  • New participants are encouraged to focus on one WG initially, subscribe to its mailing list, and review its charter and documents.
• Individual vs. Working Group Documents:
  • Individual Drafts: Authored by a participant, proposed to a WG (often with the WG acronym in the name for visibility).
  • Working Group Documents: Adopted by a WG after a "Call for Adoption" (assessing scope, interest, solution outline). Once adopted, the document is owned by the WG and reflects WG consensus, even if authors disagree. The WG can assign a new editor if progress stalls.
• Document Process Flow:
  1. Individual Phase: Write an individual draft, solicit feedback via mailing lists and presentations. Update based on comments.
  2. Working Group Phase: If sufficient interest, chairs issue a "Call for Adoption." If adopted, it becomes a WG Document. Authors refine the document, track issues. When deemed complete, a "Working Group Last Call" (WGLC) is issued to confirm WG consensus for publication. Issues are resolved.
  3. IESG Stage: After WGLC, a "Shepherd Write-up" is submitted to the IESG. Directorate reviews (from other areas) occur. An "IETF Last Call" (IETFLC) is issued for broader IETF review. The IESG then formally ballots on the document (via telechats). "Discusses" (concerns requiring resolution) and "Comments" (suggestions) are addressed. Once consensus is reached, the document enters the "RFC Editor Queue" for final editorial checks and publication as an RFC.
• RFC Types:
  • Standard Track: Proposed Standard (ready for deployment), Internet Standard (widely deployed, few documents achieve this status).
  • Informational: Useful information, operational/deployment considerations, proprietary protocols.
  • Best Current Practice (BCP): IETF process documents or operational guides/recommendations.
  • Experimental: Time-bounded experiments, denoting unstable protocols that may change significantly.
• Bringing New Work to the IETF:
  • Problem Statement: Is it an IETF (engineering) problem or an IRTF (research) problem? Who will use the work?
  • Drafting: Write an IETF draft clearly and unambiguously.
  • IPR Disclosure: Mandatory to disclose known patents covering the work.
  • Goal Setting: Understand the ultimate goal (e.g., published RFC, code contribution, review).
  • Community Building: Do not try to succeed alone. Build a community of interested participants through discussions and collaboration.
  • Bird of a Feather (BoF): A pathway to create new working groups by assessing problem validity, IETF suitability, community interest, and chance of success.
  • Prioritization: Working groups prioritize WG-adopted documents for presentation time over individual drafts, especially those discussed on mailing lists.
  • Volunteer Spirit: Everyone is a volunteer; mutual review and feedback are essential for progress.
• Hackathon Introduction: The hackathon emphasizes "running code" as a core IETF mantra. It aims to accelerate the pace and relevance of IETF work, foster deployment, and attract new developers. It's a collaborative, free event with typically 300+ participants and 40-50 projects, covering a wide range of IETF technologies. Projects are listed on a wiki, and results are presented in short demos. Remote participation is supported via tools like Gather, team schedules, and chat apps. A mix of subject matter experts and developers is encouraged.

Decisions and Action Items

• Decision: IETF decisions are primarily made through a process of "rough consensus," not formal voting. This involves careful consideration of all technical input and arguments.
• Decision: By participating in the IETF and contributing, individuals grant the IETF Trust a specific license to use their contributions for publication and derivative works.
• Decision: Mandatory disclosure of Intellectual Property Rights (IPR), specifically known patents that cover IETF work, is a condition of participation. This must occur by the Call for Adoption stage at the latest.
• Decision: Working Group (WG) chairs prioritize presentation slots for WG-adopted documents (WACUP) over individual drafts, especially those that have been actively discussed on mailing lists.
• Action Item (New Participants): Familiarize yourself with and utilize IETF participation tools, including Meetecho, Datatracker, Mailman, Zulip, and the IETF Wiki.
• Action Item (New Participants): When bringing new work, clearly define the problem statement, write an IETF draft (even if incomplete), disclose any relevant IPR, and actively seek to build a community of interested participants.
• Action Item (New Participants): Engage in mutual review of documents; reviewing others' drafts is an effective way to learn and build social capital within the community.

Next Steps

• Continue Program: Attend remaining sessions (Session 4: Hackathon Intro, then Lunch, followed by Sessions 5 and 6) of the New Participant Program.
• Networking: Participate in the New Participant Dinner and Quick Connections event to meet IETF leadership and long-term participants.
• Explore: Dive deeper into the IETF's resources, such as Datatracker's document history, mailing list archives, and the wiki.
• Engagement: Consider how to contribute to existing working groups, possibly by reviewing drafts or engaging on mailing lists.
• Hackathon: Explore participating in future IETF hackathons to contribute to "running code" and gain practical experience with IETF protocols.