Summary

  • The IETF 125 experiment connected a privately organized Tokyo hub to three simultaneous Remote Rooms. The August report says approximately 30 people participated; an April Executive Director report said approximately 50 were onsite. The official sources do not reconcile those figures.
  • The hub was not an official IETF venue. Its organizer chose participants and sessions, while every participant registered and joined Meetecho under an individual identity. A special shared room connection nevertheless made the group more institutionally visible than an ordinary remote attendee.
  • Reported satisfaction is encouraging but incomplete as evaluation evidence: the consultation gives percentages without question-level respondent counts, response rates, displayed denominators or the survey instrument.
  • Future support should treat a hub as a thin participation endpoint, never a delegation, constituency, vote or endorsement. Daniel Kade proposes a privacy-bounded receipt covering selection, costs, interface behavior, survey denominators, incidents and closure.

The room that looked more official than it was

At an IETF plenary, a video tile is not merely a picture. It is an interface to the meeting’s attention. A solitary remote participant normally appears as one named person among other named people. The Tokyo Remote Room appeared collectively, through a special connection designed for a room. According to feedback summarized in the second consultation report, that presentation could look like an official overflow room and could appear to give its participants higher standing than people joining remotely on their own.

Nothing in the report shows that the room changed a consensus decision. It does not show viewpoint discrimination, coordination as a voting bloc or improper conduct by the organizer or participants. The concern is subtler and more important: an administrative interface can imply institutional status that the underlying rules never granted. Repetition can then make the implication feel normal before anyone has decided what the room is.

The distinction begins with the experiment’s own description. A Remote Hub is the physical location of one or more Remote Rooms. The Tokyo hub was privately run and was not an official IETF-hosted venue. The local organizer controlled the premises, chose who could attend and selected which sessions the rooms would carry. Participants still registered for IETF 125 individually and used their own Meetecho identities. Shared audio and video came through a special room connection, but technical aggregation did not merge the people behind it into one standards actor.

That architecture contains two valid things at once. The organizer has a legitimate property and security boundary. A private office cannot be treated as an open conference center merely because it hosts an experiment associated with an open process. The IETF, meanwhile, has an open participation commitment. A person who is not invited into the private hub must retain the ordinary individual remote route, with the interactivity promised by the IETF’s meeting policy. The private door can remain private only if it is not mistaken for the door to the standards process itself.

What the Tokyo experiment actually tested

The second consultation follows an experiment conducted during IETF 125 in Shenzhen in March 2026. Three expressions of interest were submitted. Two were regarded as unsuitable and one Tokyo hub was approved. The hub operated three Remote Rooms at the same time. Participants chose sessions in advance by voting after the preliminary agenda was available, and some used laptops to follow sessions other than the one playing in their room.

The August report describes approximately 30 participants. An April public report from the Executive Director described approximately 50 people onsite at Google’s Tokyo office. These may reflect different counting points, attendance periods or report contexts, but the sources do not say. A credible evaluation preserves both numbers and the gap between them. Quietly selecting one would turn uncertainty into false precision.

The technical result was useful but not frictionless. Playback and room screens worked. A full test could not be completed because access to the facility was difficult, and room-wide microphones were not available. Speakers had to walk to the web-camera microphone. That detail matters. A hub is valuable partly because it lets a participant enter a conversation without managing every remote tool alone. If speaking requires a visible journey to a single device, the room introduces its own queue and hierarchy of attention.

Costs were also divided across institutional boundaries. The IETF absorbed the program development, Meetecho development, testing, setup and its operational experiment costs, with no extra hub fee. The local organizer paid for security, signage, badges, meeting rooms, audio-visual equipment, food and personnel. The report says local costs were significantly higher than expected because admitting people from outside the company required extra security. An earlier proposal had estimated IETF support at USD 1,500 to USD 3,000 per room and suggested that four to six rooms per meeting might be a practical initial limit.

That estimate is not a statement of the final Tokyo cost.

The trial therefore tested more than video quality. It tested whether shared physical presence, time-zone proximity, multiple parallel rooms and informal conversation could be restored without creating a second official venue. It tested how much public support should flow into a privately selected site. It tested whether the meeting interface could distinguish a room as an access facility while continuing to recognize every technical contribution as the act of an individual.

Encouraging percentages need denominators

