Not Being There


Date: May 7, 2007

line break image

Within the IETF, as much work as possible happens on its various mailing lists, so that attendance at IETF meetings is not an essential part of being an effective contributor to the work of the IETF.

Well, that’s the objective, and, in general, that’s been the case: critical decisions involving the milestones of the progress of IETF documents and the procedures we use are proposed, debated, and, as much as possible, concluded through the use of these mailing lists. But face-to-face meetings are still important. As one IETF attendee pointed out (on an IETF mailing list, by the way!) after IETF 68: “It’s hard to be consistently effective in the IETF without attending the face-to-face meetings. A lot happens during IETF week.”

But what if you just can’t be there?

While I cannot claim to have attended all 68 IETF meetings, I have been able to attend most of the recent ones since the mid ’90s, and I’ve found them to be very useful not only as a hard deadline for document editing but also as an opportunity to exchange ideas with others who share a common interest. However, I was unable to make it to IETF 68 in Prague, so I was using the IETF meeting’s facilities for remote participation for the first time in many years.

The IETF has supported remote participation in its meetings for many years. At IETF 23, in March 1992, the IETF was experimenting in multicasting the meetings over the Internet. From the proceedings of this meeting I found this:

Packet Audio Experiment
Thanks to the organizing efforts of Steve Casner (ISI) and Steve Deering (Xerox), and the behind-the-scenes efforts of Van Jacobson and others, we had a very exciting demonstration of the DARPA packet audio experiment in San Diego. These stalwart experimentors set up IP multicast tunnels through the NSFnet backbone, and broadcast the Plenary proceedings of the IETF to multiple sites across the Internet. Sweden, UK, and Australia all took part in this exercise.We even had a brief 2-way communication, in which several remote listeners spoke to the assembled Plenary. The quality was not perfect. Some sites had much better reception than others. For some sites, the broadcast was apparently unintelligible at times. Still, for all its imperfections, this demonstration was an impressive promise of services to come. Some of us speculated that this new technology might play an important role in helping to deal with our future growth. For example, if the Proceedings of the Plenary (and perhaps even certain Working Groups) could be made available as a reliable Internet service, especially if it provided a robust 2-way interaction, it might give prospective attendees an alternative way to participate, rather than flying to attend the meeting in person.

The “Information Age” could truly be at hand! One of the traditional strengths of the Internet community is that we use the technology we are developing to assist that very development. This exciting packet audio demonstration offers the promise of adding to that tradition. We hope to see more packet audio, and perhaps even packet video, experiments at the IETF in the future.

So far, we haven’t reached the level of support that creates an immersive telepresence for remote participants, but we have managed to make some progress with practical measures to support remote participation.

Multicast audio feeds, which started in 1992, continued for some years, to be replaced by a two-channel video and audio multicast feed by the late ’90s. Beginning with IETF 63 in 2005, the streaming media moved to an eight-channel audio feed, also moving away from multicast to a unicast audio-streaming service. This means that all IETF working group sessions, BoF sessions, and plenary sessions are now part of the streaming audio service.

In recent times, Jabber has started to extend its pervasive reach into IETF meeting rooms, and these days – in addition to using a scribe to take the minutes of each working group session – the working group chairs are asked to find a willing volunteer to act as a jabber scribe, noting the meeting in real time. This was taken one step further in the SIPPING working group at IETF 68, with a stenographer providing a full transcript of the session in the jabber room in real time. Not only does this make the jabber service really useful as both a real-time feed and a meeting record, but also it is invaluable for non-native English speakers, because often, the written transcript provides a means to readily resolve some of the uncertainties that are caused by the variety of accents, acronyms, unfamiliar use of terms, local dialects, and the speed of verbal delivery.

And working group chairs have become more aware of the need to publish both session agendas and the presentation packs to be presented in the session well before the scheduled time of the session, thereby giving the remote audience the opportunity to match the audio feed and the jabber log to the material being presented at the face-to-face meeting.

If you are familiar with the IETF format and familiar with the accents and colloquialisms of the usual contributors in your favourite working groups, then in terms of your being part of the audience, these tools are good enough to give you an excellent feel for what is happening at the face-to-face meeting. Indeed it probably matches the level of sensory input you have while being in the room with your head down making notes on your laptop. These days the Internet is clearly robust enough to support an excellent quality of audio streaming, and the diligence of working group participants to use the microphones in the room and announce their names before speaking is really helpful for remote listeners. The online presentations allow you to keep track of the progress of the presentation, and the experience is pretty much the equivalent of being there.

What is still somewhat frustrating is that the sense of being there is limited to being a member of the audience rather than a participant on the whole. Yes, you can attempt to ask questions into the jabber room, and – depending on the session and the state of the microphone queue in the room – you may be fortunate enough to have your question read out to the microphone and to have an answer provided. Simple questions can be posed-and answered-in this manner, but as an effective form of interaction with a dialogue between the remote participants and those in the room, this is not an ideal solution.

And then there’s the other important part of the IETF face-to-face meeting: face-to-face interactions throughout the week. No, it’s just not possible to participate remotely at the Social Event, which, I understand, was an especially notable event in Prague! And corridor conversations and of course the many fine lunches and dinners are not directly accessible either, when you’re sitting over a laptop in the middle of the night.

Yes, the work of the IETF is meant to happen on the mailing lists, and physically being there at IETF meetings is not intended to be an essential precondition for effective participation in the IETF. And we do try hard to actually make that the case. But the IETF is as much about “us” as a community of people with a common interest in Internet technology as it is about mailing lists and processes, and while it’s the unique and fascinating technical agenda that draws many of us into the IETF in the first place, it’s actually the rich social fabric and the strong, even tribal, sense of “us” as a community of people with common interests that keep many of us contributing to the IETF for far longer than we may have originally envisaged. And for that, while not being there from time to time is probably unavoidable, it is the being there that makes working in the IETF all the more valuable and enjoyable.

Remote Resources for IETF 68