Summary

  • The IETF Administration LLC's 12 August 2026 RFP would turn a one-day new-participant program into modular, self-paced video that requires no presenter, cohort or shared time zone. The public record still shows an open procurement, not an awarded vendor or finished course.
  • The same specification requires all materials to be in English while also requiring captions, practical transcripts and accepted accessibility practice. Captions make spoken English inspectable; they do not create another language or prove that technical meaning was understood.
  • English is the IETF's de facto working language under RFC 7154. A common language can reduce coordination cost, but a learner still needs separate routes from opening a module to asking a situated question, finding a Working Group, making a useful contribution and having an objection evaluated.
  • A privacy-safe access-and-progression receipt should preserve module version, available formats, language, correction history and optional handoffs to human guidance or active work. It must retain a null result when the learner does not consent and must never convert plays, completions, posts or drafts into evidence of consensus or mandate.

One sentence removes a meeting

On 12 August, the IETF Administration LLC issued a request for proposals for IETF New Participants Online Training. The brief starts from a candid diagnosis: the standards process and the skills needed to participate effectively can take months or years to learn, understand and practise. Its answer is to adapt the material used in a one-day, in-person program into an online course.

The proposed course must cover why someone should participate, what the IETF is, how participation works, standards development, Hackathons, Internet-Drafts and RFCs. Each part must work inside a coherent whole and as a standalone module. Shorter video can replace a long presentation where that serves the subject.

The decisive architectural requirement is more radical than the change of medium. The program must be self-paced and on demand. It must require no live facilitator, scheduled cohort or synchronous session. A learner in Nairobi, Recife, Osaka or a night shift does not have to wait for an IETF meeting week or arrange a call across time zones merely to encounter the basic process map.

That is a real reduction in entry cost. It separates the availability of introductory knowledge from the calendar and capacity of a presenter. It also creates a reusable object: the learner can stop, replay, inspect a transcript and revisit one module when a term becomes relevant months later.

The public RFP table still lists the project as open. Questions were due on 26 August, answers or an updated RFP are scheduled for 1 September, proposals for 11 September, preferred-bidder selection for 21 September and anticipated contract execution for 28 September. Those dates describe a procurement plan. They do not establish who will build the course, what the final contract will contain, when anything will launch or whether a learner will find it useful.

Accessibility and language occupy different columns

The brief is not careless about accessibility. It calls for accepted practice such as WCAG 2.1 AA or equivalent, closed captions and, where practical, transcripts. It requires editable source video, scripts, slides, assessment content and templates. Modules must be independently updateable as tools and processes change. The IETF LLC is to receive ownership of the delivered material, and the design should favor formats it or another designated contractor can maintain over a proprietary lock-in.

Those controls matter. Captions can expose a name that was difficult to hear. A transcript can be searched. Editable scripts make corrections possible without recreating an entire recording. Source custody makes an inaccessible or obsolete derivative replaceable. Standalone modules reduce the cost of keeping one procedural explanation current.

The next sentence must remain equally visible: all materials will be in English. A caption is a textual representation of spoken English, not a French, Arabic, Japanese or Portuguese version. A transcript can help a reader move at a slower pace and use a dictionary, but it does not by itself localize idiom, institutional shorthand or the pragmatic meaning of an intervention.

This is not evidence of a breach. RFC 7154 says English is the IETF's de facto language and asks participants to remember that it is not the native language of many people in the room. A global standards body needs a shared working surface, and specifications cannot be negotiated safely if apparently equivalent sentences carry different normative force.

But the working-language fact should clarify the design problem, not end it. An English course can explain the English process in the language in which that process operates. It can also leave a learner with two distinct burdens: acquiring the institutional map and decoding the map at technical speed. Recording only that the video opened would conceal both.

Opening the map is not arriving at the work

The IETF's own getting-started page does not present one universal door. It routes people differently depending on whether they want to read or implement an RFC, join existing work, bring new work, attend a meeting or start on a mailing list. The broader participation page says anyone can contribute and locates the daily work in Working Groups, lists, documents and implementation experience.

The course is therefore upstream of several choices. A person who understands what a Working Group is may still need to identify the right group. A person who finds the list may need to learn whether a question belongs there, in an issue tracker, in an Internet-Draft review or in a private request for clarification. A technically strong objection may need vocabulary, context and timing before others can evaluate it.

These are not ceremonial frictions. They protect some useful boundaries. A newcomer is not owed acceptance of an idea merely for completing training. A chair cannot treat an assessment score as technical support. A video vendor cannot certify rough consensus. The IETF LLC can procure administrative education, but it does not thereby acquire a Working Group's authority over a document.

The reverse boundary matters too. Rough consensus cannot be used as an excuse to ignore a contribution because its English is slow or unfamiliar. RFC 7282 places weight on finding and addressing technical objections rather than counting raised hands. The quality of the objection and the engineering evidence remain distinct from the fluency of its presentation.

A clean model has at least six states:

  1. the material was publicly available;
  2. a person could access the required format;
  3. the person reports that the explanation was understandable;
  4. the person found an appropriate human or working channel;
  5. a contribution entered that channel and received an attributable disposition;
  6. the relevant group formed whatever consensus its process supports.

No state automatically proves the next. Some learners will need only the first two because they want to implement an existing RFC. Some will read without consenting to any measurement. Some will contribute years later. A person can also become effective without ever taking the course.

