IETF Community Hubs

The IETF needs and wants to become more effective at outreach and growth of active participants, timely in developing needed technology, and maintain expertise in broad knowledge and review of Internet technologies. IETF Community Hubs are one experimental approach that may assist in these goals. Currently, there is one active IETF Community Hub in the Boston, Massachusetts area; it has been meeting periodically since May 2016. For a local group to be effective, it must either provide value to its participants to retain them or be able to do excellent outreach and bring those newcomers to actively participate in the IETF, but ideally both. When doing outreach, having active IETFers involved to provide connections to the IETF community and mentoring on how the IETF works and how to be effective in the IETF is critical. People come to the IETF to get technical work done and solve problems, usually relevant to their day-job’s organization. Some also come to learn and communicate back to their organizations about technology for internal use and implementation or deployment. An effective local group needs to consider how to support interested individuals in these goals.

In preparation for IETF 95, ISOC starting encouraging and running Remote Hubs , where there were local meetings centered around remote participation to a Working Group meeting during a plenary IETF meeting. Sometimes, such meetings might have a social aspect or IETF-related or introductory talks. The appropriate terminology to use is still under discussion. For clarity, in this document, the following is used. This is a geographically-focused group that holds periodic meetings and activities related to the IETF locally. This is a local meeting that is centered around remote participation to a Working Group meeting during a plenary IETF meeting. As Remote Hubs are held periodically in the same geography, there may develop an associated ICH. Any type of meeting held by an ICH - this could include a Remote Hub.

The benefits for existing IETFers can be social, educational, and assist in getting IETF work done. First, attending a Hub meeting gives a chance to see other IETFers in an environment that isn’t under intense time pressure, as many plenary IETF meetings are. A social Hub meeting (e.g. lunch, dinner, party, etc.) is a chance to catch up with friends and colleagues and chat about what interesting work they and mutual acquaintances are working on. This provides an opportunity for individual focused discussion about on-going work and an environment where folks can be introduced to others who may be interested in or knowledgeable about their work. For attendees, a technical talks session provides an opportunity to learn a little about technology or problems in the broad variety that is of interest to the IETF community. It is a chance to discuss how that work is connected to other IETF work, to find cross-area concerns that need handling before IETF Last Call when they can be better addressed, and to provide suggestions as to whom in the IETF community might be interested so that the work can get better review. For presenters, it is a low energy way of getting immediate feedback and sparking interest in the document. For newer IETFers, it can provide guidance on common considerations, introductions to others who might help, and advice on how to navigate Working Group discussions. At a minimum, going to an IETF Community Hub (ICH) meeting is a reminder of the IETF work that an IETFer needs to get done and can be a spur to make progress - whether to discuss it at the meeting or simply as a reminder that the IETF community keeps working between plenary meetings. It also provides that human element of seeing and feeling that other people are interested in discussing one’s work - which is frequently its own encouragement. One of the tricks to getting work done well in the IETF is finding the small group of people who deeply care about that work and having a complex technical conversation to resolve all the considerations. Finding that group of people frequently depends on the social network and an ICH offers the opportunity to grow more and thicker connections between those who attend, which can then help with introductions and recommendations on whom to talk to about work and what drafts would be useful to review.

While we all participate as individuals in the IETF, it frequently takes more than an individual’s interest to allow a person to regularly attend plenary IETF meetings. Effective participation, such as reviewing drafts and considering serious implementation or deployment, also frequently benefits from one’s day-job organization being highly supportive. If a person isn’t familiar with the IETF or how to get involved or why other individuals and organizations find it worthwhile, it is much harder to make a case for time or travel funding. A ICH can provide a mechanism for interested individuals to learn a bit more what the IETF is like and start determining how they might be effective. It is also very useful for implementers, operators, and others to be able to participate effectively in a low cost and low effort fashion. Obviously, working groups, with their associated mailing lists, are the mechanism by which work is done - but being able to meet other active IETFers and get advice and introductions can be quite helpful in facilitating progress. ICHs also provide a potential mechanism for sharing knowledge and perspectives with other interested local communities, such as Network Operator Groups and research communities.

A plenary IETF meeting brings together many in the IETF community and there are formal and informal activities to facilitate mingling, communication, and progress. Significant work has been done on and continues to be improved for remote participation in the formal Working Group meetings. Holding a Remote Hub session is also a way that an ICH can encourage local discussion or socialization around participating in the WG meetings. A significant benefit of a plenary IETF meeting is the informal side-meetings and hallway conversations that happen. This is where there can be time to have complex technical discussions and work out compromises and solutions that allow drafts to progress. This can also be where one can explain the motivations and context and overview of a draft to someone who may be interested and able to provide suggestions. Obviously, it is challenging to duplicate the serendipity and interactions in an ICH are primarily with those who happen to be geographically co-located, but this type of interactions can be encouraged via meeting formats. Having opportunities to interact in person takes advantage of some commonalities of human interactions that are important to consider. First, for those fluent in the relevant language, a spoken conversation can have more nuance, significantly higher bandwidth and interactivity than an email discussion. Second, even a brief in-person meeting builds a social connection and broadens appreciation of the others’ character, interests, and motivations. Complex discussion and negotiation occurs more smoothly and rapidly between those who have met in person even once.

