Summary

  • The IETF describes public side meetings as unofficial and outside the formal agenda. For IETF 126 it offered two hybrid rooms, with stated capacities of roughly 40 and 15, when those rooms were not needed for leadership or other official purposes.
  • The scheduler opened after the final agenda and the Secretariat confirmed reviewed requests on a first-come, first-served basis. Arrival order is a defensible way to allocate a small logistical pool; it is not a finding about technical merit, urgency, demand or IETF priority.
  • IETF 126 respondents rated side-meeting agenda conflicts at 3.08 out of five, the lowest side-meeting score. A separate organizer survey received 14 answers from 42 recipients. These figures identify a scheduling problem, not the effect on any named topic or a mandate for a replacement system.
  • A privacy-safe allocation receipt should expose the requested block, assigned room, capacity, queue/disposition state, declared conflicts, recording and attendance-data method, corrections, and an explicit unofficial / no process standing label. A later draft, BoF or working group must enter through a separate forward link.

Start with the room, not the idea

The IETF side-meeting page begins with a boundary. Participants sometimes arrange public discussions during, before or after an IETF meeting. The organization provides limited support, but the meetings are unofficial and do not appear on the formal meeting agenda. That sentence is the institutional checksum for everything that follows.

The resources are tangible. When spare after leadership and official uses, the large room has a U-shaped layout for forty, push-to-talk microphones, presentation equipment, power and a dedicated Webex laptop. The smaller room accommodates about fifteen, depending on the venue, with presentation equipment, a Meeting Owl and its own Webex laptop. The service does more than lend four walls. It gives a discussion physical capacity, remote reach, a calendar position and a recognizable connection to an IETF meeting.

None of that is trivial. A proposal heard by forty people with remote participation can gain criticism, collaborators and language it did not have in a private dinner. An overlooked operational problem can find the area expert sitting two corridors away. An organiser can test whether a problem statement survives questions before asking an Area Director for formal process time. Side meetings are part of the ecology from which standards work may grow.

But ecology is not authority. The room is an input surface. It does not decide whether the problem belongs at the IETF, whether the proposed scope is sound, whether enough people will perform the work, whether objections were answered or whether a working group should exist. The calendar square records access to a resource. Reading it as a verdict about the idea changes the subject of the record.

First come is an ordering rule, not a priority rule

The scheduler becomes available after the final IETF agenda is published. Organisers see a calendar, choose one of the two rooms, select a visible block of one hour, ninety minutes or two hours, and submit details. The request includes a Datatracker-linked name and email, a title, a detailed description and hosts, relevant IETF areas, and an external meeting link when the supplied Webex account is not used. The Secretariat reviews the request, may ask for more information and confirms requests on a first-come, first-served basis.

That last phrase does useful governance work. Arrival time is observable, cheap to administer and less vulnerable to quiet ranking by institutional insiders. For requests that satisfy the published conditions, a queue can prevent the meetings team from becoming an accidental technical programme committee. It protects the very informality the service is meant to support.

The same virtue creates a semantic risk. In ordinary language, “first” is easily borrowed by “priority.” In the scheduler, first means that a request reached the administrative queue earlier. It does not mean that the topic is more urgent for operators, better specified, more likely to achieve interoperability, more widely supported, more suitable for standardisation or more important than work happening in the other room.

Nor does review convert ordering into endorsement. The request fields allow the Secretariat to operate the service: identify a responsible organiser, understand the proposed use, connect it to relevant areas, arrange remote access and follow up on missing information. The policy does not say that Secretariat confirmation performs technical review. Under RFC 8711, administrative support does not rewrite the IETF standards process. A clean room allocation can be completely valid while the underlying technical proposal is premature, disputed, outside scope or never taken further.

A queue is neutral only about the criterion it declines to judge. It cannot make time abundant, enlarge the smaller room, remove conflicts or give late-arriving organisers an equal result. Neutrality of administration should therefore be reported as bounded procedural equality—not as proof that every topic enjoyed equal opportunity to be heard.

The formal agenda casts a shadow

Opening the side-meeting scheduler after the final agenda is sensible. Organisers can see Working Group, Research Group, BoF and plenary sessions before choosing their block. But “can see” is not “can avoid.” Two rooms and a finite week create overlapping claims on the same people.

The IETF 126 post-meeting survey made that constraint visible. Overall side-meeting satisfaction was 3.68 on a five-point scale. Respondents rated usefulness at 3.84 for themselves and 3.85 for the broader IETF. Agenda conflicts received 3.08, the lowest side-meeting score. Open comments mentioned a growing number of side meetings, conflicts with Working Group and Research Group sessions, and available meeting space. The IETF says the feedback was passed to the IESG as the body responsible for meetings.

The numbers should stay within their evidence boundary. The main meeting survey had 406 responses among 1,779 registrants. A separate side-meeting organizer survey went to 42 recipients and received 14 responses. Forty-two is not presented as a meeting count. It may include multiple organisers for one meeting, or other relationships the public summary does not expose. Fourteen responses do not measure every conflict, and a score of 3.08 cannot tell us which proposal lost an expert or whether the absence changed an outcome.