The missing live layer already has a name

The no-live requirement makes the product scalable. It also deliberately removes the place where a learner can ask, “Which list is the real place for this problem?” or “Did that chair's sentence close the issue?” The answer is not to smuggle a mandatory webinar back into an on-demand contract. It is to keep the handoff visible.

The existing IETF Guides Program supplies a different kind of support. It matches an experienced participant with a newcomer for advice, coaching and collected practical knowledge. A request can include a preferred language. The relationship is volunteer-based, usually linked to a meeting and limited by the guide's time. It cannot be promised as an unlimited global service.

That limitation is precisely why the course and the guide should not be described as substitutes. The course provides a stable common baseline. A guide interprets a specific situation, introduces people and helps a participant navigate unwritten context. A mailing list exposes the work to open technical challenge. A Working Group chair manages the process. Each actor has a different job.

The IETF 126 post-meeting report says 36% of responding new participants were unaware of the Guides Program. That statistic is useful only inside its boundary. It comes from respondents, not every new registrant, and does not reveal why awareness was missing. It nevertheless shows why placing a link somewhere is not the same as completing a handoff.

An online module could end with several optional routes: request a guide, join a relevant list, explore Working Group descriptions, practise Datatracker tools or stop. The learner should choose. Delivery of the chosen route can be confirmed without claiming that the person understood, contributed or remained active.

Build an access-and-progression receipt

The IETF LLC does not need a surveillance system for newcomers. It needs a small evidence structure that prevents convenient metrics from collapsing unlike states.

At the content layer, the record should name the module, authoritative source version, publication date, superseded version, language, caption and transcript formats, low-bandwidth option, accessibility-review basis, terminology set and correction history. If the English source changes, the record should show which derivatives remain aligned and which are temporarily older.

At the handoff layer, a learner may opt to request a Guide, open a Working Group page, subscribe to a list or take no further action. The record can say that the selected destination was supplied. It must not say that the learner joined, understood or succeeded unless separate, consented evidence supports that narrower fact.

At the aggregate layer, the IETF may find privacy-safe counts useful: module starts, completions, caption use, transcript access, Guide referrals, first public list posts or first review comments. Each denominator and observation window must travel with the number. A public list post is a contribution event, not evidence that the contribution was correct. An Internet-Draft is work offered for review, not adoption. Continued participation is not consensus, and consensus is not representation of everyone affected by a protocol.

The receipt should preserve nulls. If analytics are disabled, a learner declines to answer or systems cannot be joined reliably, the result is unknown. Replacing unknown with zero punishes privacy; replacing it with success turns availability into propaganda.

No individual profile needs to retain accent, private questions, draft messages, employer, nationality or inferred fluency. The useful public object is the performance of the access system: what existed, in which format, for which version, with which optional handoff, under which retention and correction rule.

Portability protects more than video files

The RFP's source-file and anti-lock-in clauses are a strong starting point. A course about an evolving institution cannot be trapped inside a vendor's player or an uneditable project file. Hosting may use YouTube, the IETF website, Cloudflare Stream or a justified alternative, but the content must survive a change in operator.

Meaning also needs portability. The terms “Last Call,” “adoption,” “consensus,” “stream,” “Area Director” and “liaison” are not decorative vocabulary. If a transcript, glossary or future language version changes their relationships, a learner may leave with a cleanly produced but incorrect map.

The authoritative English module should therefore carry a versioned terminology and decision map. Any later language derivative can declare which source version it follows, who reviewed institutional meaning, which terms remain in English and how a correction propagates. That does not require every language on day one. It prevents later access work from becoming an orphaned translation with no source identity.

The same discipline applies inside English. The standards process changes. Tools move. Roles are revised. A video that was accurate at release can become wrong without a visible error. Independent module updates reduce that risk only if the old and new claims are joined by a public supersession record.

A course is successful when its limits remain legible

The strongest case for the RFP is practical. It converts valuable, scarce presenter time into a durable baseline. It keeps source files portable, calls for accessible formats, minimizes learner data and leaves technical review with IETF people who know the process.

Its limitation is equally practical. A recorded baseline cannot observe the question forming in a learner's mind. It cannot know whether an idiom obscured a rule, whether the right Working Group was found or whether an unanswered first post caused a contributor to leave. English captions reduce one barrier while leaving others intact.

The governance answer is not to call the course inclusive or exclusive in the abstract. It is to name the transitions. Availability belongs to the publisher. Accessibility belongs to formats and review. Comprehension belongs to the learner's report, if offered. Mentoring belongs to a human relationship. A contribution belongs to its author. Disposition belongs to the forum that receives it. Consensus belongs to the technical process that tests objections.

When those states stay separate, online onboarding can expand access without manufacturing an outcome. It removes the clock and records the language boundary honestly. That is a better foundation for future improvement than a completion counter pretending the journey is over.

Sources

  1. IETF New Participants Online Training RFP
  2. IETF RFPs and contracts
  3. RFC 7154 — IETF Guidelines for Conduct
  4. IETF Guides Program
  5. IETF Meeting New Participants
  6. Participate in the IETF
  7. Getting started in the IETF
  8. New Participant Program — a look back at IETF 122 and ahead to IETF 123
  9. IETF 126 post-meeting survey
  10. RFC 7282 — On Consensus and Humming in the IETF