Periodic posts will highlight individuals who serve in IETF leadership roles, people who have recently begun working in the IETF, and organizations that make the work of the IETF possible. Each post aims to describe experiences working within or supporting the IETF. The first of these is by Alissa Cooper, current IETF ART Area Director, who will take on the IETF Chair position during IETF 98.
Alissa Cooper, IETF 96 at Intercontinental Hotel, Berlin, Germany.
I started participating in the IETF in 2008 and went to my first meeting at IETF 72 in Dublin. I was working at the non-profit Center for Democracy and Technology (CDT) in Washington, DC, where my role was to explore and articulate the technical implications of policy. I worked on a number of issues there, including online privacy.
In 2008, real-time applications were the focus of many of the consumer privacy issues of most interest to CDT. Initially, I focused on the Geopriv Working Group. I became a document author and then a co-chair of the group. It was a busy time in Geopriv – many tough battles had already been fought concerning the design of the technology, but finishing out the protocol suite required substantial effort. Over time the IETF grew into a larger portion of my job responsibilities because it was well aligned with the rest of the CDT work I was doing.
In 2011, I was appointed to the Internet Architecture Board and soon thereafter became the lead of the IAB’s Privacy Program. CDT was thrilled—they saw it as a huge honor that one of their own had been selected to serve in this capacity.
In 2013, I joined Cisco, and in 2014, I joined the Internet Engineering Steering Group as Applications and Real-Time area director. I’ve tried to do my area director work approximately half-time and my day job half-time. I’m leaving the post as I’ve been appointed IETF Chair beginning in March 2017—my new full-time role for the next two years.
Leadership in the IETF offers exposure to a broad swath of Internet technology that most of us otherwise wouldn’t be able to justify spending our time learning and influencing. This is particularly true on the IESG, but also on the IAB. It’s incredibly enriching and highly beneficial because you’re able to make connections between your day job and things going on across the whole industry.
IETF leadership also requires management skills of many kinds. You have to manage authors, your time, big community processes. It requires a lot of strategy and work in the background to achieve good outcomes. Many people do not realize the depth of the management education you get while serving in the IETF leadership.
Lastly, you get to (try to) promote your vision of what the future of the Internet should look like. Everybody might not agree with you, but serving in the leadership gives you a platform to steer and influence.
Cisco has been a big supporter of the IETF because it is deeply invested in the growth and stability of the Internet. Its customers like the idea that the products they buy from different vendors interoperate. Cisco enjoys having people in leadership positions dedicating a portion of their time to furthering interoperability and making sure that standards are keeping pace with other technological developments.
In recent years, some IETF participants have encountered difficulty in trying to convince their employers about the value of the time commitment associated with IETF leadership positions. But in reality it is possible to balance your day job with an IETF leadership role—you set the parameters for how you manage your time. Lots of positions require a half-time commitment or less.
Having a well-functioning IETF and an Internet that runs on secure, performant, interoperable standards should be pretty important to any large tech company at this point in history. If that model goes away, the options for how we replace it are all inferior. Hopefully the indirect benefits of supporting IETF leaders are obvious, but if not, current and past IETF leaders are always happy to explain the benefits. We have a big incentive to expand the population of people willing to take on leadership roles.
The Chicago IETF begins in a couple of days, and I wanted to point people to a few highlights from my perspective. Of course, with over hundred working groups, the IETF’s work program is quite diverse, and different people are interested in different topics. There is a lot that is particularly interesting for me:
New transport: I expect a lot of attention again on QUIC, the transport protocol designed to integrate functions from TCP and TLS. They are meeting Thursday at 09:00. They will use their meeting time to discuss the main protocol drafts, and issues such as details of the integration to HTTP. There will be a QUIC Tutorial on Sunday afternoon (15:00).
Coordinated Address Space Management: The CASM BOF will meet Monday 15:20 and discuss how organisations manage their address space and what possibly standardised tools may be useful in that.
Trusted Execution Environments: The A Protocol for Dynamic Trusted Execution Environment Enablement (TEEP) BOF meets Tuesday 14:50. They talk about a possible application layer security protocol that would allow configuring security credentials and software running on a Trusted Execution Environment (TEE). These environments are often found in set-top boxes, smart phones, tablets, wearables, etc. Current control and configuration protocols are propietary.
GitHub: More and more of networking software gets developed in GitHub, and it has also become a popular way for us to collaborate on the specifications themselves, with everyone having an ability make edits, raise issues, etc. We now have some experience from doing this, and the WGs Using GitHub (WUGH) BOF will discuss those experiences and find ways to work even better with GitHub. They meet Monday 17:10. There’s also a mailing list for discussing this topic.
YANG: In the Routing Area, YANG work continues to be of high interest. A Joint YANG session among four Working Groups (CCAMP, MPLS, PCE, and TEAS) will be held on Friday 09:00 to coordinate the work. Topics will include TE topology models, MPLS, PCE, Microwave Radio Link, and Transport. In the RTGWG, an update on the RTG YANG Architecture Design Team and work on-going in OpenConfig will be presented Wednesday 09:00.
Administrative matters: Changes to how the IETF is administered are also a popular discussions for the IETF community. The MTGVENUE working group is continuing our effort to define requirements that IETF meeting sites must fulfill, which seems even more important among the increasing number of travel restrictions. The IETF needs to stay as open as possible for all attendees. The group recently went through some changes. The group meets Monday 15:20. And the IASA 2.0 BOF asks whether there should be adjustments or even restructuring of the IETF administrative arrangements overall. Our arrangements have served us well, but there are also issues, and with 10+ years of experience it is time to re-assess the system. We held two workshops earlier on this topic, and the results of those workshops are outlined in an Internet-Draft. The group meets Wednesday 13:00.
New leadership: The IETF Nominations Committee (Nomcom) is charged with selecting persons for the various IETF leadership positions. The changeover is in the March meeting. For our steering group, Eric Rescorla, Adam Roach, and Warren Kumari will be starting as new Security, Applications and Real-Time, and Operations Area Directors. And I will be stepping down after four yours as chair, with Alissa Cooper continuing in that role. Please welcome the new chair and ADs! And thank you for volunteering to do this!
Running code. Last but not least, none of the above matters without software that actually does those things. Our Hackathon and Code Sprint events are open for everyone to attend, do join us and work on something that is important to you or your business! Both events start Saturday morning (09:00/09:30) before the IETF. The Code Sprint is the way that much of IETF’s own web systems and tools have come about. I want to emphasise how much we depend there both on volunteers as well as capable contractors — we need you. There are also many side events during an IETF, for instance the network operators meeting (IEPG, Sunday 10:00).
I also wanted to thank all our sponsors and supporters, and Ericsson in particular for hosting us in Chicago.
The sponsors make our meetings and IETF services possible. Thank you!
See you soon, and I wish everyone safe travels to Chicago. Hopefully the effects of various last-minute restrictions (such as the laptop ban on some flights) will remain minimal. And those participating in the meeting online — see you virtually soon!
Jari Arkko, IETF Chair
Picture credits: Thompson’s original 1830 58-block plat of Chicago from Wikimedia. In public domain.
IETF Hackathons embody the IETF’s tradition of running code—testing theories against the realties of implementation, with a goal of accelerating the definition and adoption of protocols and technologies that make the Internet work better. One of the best things about theses events is the shared success of a broad range of participants, from long-time IETF contributors to those who have never attended an IETF meeting or joined an IETF working group. Of particular note, university students from around the world have been remarkable contributors at the past few hackathons.
Team from Sungkyunkwan University IETF Hackathon at IETF 97
At the most recent IETF Hackathon in Seoul, a team from Sungkyunkwan University worked on implementations of the specifications being defined with the Interface to Network Security Function (I2NSF) Working Group. Powered by energetic professors and students from Sungkyunkwan University in South Korea, the team used RESTCONF and NETCONF together with YANG data models to implement network security services using OpenDaylight and mininet. In doing so, they validated the approach defined by the IETF’s I2NSF Working Group.
Charles Eckel, an Open Source Developer Evangelist for Cisco DevNet, who has led the IETF Hackathons over the past few years, has witnessed first hand how teams with a diverse set of participants often leads to impressive results. Eckel commented, “The most successful hackathon teams are those with a good mix of participants with different skillsets. When you combine IETF newcomers with great coding skills with IETF veterans with tremendous knowledge of evolving Internet protocols—that’s where the magic happens.”
IETF Hackathons provide students with unique learning opportunities as well. Eckel observes, “The mentoring and teamwork that comes from working closely with a group of people on a focused effort over the course of two days is a rich and valuable experience that you are not likely to get merely by reading a few drafts and attending a handful of meetings.”
On numerous occasions, even the hurdle of geography has been cleared by hackathon participants. For example, Ecole Polytechnique de Louvain in Belgium organized two teams working on Multipath TCP during the IETF 97 Hackathon in Seoul. Five participants in Seoul, including three PhD students, worked with 25 students in Louvain-la-Neuve on a new socket API that allows application developers to more easily make use of multipath TCP subflows. Together, the teams received the Best Overall award for the hackathon.
The result confirms Eckel conclusion that, “IETF Hackathons are great events for both long-time IETFers and well as newcomers. “
The next IETF Hackathon will be held in Chicago on 25-26 March 2017. As Eckel notes, “For someone with coding skills and an interest in working on the Internet, IETF Hackathons provide opportunities to get plugged into a project and immediately start producing tangible results.”
Recent news stories, and some IETF list discussion, have related to the release of (claimed) CIA materials relating to surveillance, hacking and information warfare. There has been quite a bit of discussion about the details of the various attacks contained in this leak, such as those relating to surveillance through smart TVs, or hacking vehicles. But are there more general conclusions that we can draw from release of this information?
First, we think the content of leaks is not particularly surprising, especially given knowledge of other leaks in recent years, such as those from Edward Snowden. Malware is another tool in the same toolbox that is already known to include many other efforts that attempt to compromise security, such as pervasive surveillance.
But the release of the current tranche of documents does seem to nicely support a number of things that we knew already and that are arguably more worthy of consideration:
Security is not a single feature, rather the level of security one experiences needs to be thought of as an emergent property of the whole system. Communications security, for instance, is necessary but not sufficient. You also have to worry about the security of your devices, platforms, operating systems, and components. And the reliability of your communication partners.
There is no such thing as privileged access for the good guys once there are more than a very small number of people involved. Sooner or later the privileged way to access information or hacks will either leak, be re-discovered independently by others, or be shared to parties that do not have your best interest in mind. In addition, systems built to take advantage of the privileged access will get broken and misused.
All malware is just that, malicious software designed to disrupt or compromise other systems. And all will eventually leak. Secretly held knowledge of vulnerabilities makes us all less safe. The vulnerabilities will be exploited, perhaps traded or shared, instead of being reported and fixed. And when they leak out, they do damage to your friends as well as your supposed enemies.
The security of our communications and applications matters a lot. Lives are at stake, not just your browsing history. Our entire societies run on top of our technical infrastructure, from hospitals and power plants to political processes and our economy. We cannot afford to compromise the security of these systems.
As noted, we think these are matters that are already known, but reminding ourselves of the big picture now and then can be useful.
From the IETF perspective we are of course committed to continuing our effort to provide the best possible technical tools for the Internet and the users. One technical observation that may be of use is that focusing on protecting data and not merely links or transport needs better support, make it easier to achieve in practise and at scale.
Jari Arkko, IETF Chair
Stephen Farrell, IETF Security Area Director
Photo credits: Image of the toxic leak in a reservoir in Ajka, Hungary affecting the villages of Kolontar and Devecsar, photo by DigitalGlobe, sourced from Wikimedia (CC BY 3.0).
The current IETF Administrative Support Activity (IASA) arrangements were created more than ten years ago when the IETF initially took charge of its own administration . The arrangements have served the IETF well, but there’s been considerable change in the necessary tasks and in the world around us since then . What administrative arrangements will best support the IETF going forward?
A series of virtual workshops have been arranged as part of an effort, dubbed the IASA 2.0 project, to gather community input as part of a review and possibly rework of IASA arrangements.
The workshops will help understand what is working well and what challenges or missed opportunities exist in the current system. We also want to understand what the IETF will need in coming years. Possible topics include:
internal IASA and IAOC organizational issues;
roles and interfaces between the IETF, the IAOC, ISOC, the IESG, and contractors;
availability of staff, contractor, and volunteer resources compared to the administrative workload;
finance and sponsorship arrangements.
The workshops will be virtual meetings where the participants can provide their experiences and suggestions. Proposed changes and solutions will be dealt with in a later phase . Meeting notes and an Internet Draft summarizing the input will be produced afterwards.
The agenda will be the same for both workshops, which are scheduled to accommodate participants in different timezones:
IASA 2.0 Workshop 1
Tuesday, 28 February 2017
11:00 UTC (6:00AM ET / 12:00 noon CET)
IASA 2.0 Workshop 2
Tuesday, 28 February 2017
16:00 UTC (11:00AM ET / 17:00 CET).
These documents will be helpful to review in advance of the workshop:
Every year, the IETF selects its leadership through the nominations committee or NomCom process. Today, the committee has announced our new steering group (IESG) members.
The new members are Alissa Cooper (Cisco), who will be new IETF Chair as I am stepping down. Warren Kumari (Google), will be our new Operations and Management Area AD. And Eric Rescorla (Mozilla) becomes the new Security Area AD. Together with the continuing ADs, this is a great team, and the IETF is in extremely capable hands!
When the new members get seated, we will be saying goodbye and thank you to two long-serving ADs: Stephen Farrell (TCD) in the Security Area and Joel Jaeggli (Fastly) in the Operations and Management Area. Their service to the community, dedication to making the Internet better, and rational approach to contentious issues have made the IESG, the IETF, and the Internet better.
Notably, with these appointments we’ll be continuing to demonstrate gender diversity in our leadership. Not only has Alissa been selected as the first female chair, but we’ll continue to have five female area directors serving in the IESG, the most we’ve had at one time. They are in these roles because they are the best people for their roles, but I think this also sets a great example for other tech organisations to follow in gender diversity I would like to challenge other standards organisations to top our results.
The Internet Engineering Task Force (IETF) is a global community of network designers, operators, vendors, and researchers that develops Internet protocols. Our focus is the evolution of the Internet architecture and the smooth operation of the Internet. We do most of our work online, largely through email and mailing lists, but we also regularly meet in-person at locations around the world. Whether online or in-person, we come together as individuals with the shared goal of making the Internet work better.
An important part of the Internet’s success is that it is all voluntary. Everyone connected to the Internet uses the same mechanisms by choice, and the Internet only works because everyone connecting uses the same mechanisms. Those mechanisms are the protocols of the Internet.
Because the Internet is voluntary, it only works if everyone wants to use the same protocols. So, our work on open standards–like that of the open source and and scientific research communities–fundamentally depends on the ability to work collaboratively across national borders.
The IETF does not make comments on political matters. But we do comment on topics that affect the IETF and the Internet. Specifically, the recent action by the United States government to bar entry by individuals from specific nations raises concerns for us—not only because upcoming IETF meetings are currently scheduled to take place in the U.S., but also because the action raises uncertainty about the ability of U.S.-based IETF participants to travel to and return from IETF meetings held outside the United States.
The situation is fluid. Legal and political processes around the imposition of barriers to travel will likely continue. We plan to track the situation closely in the US and elsewhere. We believe that Internet protocols develop best when people of many backgrounds can offer their contributions, and we are negatively impacted by policies that prevent such collaboration.
IETF meeting venues are always reviewed for potential impact on attendance by participants from different countries. Our next meeting is planned for Chicago, and we believe it is too late to change that venue. We recognize, however, that we may have to review our other planned meeting locations when the situation becomes clearer. We are already reviewing what to do as far as location for the next open North American meeting slot.
RFCs are documents designed to serve a variety of purposes. They offer information to developers engineers on how to make the Internet interoperate. They specify protocols, document registries and code points, and describe network experiments. They do all these things with an eye towards short-term relevancy, while being structured in such a way as to save this body of knowledge in perpetuity. Everything from the numbering scheme to the document style to the file format works together to balance the short-term and long-term needs. The RFC format project is pushing those boundaries quite a bit to make documents more easily consumed in the short term, while relying on the advances in technology to support that long-term archive of material. This is not, however, a post about the RFC format (though if you want to know more, feel free to read the FAQ!)
This is a post about what the RFC Editor is doing to improve the archival component of the RFC Series. Late in 2016, the RFC Editor entered into an agreement with the National Library of Sweden to properly archive RFCs, both the ones already published and new ones as they are posted via an RSS feed. The National Library of Sweden was established in 1661, and has had a digital archive since 1997. They take their archiving very seriously, storing material in a bunker 40 meters under the main building of the National Library.
Picture: The library’s system for digital preservation is called Mimer. Mimer is a figure from the old Norse mythology, a gentle giant who was the guardian of Mimers: a fountain of wisdom from which if you got a sip of that well you would become all wise and know everything that had happened before and everything that will happen in the future.
Stepping back for a moment from this very good news, let me explain a bit why archiving isn’t just about having a nice set of offsite backups. Quite a bit of this is explained in draft-iab-rfc-preservation but here is a quick high-level summary. A proper digital archive, at minimum, has that offsite backup component in storing a copy of the material. Beyond that, it also stores quite a bit of metadata about the document, such as when it was retrieved, when it was published, where it came from, who the author(s) and/or editor(s) are, the original location, title, all assigned identification numbers (such as DOI, ISSN, or other custom information, which in our case is the RFC number) and so on. A digital archive commits to storing and maintaining this information, and doing what it can to try and make sure the document can be viewed by whatever modern technology is available at the time.
The RFC Editor needs partners like the National Library of Sweden to archive the series. The resources available to the RFC Editor are necessarily prioritized towards the editing and publishing of RFCs; the archive itself is in those off-site backups and printed hard copies. Having an organization that specializes in digital archiving is a big win for preserving this rich set of material that documents the birth and evolution of the Internet. The RFC Editor will, of course, continue with proper backups, and will always consider the needs of an archive when we discuss any changes to the format and metadata around RFCs.
And with that, I want to offer many thanks to the people at the National Library of Sweden for agreeing to archive the RFC Series. Tack!
The essence of the IETF is that it is a place for people who both write code and specs. The IETF motto is “Running Code and Rough Consensus”. With that in mind, a big part of our work is helping and encouraging for that code writing to happen. This happens at many levels: the IETF Hackathon focuses on open source projects and Internet technology, the CodeSprint is about IETF’s own tools and web services, interoperability events test specific pieces of technology, and so on.
We will be hosting another IETF Hackathon at IETF-98 which will take place in Chicago at the end of March. The Chicago Hackathon will run from Saturday March 25 to Sunday March 26, but will surely have follow-ups during the rest of the week. We will also get to demonstrate some of the results in the Bits-n-Bites later in the week.
So do considering joining this event. The signup page is here. You can keep up to date by subscribing to the Hackathon mailing list.
Hackathon is free to attend and open to the public.
And remember that what you do at these events is up to you. You decide what is the coolest tech thing that you need to implement! So don’t be afraid to add your own project or team!
I’ll say that again: add your own topic to the wiki, and work on it!
See Charles Eckel’s mail and the wiki for the details.
I would also like to offer IETF-98 as a place for various interop and test events. We typically have several at every IETF. Many people travel to the IETF anyway, so it is a convenient place to spend some time testing. Let us know if you are planning to do some testing, we may in some cases also be able to help with rooms, networking, and help publicise your event to other networkers!
First, there will be a CodeSprint on Saturday March 25th just before IETF-98 in Chicago. CodeSprint is about IETF’s own tools and web services, interoperability events test specific pieces of technology, and so on. Everyone is welcome to attend! Read more from  and sign up .
And remember that what you do at these events is up to you, you decide. You decide what is the coolest or most useful feature; you decide what IETF data tracker feature you need for your work.
Secondly, we would like to draw your attention to work on tools that serve the IETF, and we would like to signal for a need to draw in further people and vendors in this effort.
Part of the work is on a volunteer basis, both in our Code Sprints and through various long-term efforts. Part of the work is run on a commercial basis, e.g., operations of the various IT systems that our Secretariat provides or the implementation of various new tools that we have decided to implement. The commercial efforts typically require some volunteer effort as well, for instance, Robert Sparks is the project manager for all datatracker related efforts and Joe Hildebrand is the project manager for the IETF web site redesign project.
Thanks to all of the volunteers for their efforts. We are VERY grateful for their work, and it is necessary work. But at the same, we are realizing that resources are spread fairly thin. We’re happy about the turnout in the IETF Code Sprints, but would love to get more people. And we would love to have individuals who care about particular tooling issues enough to adopt them as their longer term project and take them to completion. Getting involved with the volunteer tools work starts best at the Code Sprint, however. The next one will be on Saturday, March 25, just before the IETF begins in Chicago. Join us, and book your flight tickets so that you can spend the Saturday with us!
But the same issue applies even to the commercial parts , and we would like to have more companies or capable individuals bid for some of the projects. The Technology Management Committee and the IAOC have recently awarded the projects for building the tools necessary for the new RFC format, for instance, to two individuals that are very active in the IETF community, one of which was already doing quite a lot for the IETF. For the long-term sustainability of the IETF IT and tool efforts, we would desperately like to extend the set of people and companies looking at and bidding on these efforts. We know that many individuals in the IETF sphere have capabilities in this area, and we’d like to draw your attention to this opportunity as well. We welcome first time qualified bidders, and we pay competitively. If you can do the work, a contract to work on open source tools for the IETF can be rewarding.
Jari Arkko, IETF Chair
Russ Housley, Chair of the IAOC Tools Committee