Still, the signal is specific enough to matter. The official agenda occupies the highest-value hours of many participants. A side meeting that overlaps the Security area can lose security reviewers; one that overlaps Operations can lose deployers; a cross-area topic may have no conflict-free block at all. The room may remain open and free while the relevant attention is already committed elsewhere.

This is the shadow-agenda effect. It is not a secret agenda and it does not imply misconduct. It is the predictable consequence of placing unofficial discussions around a dense formal programme. The side calendar shows which discussions obtained a block. Without a record of alternatives and conflicts, it does not show which discussions were impossible to place, how organizers traded capacity for timing, or which intended audience was unavailable.

Visibility can then be mistaken for demand. A full fifteen-seat room may indicate intense interest, or merely a small capacity. A half-empty forty-seat room may reflect weak interest, an official-session clash, remote participation, late publicity or an overly large allocation. Attendance is an outcome of subject, schedule, room, discoverability, travel and competing obligations. It is not a one-field measure of legitimacy.

Open and free does not erase access costs

The public-side-meeting rules establish valuable safeguards. Organisers and attendees must be registered for the IETF meeting. The discussion should be open and free to any registered participant. The IETF Note Well applies, so informality does not create a policy-free enclosure. Recording requires active consent from all participants. Attendance data is not required; if an organiser collects it, participation in that collection must be optional and the organiser is responsible for compliance with the IETF privacy statement.

These conditions describe eligibility and conduct. They should not be stretched into a claim of equal practical access. Registration may carry a fee or require a waiver. Onsite participation carries travel, visa, accommodation and time costs. Remote participation depends on time zone, equipment and publicity. The room has a capacity. A clash may force a participant to choose between chartered work and an emerging topic.

Nor should the cure be compulsory attendance tracking. A named list would make the room easier to count and harder to enter. People may wish to listen before associating their identity or employer with a nascent subject. Optional collection is a deliberate privacy boundary. A governance record can disclose capacity, aggregate or banded attendance when voluntarily and consistently collected, and the method used. It does not need to identify participants or turn presence into a roll call.

The same discipline applies to recordings. A recording expands access and preserves what was said, but only after active consent. The absence of a recording is not evidence that a meeting was closed or illegitimate. The existence of one does not make every statement an IETF position. Capture preserves speech; it does not supply authority.

Side meeting, BoF and working group are different objects

The cleanest defence against status inflation is to compare the side-meeting record with the formal path it does not replace. RFC 2418 describes Working Groups as the primary mechanism for developing IETF specifications and guidelines. Anyone seeking to create one must obtain the advice and consent of the relevant Area Director and proceed through formal formation steps. The charter moves through Area Director review, public notice, IAB review and IESG approval before the Secretariat records an approved group.

A Birds-of-a-Feather session is also different from a side meeting. RFC 2418 says a BoF request must be filed with a relevant Area Director, who must approve it before it can be scheduled; a description and agenda are required. Available BoF time is limited and Area Directors exercise defined judgement. A BoF can explore whether a working group is warranted, or can host a one-time discussion without an intention to charter.

RFC 5434 shows how much work can precede a successful BoF aimed at forming a group: public discussion, a clear problem statement, evidence of critical mass, Internet-Drafts, early engagement with Area Directors and a proposed charter. It cautions that the useful work often happens on a public mailing list before the meeting session. A booked side room can help people begin that preparation. It is not a shortcut through it.

The distinctions can be written as a sequence:

  1. A topic is discussed informally.
  2. A side-meeting request obtains or fails to obtain a scarce room.
  3. Participants may create drafts, lists or other public evidence.
  4. A relevant authority may accept a BoF request under the formal process.
  5. A proposed charter may be reviewed and approved, changed or declined.
  6. A working group, if formed, may adopt work and assess rough consensus.
  7. Later publication and deployment decisions follow their own authorities.

Each transition needs its own actor and record. Skipping a line in prose does not skip it institutionally. A statement such as “the work emerged from an IETF side meeting” can be historically true. “The IETF prioritized the work by giving it a room” is a different claim and lacks that authority.

Even within a working group, visible support is not a vote count. RFC 7282 explains that rough consensus turns on whether issues and objections have been addressed, not which side packs a room or hums loudest. If a full formal session cannot establish consensus by head count, an unofficial fifteen-seat room certainly cannot do so by occupancy.

What the calendar currently forgets

The public scheduler is good at the present tense. It can show that a titled meeting occupies a room at a stated time and may provide a link or description. That is enough for discovery. It is not enough to audit how scarcity was applied or to prevent later readers from assigning the slot more meaning than it had.

Several states can collapse into an empty square: no request was made; a request arrived after the room was taken; the organiser withdrew; the Secretariat needed information; official use removed the room; the requested duration did not fit; or the organiser chose another time. These possibilities have different governance meanings. None requires disclosure of confidential correspondence, but a neutral disposition code would stop absence from being invented as rejection.