The participant feedback summarized in the August report is strong enough to justify attention. It says 95% of surveyed hub participants would make the same attendance choice again. Another 95% would probably or definitely use a hub at a future meeting if they were not attending onsite for reasons other than budget. In the reported counterfactual, 11% would otherwise have attended Shenzhen, 22% would not have registered or attended, and 63% would have participated remotely. On productivity, 53% found the hub somewhat less productive than onsite participation, while 42% judged it about as productive or more productive.

Those figures describe the answers reported; they do not disclose the size and shape of the evidence behind every question. The report does not place a question-level respondent count beside the percentages, state a response rate, reproduce the exact instrument or display denominators and missing responses. The unexplained remainder in any percentage set must not be reverse-engineered into an answer category. Nor should the survey be presented as representative of all remote IETF participants.

This limitation does not make the results worthless. It changes the claim they can support. The trial shows that respondents found real value in time-zone alignment, multiple rooms, side conversations, social contact and presenting with other people physically present. It does not establish how common those preferences are across the wider community, whether the format changes who speaks, or whether a different admission design would produce the same experience.

Survey disclosure is especially important when scarce support is being allocated. Satisfaction among people selected for a novel, subsidized access arrangement is relevant, but it cannot answer the distributive question on its own: who did not enter, who never applied, and which costs would move if the design scaled? A future study should publish its instrument, question-level number of respondents, response rate, denominator, missing-answer treatment and aggregation method while protecting individual privacy.

Private admission and public process

Community concerns about a private hub should not be flattened into a demand that every private organizer open every door. Security checks, capacity, insurance, workplace policy and cost are real constraints. The Tokyo report says outside attendance increased security expense substantially. An organizer who bears that burden needs a defined admission boundary and must be able to say no when the premises cannot support more people.

But the IETF also needs to know what it is subsidizing and what that support signifies. If multiple organizers seek limited Meetecho development, testing or operational attention, selection cannot rest only in private correspondence. Aggregate reasons for approval and rejection, capacity, planned session coverage, public support and the identity of the local cost payer should be visible. Private vouching details and security records need not be disclosed. The objective is not forced admission; it is a legible allocation of scarce institutional support.

The first proposal anticipated that the organizer would have sole say over its community. That arrangement may be operationally unavoidable, but the word “community” can carry more authority than the arrangement deserves. A host-created guest list is a gathering. It is not proof of representation. It cannot speak for a city, company, country, region or technical interest unless a separate process grants and defines that mandate.

The ordinary remote route is the constitutional safety valve. RFC 9501 requires a free remote participation option and equal interactivity for paid and fee-waived remote participants; it also protects the confidentiality of fee-waiver status. It does not require the IETF to provide a free physical hub. A supported room may offer social and ergonomic advantages, but no chair queue, chat channel, document repository or decision path should become exclusive to it. Otherwise a convenience at a private site becomes a tier of participation.

Individuals, not rooms

RFC 3935 states the IETF’s mission in terms of an open process and identifies individuals—not organizations, companies, governments or interest groups—as the fundamental unit of participation. That principle is particularly useful here because it does not deny collective life. People will sit together, compare notes, share equipment and influence one another. The rule says where formal agency returns: the person who speaks, authors, objects, hums, appeals or accepts responsibility.

RFC 7282 adds that rough consensus is not head counting. A room of thirty or fifty people does not become thirty extra votes when it appears on screen, and it does not become one super-participant because it has a shared microphone. Chairs still evaluate the substance and strength of objections through the meeting’s ordinary process. The interface should help them see individual interventions, not create a visual shorthand that implies a corporate position.

Administrative power has a separate boundary. RFC 8711 gives the IETF Administration LLC responsibility for operational support, meetings, finance and related transparency. That authority is sufficient to fund an experiment, contract for technical work, decide how support is allocated and consult the community. It does not give the LLC authority to define the technical consensus of an IETF working group. The room operator controls premises; the LLC controls administrative support; Meetecho carries identities and media; chairs manage sessions; individuals make standards contributions. No layer should borrow the mandate of another.

This is why accurate labeling matters. “Private Remote Hub organized by X” describes an access endpoint and its controller. “IETF Tokyo room” can sound like an official branch of the meeting. A collective video label should not substitute for participant names in a queue. When a person speaks from the room, the record should carry that person’s IETF identity. The room may be the network path; it is not the author of the contribution.

