## Background This is a proposal for an experiment to test a new feature called “Remote Rooms” and feedback is now sought from the community.
For several years, various organizations operated remote participation hubs for IETF meetings, allowing participants who had never been to an IETF meeting to meet together and remotely experience the meeting. While this was a very valuable initiative, the participants were largely observers due to the limitations of IETF remote participation at that time. In response to the COVID pandemic, the IETF has invested heavily in supporting remote participation in IETF meetings, and integrating remote and onsite participation. It is now possible to envisage a new form of remote hubs with a significantly improved experience. This new feature is tentatively called “Remote Rooms”. ## The intended experience If you have participated in a recent plenary session, you will have seen some participants who chose to join from the onsite overflow room rather than the main room. Those participants used the onsite Meetecho tool to join the queue and, when it came their time to speak, the audio and video feed switched to the overflow room seamlessly. The Remote Room experience is intended to be very close to the overflow room experience. Participants gather in a remote room with suitable Audio/Video (A/V) support; the organizer logs that room into Meetecho using a dedicated laptop and chooses the session to join; the participants all login to Meetecho (normally the onsite tool but they can use the Meetecho full client) using a special QR code just for that room and use Meetecho to join the queue, chat, etc.; and when a participant in a remote room is called to speak, the A/V feed switches to that from the remote room and the participant speaks using the shared A/V facilities in that room not their own laptop camera/microphone. The aim is that this is a seamless switchover where the technology is transparent, not a distraction, and not another complicated thing for session chairs to manage. Feedback is sought on this intended experience in all aspects. NOTE: In discussion with some potential organizers, we have identified an alternative, simpler experience that is described below and on which we are also interested in community views. ## Resource implications and fees Remote Rooms will incur new financial and staffing costs, including: * The development cost for adding this new feature to Meetecho, as this is a new feature unique to the IETF. * Managing the application process, which includes checking the plans for the remote room, the A/V specification of the room, and setting up the special codes and permissions. * The pre-flight testing to ensure that the remote rooms integrate correctly with the onsite technology on the weekend before the main meeting. The cost is currently estimated to be in the region of $1,500 to $3,000 per remote room. It should also be noted that these resource implications act as a natural limit on the number of remote rooms that can be supported for any one meeting. While the processes need testing it is likely that the maximum that can be realistically supported will be somewhere around 4-6 per meeting. For IETF 125 Shenzhen, the IETF LLC proposes to absorb these costs in order to test this feature, but for future meetings it would need to recover these costs rather than add to the already significant annual deficit incurred in running IETF Meetings. The options that have so far been identified for recovering these costs are: 1. Remote Room organizers pay a fee for this support. 2. Remote Room participants pay a higher fee than the normal remote participation fee, which is ineligible for a fee waiver, and the organizers pay nothing. 3. A combination of the two above. Feedback is sought on this whole area of costs and cost recovery, the options identified, and any other possible options. ## Terms and conditions Use of this feature will require some form of terms and conditions to be agreed to by the Remote Room organizer. The key points that might need to be included are: * All participants who use the remote room will need to be registered for the IETF meeting and the organizer of the remote room will need to ensure that this is the case. * The remote room organizer will choose who the “community" of intended room participants is and have the sole say on who can participate in that room. * This feature is intended to support participation in IETF meetings and the development of IETF technology, not the work of another standards organization or the development of non-IETF technologies. * The IETF cannot assume liability for anything that takes place in the room. * The feature cannot be commercialised. The mechanisms for a Remote Room organizer to commit to these terms and conditions might include: 1. A check box when applying for a Remote Room. 2. A short agreement signed when a Remote Room is approved. Feedback is sought both on these possible terms and conditions and the mechanism by which a Remote Room organizer commits to them. ## Alternative experience In discussions with people who work with universities, an alternative experience has been suggested that simplifies much of the above, but may not provide the full Remote Room experience that others have asked for. In this alternative experience, a feed of the IETF meeting is provided that can be shown on a large screen in a remote location, mirroring the main screen in the onsite session, but otherwise all participants at that location use their local devices for interaction. So if one of them wants to speak, they must mute the large screen and then speak using their laptop as would any normal remote participant. This alternative experience reduces the cost and complexity of the proposed Remote Rooms feature but also makes the chances of disruption from incorrect use of the technology more likely. Feedback is sought on this alternative experience and whether or not it should be the only feature provided in place of the full feature above. ## A special note about interim meetings The proposal above focuses on remote rooms during IETF meetings, but the same feature could be used for an interim meeting. If it were, then there would be a number of simplifications from the above model: * As the remote room would only be for one session, the session chairs could be responsible for agreeing to it and issuing the code/permissions for the remote room to join. * With no extra support costs, this could be free and several remote rooms could join at once. * Session chairs would need to manage some aspects of this when things go wrong. ## Providing feedback Please send feedback on this proposed experiment by 16 January 2026 either privately to the IETF LLC Board and myself at [email protected] or to the public administrative discussion list [email protected]. Note that IETF Executive Director Jay Daley is on leave until 25 January 2026 so feedback sent directly to him will not be incorporated. -Greg -- Greg Wood Senior Director, Communications and Operations IETF LLC [email protected] _______________________________________________ IETF-Announce mailing list -- [email protected] To unsubscribe send an email to [email protected]
