Skip to main content

Filter by topic and date

Filter by topic and date

IETF Diversity Update

  • Kathleen MoriartySecurity Area Director
  • Jari ArkkoIETF Chair

4 Dec 2015

It’s been a while since we’ve had a diversity related update and with the approval of the Anti-Harassment BCP and publication of the Independent Stream Editor (ISE) document, RFC7704 it seems timely.

IETF Diversity Graph
Charts from Jari Arkko, IETF Chair

The anti-harassment BCP [1] helps to establish a code of conduct supported in the IESG statement on the same topic from 2013. RFC7704 [2] is an opinion piece from the editors citing issues from the 2011-2012 time period that while still surface on occasion, have seen improvement due to many efforts from IETF participants.

While the IETF has diversity issues, and like any other organization we will have to work on this continuously. In 2012, when these behavior and diversity issues were glaringly apparent to the IETF, the chair, Jari Arkko worked with others to establish a “Diversity Design Team”, of which I was appointed as one of the co-chairs with Suresh Krishnan. The final readout from the Diversity Design Team was given at the IETF 87 Plenary in July 2013 [3], switching the focus to inclusion from diversity. The Internet Society was already working on important programs to increase regional diversity, such as the Fellows and Policy programs, which bring new people from various regions of the world to meetings to introduce them to the IETF. Other efforts, such as the Mentoring Program were established by individual participants in 2013, with Alissa Cooper and Brian Haberman leading the effort with other individuals on the team [6][5]. The mentoring program assists newcomers at their first IETF meeting pairing them with volunteer mentors that guide them through their first IETF and helping them negotiate the new environment as well as procedures. The IETF culture and complex procedures are tough to negotiate and this effort is key toward improving retention of newcomers. The IETF does quite a bit of work from the bottom up, so if a need for something is seen, individuals are welcome and encouraged to drive them as was shown by the mentoring program. The 2013 nominating committee (NomCom), led by Allison Mankin, took it upon themselves to first raise awareness on implicit bias amongst committee members in self assessments, as well as taking steps to have those nominated for IETF leadership positions provide ‘blind’ questionnaire responses as not to identify themselves in the initial selection process. These techniques were supported by research to improve diversity and in from their own research and awareness raised by the Diversity Design Team. The 2013 NomCom appointed 3 women to the IESG and 1 to the IAB. The 2014 NomCom added one more woman to each of those leadership groups as well, matching (at least for the IESG) a prior high point of 4/15 women in the IESG.

On a personal note, I could be considered as part of the 2012 Systers ‘experiment’ mentioned in RFC7704. I was not appointed in that cycle as a Security Area Director (although am currently serving in that role), so I do count in the numbers cited. I bring this up as a few women in the nominating cycle for 2012, like myself, fully expected that the nominating cycle would be a dry run for the following year. While that may sound odd, if all things are equal with two candidates, the NomCom will select the incumbent for a second term. This is a result of the complexities of the position and the amount of time it takes to come up to speed fully in the responsibilities for the role. In the 2012 cycle, Stephen Farrell was an incumbent running for his second term. Stephen and his co-AD at the time, Sean Turner encouraged me to accept their nomination as they wanted the NomCom to have reasonable candidates to select from and they also wanted me to consider a possible appointment the following year when there was no incumbent. Several very qualified IETF participants accepted nominations the following year, 2013. Since I was the Global Lead Security Architect at EMC, this would take discussions with management to determine if there was support for me taking on this time consuming appointment and stepping away from a very important role at EMC. This is not uncommon for many candidates as they tend to be in high-level positions in their organizations. For me, this was quite helpful for the long term process. While there may have been a bias in the 2012 NomCom as cited in RFC7704, at least a couple of the qualified females had no expectation of being appointed that year. Another woman accepted a nomination for an Area Director role just in case the incumbent was selected for a more senior role and the NomCom needed a reasonable nominee/volunteer to appoint. She was also appointed by a subsequent NomCom as she is also well qualified for the role of an Area Director and held senior level positions in her supporting organization.

The IETF leadership has been very supportive of fostering an inclusive environment, which from studies is one of the most critical factors to improving culture and working towards a more diverse environment. In addition to supporting a number of programs, an anti-harassment statement was issued by the IESG in November 2013 [4] and was followed by a consensus draft, on it’s way to final publication as a Best Current Practices RFC [1]. Research has also demonstrated that programs are the most effective way to make progress in an area that will require continued focus for the IETF. We are not perfect but have come a long way in a few years. The IETF will need continued support from the Chairs, IESG, and IAB to foster continued improvements. As such, this consideration is part of the NomCom evaluation process now.

Unfortunately, the problems cited in RFC7704 are not unique to the IETF, so there was plenty of research for the Diversity Design Team to draw from. The final readout from the Diversity Design Team was given at a recorded IETF87 plenary [8] with slides available [3], where the focus was changed to one of promoting an inclusive environment. While the male/female ratios may have sparked the IETF conversations, we also needed to consider regional diversity and ways to develop a pipeline of potential IETF leadership candidates along all measures of diversity. This goal is supported by research that shows the benefits of diverse groups toward improved outcomes and higher collective intelligence of diverse groups versus homogeneous groups. Working Group chairs and Area Directors support these goals by providing training opportunities to individuals and considering diversity when selections are made. If you take the time to watch the recording, you’ll notice an interaction at the end that might be more typical of the cited RFC7704 behavior. While on the surface this may look bad, what followed the plenary demonstrated progress in that apologies and an additional acknowledgement of the problems we face as a community were the result. What this boils down to is that the IETF is not perfect, but we have moved to an environment where bad behavior is called out more readily and have options now such as working with an ombudsmen to have neutral arbitrators, thanks to the work in the anti-harassment BCP [1].

For my own working groups, I do feel they are welcoming environments for all to participate both on the lists and in the room. When an occasional comment that is not appropriate occurs (very rare), it’s been called out immediately and this is a new norm where the behavior is corrected on the spot. It’s progress. If I or other ADs are missing behaviors we should be catching, please let us know. This is a community effort.

[1] https://datatracker.ietf.org/doc/draft-farrresnickel-harassment/
[2] https://datatracker.ietf.org/doc/rfc7704/
[3] http://www.ietf.org/proceedings/87/slides/slides-87-iesg-opsplenary-8.pdf
[4] https://www.ietf.org/proceedings/87/slides/slides-87-iesg-opsplenary-5.pdf
[5] https://www.ietf.org/proceedings/88/slides/slides-88-iesg-opsplenary-2.pdf
[6] http://www.ietf.org//iesg/statement/ietf-anti-harassment-policy.html
[7] http://recordings.conf.meetecho.com/Recordings/watch.jsp?recording=IETF87_ADMIN_PLENARY&chapter=part_1
[8] http://recordings.conf.meetecho.com/Recordings/watch.jsp?recording=IETF87_ADMIN_PLENARY&chapter=part_7


Share this page