Monthly Archives: December 2015

Year 2015 and Beyond

fireworks

With the year closing, I wanted to make a post highlighting some of the events and hot topics of the year. And say a few words about the challenges that lie ahead.

Lets start with technical and big-Internet affecting issues. When I talked with the steering group about the events of the year, these came up:

  • The publication of HTTP/2 in RFC 7540 [1]. This is the new protocol that supports web traffic in an efficient and secure manner, widely adopted in software and increasingly used in Internet [2,3,4].
  • Publication of the DNS privacy problem statement and subsequent work on potential solutions to address this problem [5,6].
  • More generally, eighteen months ago we made a promise that the IETF would understand the implications of pervasive surveillance on Internet technology [7]. We are starting to deliver on that promise, and as a result, are better equipped to look at improvements.
  • The IETF took on data modelling work for network management, mostly focused around YANG and various standards organisations and open source efforts that use these models [8,9].
  • We chartered new work to extend security protections to vulnerable parts of the real-time communications stack, such as the security work in PERC, STIR and the continuing work in RTCWEB WGs [10,11,12].
  • The IAB worked with operators to understand the implications of Internet traffic being more commonly encrypted [13].
  • We started supporting IEEE efforts on deterministic networking using IETF protocols for broader geographical coverage [14].

But there were also more internally oriented events for the IETF. For me the big thing was focusing more on open source and bringing back the running code aspect to the IETF. Our Hackathon events have now seen their first year, and grown to a successful ~100 person event. We are looking forward to the second year, and the next event will be April 2-3, just before IETF-95 in Buenos Aires [15].

We also re-organised the IETF areas, creating the new Applications and Real-time area (ART), and helping the steering group organise its work in a flexible manner on current topics [16].

We also saw development and increased usage of remote attendance facilities through Meetecho and other systems. Did you know that all 2015 IETF sessions are on YouTube [16]?

Here are some of the challenges that we saw coming up:

  • We need to continue the work on increasing the security of web and e-mail traffic. It will not be easy, and technology can only provide a part of the answers. But we must continue this work, as at least from my perspective the loss of privacy and personal control of information relating to a person is the most critical challenge facing the Internet today. It is also important to consider threats to privacy as a systemic problem, and not something only related to surveillance. The current Internet enables legitimate services to have a lot of privacy-sensitive information, and building ways to minimise exposure would be beneficial to both users and service providers in the long term.
  • The expanding Internet of Things applications, with their security, privacy, interoperability, and manageability issues is another major Internet future challenge. It is essential, for instance, that interoperable devices can be used to build systems around us, enabling competition and innovation.
  • We must start work on new tools that help operators to manage traffic in an all-encrypted world.
  • We need to continue extending management capabilities and security aspects for routing protocols.
  • The Internet transport protocols are evolving to match current day needs, with respect to security and efficiency. It is likely that a fairly large change will happen in this space, and proposals such as TCPINC or QUIC will change how we think about transport protocols [18,19].
  • We must accelerate the publication of the standard YANG data models, the challenge being the coordination of all these models.
  • We need to deliver on our promises to provide the privacy enhancements, real-time communication security tools, and many other topics that the working groups have been chartered to do.
  • We need to execute the IANA transition, finally. A plan for this transition has been produced by the IETF together with other Internet organisations [20].

What other challenges do we face in the Internet, and are there proposals that you would like to see taken forward to solve them? Let us know on ietf@ietf.org.

Inside the IETF, one of the key issues continues to be that we remain the most useful place for today’s Internet technologists to work with each other. I’m happy about our reach into more open source folks, our meetings and ISOC programs reaching out to different groups and different regions, but that is only the start. What can we do to make the IETF a better place for you to develop standards that you need?

With this, I want to thank everyone who has participated in IETF projects and wish you happy holidays. We have more work to do, but we should be happy about the things we’ve achieved in 2015. See you next year!

Jari Arkko, IETF Chair

IETF Diversity Update

Kathleen M. Moriarty, Security Area Director

Charts from Jari Arkko, IETF Chair

It’s been a while since we’ve had a diversity related update and with the approval of the Anti-Harassment BCP [1] and publication of the Independent Stream Editor (ISE) document, RFC7704 [2] it seems timely. The anti-harassment BCP helps to establish a code of conduct supported in the IESG statement on the same topic from 2013. RFC7704 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