Participation in even very active Working Groups is seldom more than a couple hundred IETFers. While there are some geographical localities that have comparatively dense participation in the IETF, it is not likely that more than a handful of participants will be geographically close. There may be more people interested in following a WG; they may occasionally review documents, may be implementing, and/or may be deploying or operating networks using the WG’s technology. The existence of such people in a locality is highly dependent upon the WG and the active companies and universities in the area. It could be useful to focus on particular relevant WGs for remote hubs with associated technical discussion if it seems there are a number of local people interested. Obviously, discussion and agreements about working group drafts happen on the WG mailing lists.

Some of the benefit of having ICH meetings is to allow those local to meet and interact, which facilitates mentoring and discussions. If all the meetings are during plenary IETF meeting, then those IETFers that do attend in person will miss the ICH meetings and not be able to assist as easily in mentoring or facilitating discussions.

The Boston IETF Community Hub has held social meetings, technical talks meetings, and remote hubs. Meetings have been at companies that have volunteered conference rooms or at restaurants for social get-togethers.

The Boston Hub started based on a request for a mailing list with a desire for a local social meeting. The concept of community hubs was sparked by ISOC’s work with Remote Hubs in Latin and South America. Asking for and doing introductions on the ietf-hub-boston mailing list definitely helped with realizing whom else was in the area and something of their interests.

It has proved extremely useful to have multiple coordinators for discussing what to do and trading off the work of organizing a meeting. There are three coordinators. The main restriction on number is coordinating and making sure that responsibilities are clear. So far, different coordinators have been responsible for different meetings.

The greater Boston area pulls from a couple hour radius and has to trade-off considerations in terms of transportation, parking, traffic, and convenience for different sets of people. . The locations have ranged from Akamai in Kendall Square in Cambridge, to a restaurant by the Alewife T station, to 128 Technology in Burlington to Juniper Networks in Westford. It is likely that meeting locations will continue to be varied so that inconvenience is balanced.

These have been a retirement party, a dinner, a lunch, and a planned meet at a pub with dinner. They’ve allowed small and group conversation. Attendance varies between 10 and about 20.

There have been two meetings and two more are planned. To find talks, volunteers were asked from on the ietf-hub-boston mailing list. Most talks are targeted at 10-15 minutes with another 10-15 minutes of discussion. The first meeting was 2 hours and the second was 3. The first meeting had one 45 minute topic because there was no way to cover the material more quickly; the depth seemed to be welcomed and appreciated. Topics for these meetings ranged widely and included information-centric networking (ICN), NTP Security, Banana BoF overview, Happy Earballs - Coping with Dual-Stack Connectivity Issues in SIP, Homenet Naming and DNSSD. For the meeting in February 2017, the talks will be focused on privacy and security; RSVPs for that meeting are around 35. In April, the expectation is to have a mixture of topics. These meetings attracted between 15-20 people - mostly experienced IETFers with a few new folks. After the meeting, a slightly smaller group has gone out to dinner. Both of the meetings ran over time by about 30 minutes and there was energetic discussion during them. The venue used (128 Technology volunteered space) had an option for informal gathering afterwards, but because the meeting ran long both times, folks just went to dinner.

For IETF 95 and IETF 96, there have been Remote Hubs at Juniper Networks in Westford. The Working Groups covered have been focused in the Routing Area, because there are a number of interested developers there. The Remote Hubs were open and did have a couple non-Juniper attendees. In addition, each time, one evening there was a social dinner. No Remote Hubs were tried for IETF 97 due to the time difference. There are plans to hold another Remote Hub during IETF 98. Feedback about Remote Hubs on ietf-hub-boston has indicated that while there are many WGs not covered, there aren’t even small groups of folks interested in particular other working groups; the spread is too large. Interest in driving to another location to remotely participate in a WG was quite limited.

Limited publicity has been done and this is an area that could use significant improvement and suggestions. One effort that was started in time for the February 21 meeting is identifying a list of active Internet-Draft authors in the area and notifying them about the meeting and the ietf-hub-boston@ietf.org mailing list.

The mailing list has been used to ask for talks, do introductions, and discuss meeting logistics. Doodle polls have been used for RSVPs to the meetings. It would be very useful to have a common wiki to provide a reference for various publicity efforts to local groups and to record the previous and future meetings. This would also be potentially useful for IETFers traveling to the area, since they could then know if there is a Hub meeting happening. There is some investigation of using MeetUp to help with publicity and coordination. It would be useful to use a common calendar so meetings are on it in advance and others traveling to the area could see when a meeting was going to happen.

If this experiment seems useful, additional IETF Community Hubs may be started. What is most useful depends in part on the local community of IETFers and others interested. How coordinators can volunteer, step down, and so on is not yet clear. Ideas on interactions into the IETF organization - if such is needed - still need to be discussed. [a]there’s something amusing about using gdocs for markdown.

I would like to thank Christian O’Flaherty, Nalini Elkins, Alvaro Retana, Rich Salz, and Dale Worley for the discussions and/or review.