Confirmed meetings need similar care. The public record should distinguish requested time from assigned time, chosen capacity from available capacity, and a conflict declared by the organiser from a conflict inferred after the event. If a meeting is renamed or moved, the correction history should remain. A later BoF or draft should be linked by date and authority, without rewriting the side meeting as an official precursor that was already approved.

This matters for retrospective research. Years later, a standards historian may ask when a problem became visible. A vendor may cite an early room as evidence that its approach had community backing. A policy advocate may count calendar entries to claim momentum. A sceptic may treat the lack of a slot as rejection. A thin allocation history would allow all four readers to see the same bounded fact: the meeting obtained this resource under this rule, and nothing more.

A public allocation receipt

Daniel Kade's proposal is a compact, privacy-safe receipt attached to each request. It is not current IETF policy and it is not a call for a merit panel. Its purpose is to make the administrative decision legible while preventing it from travelling as technical authority.

The receipt would begin with identity at the meeting level: a stable request identifier, requester-provided title, brief description, named hosts already intended for publication, relevant IETF areas and submission timestamp or coarse queue position. If exact timestamps create gaming or privacy concerns, a signed sequence or daily band can still prove order without exposing more than necessary.

It would then record the scarce resource: requested duration, acceptable alternatives, requested room, assigned room and capacity, requested and assigned block, and the availability version of the calendar. A list of organiser-declared official-agenda conflicts could be published as session identifiers, not as judgements about which work deserves precedence.

The disposition would use neutral states: confirmed, confirmed with alternative, withdrawn, information requested, unavailable, superseded or cancelled. The reason code should remain operational—capacity, block unavailable, room reclaimed for official use, incomplete request—not a technical grade. Corrections should append rather than overwrite.

Privacy and capture belong in separate fields: whether attendance data was collected; whether it was optional; whether any public figure is exact, banded or unavailable; whether recording consent was obtained; whether a recording link is public, restricted or absent. No field should invite a list of participant names merely to make the meeting look important.

Finally, the receipt would carry an explicit status line: Public side meeting — unofficial — not on the formal IETF agenda — no process standing conferred by allocation. If a later Internet-Draft, BoF, proposed charter or WG appears, the receipt can point forward to that independent record with its date and approving actor. The link documents history. It does not backdate authority.

Such a receipt would also make aggregate planning possible. The IETF could publish, per meeting, requests by duration band, confirmations, alternative placements, unavailable requests, room-hours, conflict categories and remote-participation availability. Those aggregates would help the IESG and meeting team decide whether two rooms remain sufficient, whether opening rules need adjustment or whether clearer discovery reduces conflicts. No technical topic needs to be ranked and no attendee needs to be exposed.

Preserve the queue by naming its limit

There are plausible alternatives to first-come scheduling, and each carries a cost. A lottery treats arrival time as irrelevant but makes planning less predictable. Rotating allocations can broaden access but requires a stable applicant identity and history. A merit panel may reduce low-value use but quietly turns administrators into content gatekeepers. Larger capacity or more rooms reduces scarcity but costs money and venue flexibility. An overflow-only remote model expands reach while changing the character of the meeting.

The evidence reviewed here does not establish which alternative is best. The IETF 126 survey demonstrates dissatisfaction with conflicts and space, not the superiority of a replacement. The safest immediate reform is semantic and evidentiary: retain a simple queue, disclose its actual states, and make clear what confirmation cannot mean.

That limit strengthens, rather than diminishes, side meetings. An unofficial room can host unfinished ideas without demanding the ceremony of formal work. It can expose a proposal to criticism before institutional machinery gathers around it. It can connect people who would never form a Working Group. It can also end without failure. Not every valuable conversation needs a charter.

The mistake is to make the room carry two incompatible burdens: informal openness at the beginning and institutional endorsement in retrospect. The IETF already supplies the correct sentence—unofficial, outside the formal agenda. A receipt would keep that sentence joined to the calendar evidence people actually see.

Evidence limits

This analysis uses the current IETF side-meeting policy page, the IETF 126 post-meeting survey summary, the Note Well and privacy statement, and RFCs governing administrative scope, BoFs, working-group formation and rough consensus. No complete submitted-request ledger, rejected-request log, wait list, room-utilisation dataset or participant-level survey data was available. The article does not count dynamic calendar entries, equate 42 survey recipients with 42 meetings, infer a displaced topic, allege favouritism or claim that any standard changed because of a conflict.

The allocation receipt is Daniel Kade's governance design, not an existing IETF obligation.

Sources

  1. IETF — Side meetings and private meetings
  2. IETF 126 post-meeting survey
  3. IETF 126 Vienna
  4. IETF Note Well
  5. IETF/IRTF/IAB Privacy Statement
  6. RFC 2418 — IETF Working Group Guidelines and Procedures
  7. RFC 5434 — Considerations for Having a Successful BoF Session
  8. RFC 7282 — On Consensus and Humming in the IETF
  9. RFC 8711 — Structure of the IETF Administrative Support Activity 2.0
  10. RFC 3935 — A Mission Statement for the IETF
  11. IETF side-meeting scheduler