IETF Profile: Jari Arkko

Periodic posts on the IETF Blog 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. This one is by Jari Arkko, who will step down as the current IETF Chair during IETF 98 and begin an appointment as a member of the Internet Architecture Board (IAB).

Jari Arkko

Jari Arkko

I had my first contact with the IETF in 1996. I started working with modem pool and access server products at Ericsson. Some of what we wanted to build for our products needed standards so they could interoperate. I started working with AAA protocols and extensions. Later I became chair of the EAP, EMU, and MOBIKE working groups. These were long-term efforts that I was heavily involved in.

When I was first approached about the area director role, it didn’t sound like a feasible goal, but it grew on me. But a few years later, I applied to become an Internet Area Director. It turned out to be a perfect fit — I got to work on many topics that I really cared about, such as IPv6 transition techniques. And it was good for our company because this is the layer where our products mostly were.

I was an AD from 2006 to 2012. Six years is on the long side for this job. We tell people that four years is optimal because it takes about two years to learn the job. When I was an AD, the IETF took up 50–100% of my time. Meanwhile, Ericsson benefitted from me advising them on where the technical pieces that we cared for were heading to.

I spent the year after the AD term in the the IAB. I was already wondering if I wanted to be the IETF chair. But I knew it would be a growing experience, perhaps even a scary challenge. But I thought about it for a long time and decided to go for it.

I was IETF Chair from 2013 to 2017. And this year we are again in a situation where things are changing: I will still be at the IE, contributing, and again at the IAB.

I have personally benefitted tremendously from the involvement with the IETF. Those challenges were well worth taking!  It is a privilege to witness Internet technology in the making. .And the nature of a leadership role in the IETF demands that you see things in a broader way, talk with other companies, talk with lots of people with new ideas. It forces you to understand the bigger picture. I’ve become personal friends with lots of people in the industry, a perk I’ve enjoyed a great deal.

In a leadership role, you get the feeling that you are in the middle of important issues. As chair of one of the more active or high-profile working groups, you are doing things that are broadly visible and have an impact on the Internet. As IETF chair, I was witness to many interesting things. I am an engineer and have no interest in going into political matters. Yet observing the IANA [Internet Assigned Numbers Authority] transition was a wonderful experience, and I was glad to see how that played out.

The work of the IETF chair represents almost 100% of my efforts, although I spend a fair bit of time at Ericsson. My main role at Ericsson is to share with people what is happening in the Internet and make sure we take it into account. There were many cases, including Internet of Things technology, HTTP and encryption changes, where our business was affected by what was happening at the IETF. The company appreciates our IETF team’s involvement and expertise on these topics.

If you are thinking about applying for an IETF leadership position, my suggestion is to take the challenge! Expose yourself to new things. You will understand more, which is a benefit to both you as a person and your employer.

For me, being a leader in the IETF has underscored that we actually can make a difference. We can make significant technical changes in the Internet, or change how the Internet is administered. Yes, some of the work is hard and takes a lot of effort, but isn’t that the exciting part?

IETF Profile: Alissa Cooper

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

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.

IETF-98 Highlights

800px-Thompson_Chicago_plat_1830

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).

ericsson-logo-100x 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.

University Students Create Running Code for the Internet

IETF 97 Hackathon pano

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

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.”

For more information, and details about participation, see: https://www.ietf.org/hackathon/

Observations on the CIA Revelations

TOXIC SPILL, AJKA, HUNGARY-OCTOBER 9, 2010

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:

  1. 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.
  2. 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.
  3. 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.
  4. 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).

Reviewing and Assessing the IETF Administrative Support Activity

Ranakpur-Jain-Marble-Temple-pillars-Frescoes-Apr-2004-02

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 [1]. 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 [2]. 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 [3]. 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:

[1] http://tools.ietf.org/html/rfc4071
[2] http://tools.ietf.org/html/draft-daigle-iasa-retrospective
[3] https://www.ietf.org/blog/2016/11/proposed-project-ietf-administrative-support-2-0/

The agenda and connection details can be found here:

[4] agenda
[5] meeting materials

Jari Arkko, IETF Chair
Alissa Cooper, Incoming IETF Chair

Photo credit: Acred99 in Wikimedia (CC BY-SA 3.0)

New IESG

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.

More information in the announcement.

Jari Arkko, IETF Chair for two more months :-)

Barriers to entry

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.

The upcoming IETF meeting schedule is at https://www.ietf.org/meeting/upcoming.html

Jari Arkko, IETF Chair
Leslie Daigle, IAOC Chair
Andrew Sullivan, IAB Chair

A New RFC Archive

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.

cdihkigikmmkikop

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!

Heather Flanagan, RFC Series Editor

IETF Hackathon in Chicago

hackathon97

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!

Jari Arkko, IETF Chair