A participation endpoint receipt

Daniel Kade’s proposal is to continue only with a participation-endpoint boundary and a compact public receipt. This is analysis, not adopted IETF policy. The receipt would let the community verify what support did without turning the LLC into a regulator of private premises or exposing confidential security and participation information.

Before a meeting, the receipt should state the number of applications, the published selection criteria, aggregate approval and rejection reasons, room capacity, organizer, admission model, intended session coverage, IETF support categories, estimated institutional cost and local cost payer. If the capacity or session plan changes, the revision should remain visible.

During the meeting, the interface should identify the site as a private Remote Hub, not an official overflow venue. It should preserve named individual participation in the speaking queue and chat. The operational record should note rooms active, sessions carried, major technical failures, accessibility constraints, chair interventions and any safety restriction that changed access. It need not publish private attendee vetting or the content of confidential complaints.

Afterward, the receipt should add actual support cost by category, the survey instrument and denominators, incident disposition, evaluation findings and the decision to continue, change or close the model. A closure entry is important. Experiments otherwise acquire permanence through calendar repetition: the room appears again, the label becomes familiar, and a temporary exception turns into an institution without a decision point.

The receipt is deliberately thin. It does not establish a new membership body, certify the organizer as representative, reveal fee-waiver status, force a private host to admit a person, or give the LLC power over standards judgment. It carries identities, costs, interface facts and decision history across the administrative boundary while leaving each principal’s authority where it belongs.

The decision due after the second consultation

The consultation asks for feedback by 27 September 2026. At the observation date, there is no adopted future Remote Rooms policy. The correct choice is not between declaring the experiment a success and abandoning shared remote participation. It is to separate four questions that the Tokyo experience brought together.

First, did a group setting improve access for people who would otherwise join alone or not attend? The reported feedback suggests it did for some respondents. Second, did the technology perform reliably enough to justify its support cost? Screens and playback worked, but the incomplete test and microphone constraint show that the operational answer is not yet complete. Third, was scarce support allocated through a process the community can evaluate? The existence of three expressions of interest and two unsuitable proposals makes selection evidence relevant.

Fourth, did the visual and institutional design preserve the individual as the standards actor? Feedback about an official-looking plenary presence shows that this boundary needs deliberate design.

A future trial can answer these questions without burdening participants with institutional theory. Keep registration and Meetecho identity individual. Keep the free ordinary remote path fully interactive. Label the site and organizer precisely. Publish the bounded receipt. Give chairs a clear way to distinguish a room-wide technical issue from an individual intervention. Then measure whether the hub expands useful participation, merely relocates existing remote participants, or unintentionally creates a privileged interface.

The most promising feature of the experiment is also the easiest to overread. People benefited from being together. That is evidence for shared presence, not evidence that the room became a constituency. The IETF can carry the access without carrying the implied mandate.

Evidence limits

This analysis relies on the second consultation report, public announcements, the April Executive Director report, IETF meeting guidance and published RFCs. It does not have the underlying survey data, application records, cost ledger, participant list, private feedback or incident log. It therefore cannot assess individual admission decisions, reconcile the approximately 30 and approximately 50 attendance reports, calculate response rates or determine whether the experiment changed any consensus outcome.

The sources record both participant benefits and community concerns. Neither set should be treated as a representative vote. The consultation remains open, its future design may change, and cost estimates in the first proposal are not final Tokyo costs. The receipt proposed here is Daniel Kade’s governance recommendation for future experiments, not a description of an IETF decision already made.

Sources

  1. Second Consultation on Remote Rooms for IETF Meetings
  2. Announcement of the second Remote Rooms consultation
  3. Initial proposal for Remote Rooms at IETF 125
  4. Public discussion of Remote Rooms on admin-discuss
  5. IETF 125 Remote Rooms experiment update
  6. IETF Executive Director public report, 8 April 2026
  7. Meetecho guidance for chairs
  8. RFC 3935: A Mission Statement for the IETF
  9. RFC 9501: The IETF Meeting Venue Requirements Review
  10. RFC 8711: Structure of the IETF Administrative Support Activity, Version 2.0
  11. RFC 7282: On Consensus and Humming in the IETF
  12. IETF LLC statement on remote meeting participation