Overhead photo of the Circle Interchange in Chicago. Photo by Stratosphere. (CC BY-SA 4.0)
As Routing Area Directors, we have now made it a habit to share some of our thoughts after each IETF meeting. This is a short summary of some of the highlights from the recent one in Chicago.
YANG continues to be a focus in routing and the IETF as a whole. While in Chicago, many working groups had YANG models in their agenda and even specific sessions to review and move the work forward, as was the case for the joint meeting of the mpls, ccamp, pce and teas WGs. The importance of some of this work is reflected in a recent IETF Journal article: Working Group Update: Microwave Modelling at CCAMP.
The netmod WG is making progress with the Network Management Datastore Architecture (NMDA) that will allow access to system-derived state (think of new interfaces learned by inserting a line-card) and cleaner access to operational state versus configuration by having explicit operational and intended datastores. Knowing this future direction allows us to recommend how affected YANG models can be finalized in RFCs.
Along with the Operations and Management (OPS) ADs, we will be sending out precise guidance (thanks to lots of work from the NetMod DataStore Design Team and the Routing YANG Architecture Design Team) that should allow most YANG models to be completed and implemented without delay. To summarize, the models should include all configuration and state in a single normative module to be NMDA-ready. When needed, it should have an optional state module that provides access to the state not otherwise accessible until NMDA and the associated protocol work is implemented. Of course, there are rarely one-size-fits-all rules and this guidance is no different; the exceptions will need to be individually discussed.
In the period before IETF 98 the spring WG has accelerated the work on several of the key documents that will open the way for the segment routing-related extensions defined throughout the area, including use cases and the Segment Routing Architecture document. The chairs opened the discussion about which topics should be the subject of an updated charter for this WG.
The sidr WG is also close to finishing its charter – just a couple of documents remain. While it didn’t meet in Chicago, the participants met as part of the new sidrops WG (in the OPS area). This transition from the development of solutions (origin and path validation in this case) to the understanding that implementation and deployment should now take center stage is critical to this work, but also to the routing area in general. Another good example of the same trend is the trill WG, which is also finishing up the currently chartered work; additional work based on strong operational needs may still be considered.
It is very important for the WGs in the area to keep a close eye on operational requirements, experience and feedback. Besides sidrops, other WGs also deal specifically with the operations of routing-related technology, including grow and mboned.
One of the topics for discussion in rtgwg was “Routing in the DC”, which has several proposals on how to make routing in the data center more efficient, scalable and flexible. This session served as a review of some of the proposals and the opportunity to listen to operators express their needs in response. We look forward to a continued and tighter participation from the operations community.
The detnet WG is making good progress on their Deterministic Networking use cases, architecture, and selecting a data plane. The DetNet Data Plane Design Team gave an update on their work and proposed their DetNet Data Plane solution document is ready for adoption.
The bier WG has made excellent progress with a unified encapsulation that will work for MPLS and Ethernet. The WG took an important step forward in deciding to continue with the WGLC and eventual publication of their work as Experimental RFCs, instead of waiting for deployment experience and pursuing the Standards Track. The decision was aided by the existing ability to do RFC Status Changes without impact to the IANA registries or even the RFC number.
The babel WG had a good discussion on adding unicast hellos to the protocol; several implementers have use-cases that need them. The WG remains small but active with focused technical discussions and an emphasis on experimenting with ideas via implementations before agreeing on changes.
NVO3 discussed the recommendation of its Design Team to select an updated Geneve as the standards-track encapsulation. The consensus is being verified on the mailing list. For the second IETF meeting, nvo3 experimented with meeting twice and having small group discussions on data-plane, control-plane, and security. The WG could use more folks interested in discussing security extensions and use-cases.
While we would like to walk through every WG in the area, this summary is meant to be just that, a summary. If you want more information, please take a look at the IETF 98 Routing Area Working Group High-Level Summary that the WG Chairs put together. Just a few more work items that are worth listing here:
The lisp wg is making progress with the transition of their core experimental documents, RFC 6830 and RFC 6833, to the Standards Track.
The teas wg has been refining the ACTN (Abstraction and Control of TE Networks) Framework and Requirements
IPv6 is not optional – the need to specify, implement and deploy IPv6 is well understood by everyone. During the Routing Area meeting we made a call for the WGs to consider the deployment of IPv6-only networks, and the transition to them from IPv4-only and dual-stack implementations. The intent is to consciously find and fill any specification gaps as vendors and operators clearly work towards that goal.
As Area Directors, our interests go beyond the technical work and into, for example, the topics of outreach and remote participation. To that effect, we are working on efforts to better characterize and eventually measure the participation at remote hubs, from new people to the IETF all the way to established contributors. Also, we are currently involved in other IESG-wide topics including side meetings, BoFs and the application of the Note Well. We welcome any comments or ideas about these topics or others that you think the IESG should be addressing.
Finally, the IETF meeting in Chicago marked the start of Deborah and Alvaro’s second term as Area Directors. We are very happy to be able to continue to work together.
About a month ago I officially took on the role of IETF Chair. My predecessor Jari Arkko noted upon beginning his term as chair just how much can change from one chair’s term to the next. As I’ve started settling into my new role over these last weeks, I’ve been thinking a lot about what has been changing and what has been staying the same in the IETF.
Past and present IETF Chairs with IETF Senior Meeting Planner Marcia Beaulieu. From left, Fred Baker, Jari Arkko, Alissa Cooper, Marcia Beaulieu, Russ Housley, and Harald Alvestrand.
When I first started participating in the IETF, it didn’t take long for me to realize the importance of the IETF as a venue for creating the building blocks of the internet. The significance of the IETF derives from the combination of what we choose to work on and how we carry out that work. Producing core standardized protocols wouldn’t have nearly the same impact on the internet as the existing body of IETF work if it were done behind closed doors, if a single constituency could dictate the outcome, or if broad interoperability were not the main objective. To my eye, the core principles of the IETF process – open participation, cross-area review, and consensus – contribute to the success of IETF protocols in tandem with the design choices and technical trade-offs inherent in protocol design.
Of course, those process features are also often cited as drawbacks of IETF participation. “The IETF moves too slowly,” some people say. “They’re not adaptable,” “they can’t compete with open source,” “the biggest players aren’t interested in consensus.” Sound familiar? Sure, it’s true more often than not that if you’re trying to find agreement among a large, heterogeneous pool of people, that will require a different investment of work and time than deciding things among you and your close group of friends, or hacking something together all on your own. The challenge I see for the IETF in the coming years is to preserve the benefits of the essence of the IETF model while adapting to changes in the industry and the environment. With collaborative styles of engagement flourishing across both open source and standards development, there is a lot of opportunity for synergy.
How can we do a better job of integrating our work with open source development efforts? How can we evolve our tools and processes to align with how software is being developed and deployed today? How might we apply the model of cross-area review and consensus more broadly than to static text specifications? How can we evolve the administration of the IETF to give the community more flexibility and room to experiment? I have my own thoughts about these questions, but far more important are the ideas and efforts of the IETF community.
Personally I think we have many reasons to be optimistic about tackling these questions, based on recent IETF standards development work as well as ongoing community conversations and activities. Over the last several years we’ve seen protocol development efforts deeply intertwined with and informed by running code, with the concurrent development of 10 or more independent implementations, for instance in the case of HTTP/2 and TLS 1.3. We’ve seen broad interest across the industry in the kind of security expertise that has become a hallmark of the IETF, and resulting security and privacy improvements being developed for web, email, DNS, DHCP, real-time, and other kinds of traffic. We’ve seen tremendous energy behind the specification of YANG data models and their integration across the industry into standards processes. And community discussion and activity continues to grow around the IETF Hackathons, use of Github, remote participation, and IASA 2.0.
I’m excited to work with the community on how we face the changes around us while retaining the core of what makes the IETF most effective. We have lots of existing venues for discussions of specific aspects of this, but of course you can always send me your thoughts or post them to the IETF discussion list.
The IETF 98 is now over. This was a successful IETF meeting in multiple ways, one of which is the IETF hackathon, two days of hacking on Saturday/Sunday.
Before delving into the hackathon results, let’s briefly review the YANG « state of the union ». As you know, YANG became the standard data modeling language of choice. Not only is it used by the IETF for specifying models, but also in many Standard Development Organizations (SDOs), consortia, and open-source projects: the IEEE, the Broadband Forum (BFF), DMTF, MEF, ITU, OpenDaylight, Open ROADM, Openconfig, sysrepo, and more. Here is a nice summary presentation “SDN and Metrics from SDOs” by Dave Ward during the Open Networking Summit 2017.
This data model-driven management applies throughout the automation « stack »: from data plane programmability with the fd.io honeycomb open-source project that exposes YANG models for VPP functionality via NETCONF and RESTCONF, to operating systems with the sysrepo open-source project (Sysrepo is a YANG-based configuration and operational datastore for Unix/Linux applications), to network control via the networking specifications in IETF/IEEE/BBF/openconfig/etc., to service models specification (YANG Data Model for L3VPN Service Delivery as an example), to controller and orchestrator and open-source projects such as openconfig), to cloud and virtualization management, without forgetting the orchestration and policy aspects (for example, the MEF Livecycle Service Orchestration).
With the rise of data modeling-driven management and the success of YANG as a key piece comes a challenge: the entire industry develops YANG models but those models must work together in order for operators to automate coherent services. And they must work together NOW. We don’t have the luxury to work in well planned sequences and all the modules. On one side, the YANG modules are constantly improved, and on the other side, they depend on each others.
In order to resolve this challenge, we’ve been working during IETF hackathons to provide the right open-source tools for the industry. Previous results after the IETF 97 have been highlighted. At this IETF, a team of around 10 people went one step further by integrating tools around a YANG catalog.
Note: I went the easy way to create this blog with « we » as opposed to stress individual achievements, but many thanks to Joe Clarke, William Lupton, Einar Nilsen-Nygaard, Gary Wu, Mahesh Jethanandani, Radek Kreji, Sudhir Rustogi, Abhi Ramesh Keshav, Carl Moberg, Rob Wilton, Miroslav Kovac, Vladimir Vassilev, and more.
What is the idea behind a YANG catalog?
From a high-level point of this YANG catalog goal is become a reference for all YANG modules available in the industry, for both YANG developers (to search on what exists already) and for operators (to discover the more mature YANG models to automate services). This YANG catalog should not only contain pointers to the YANG modules themselves, but also contains metadata related to those YANG modules: What is the module type (service model or not?) What is the maturity level? (for the IETF: is this a RFC, a working group document or an individual draft?), Is this module implemented? Who is the contact? Is there open-source code available? And we expect much more in the future. The industry starts to understand that the metadata related to those YANG modules become equally important as the YANG modules themselves. We based on work on openconfig catalog, as a starting point but we realized that we have slightly different goals.
The YANG catalog added value, compared to a normal Github repository resides in the toolchain and the additional metadata:
the demonstration of data model-driven management with open source tools: YANG Explorer (a GUI-based tool to explore modules, generate some code, and connect the devices) YANG Development Kit (a more advanced tool for code generation)
Using this one-stop set of tools, the typical flow for a YANG module designer is to validate the YANG module and to populate the YANG catalog (via an IETF drafts, via Github, or directly via the YANG catalog).
And the typical flow for a YANG module user is to search for an existing YANG module, to look up the metadata (such as maturity level, implementation, etc.), and to look up the import and include dependencies if any. Once the YANG module of choice is found, the YANG module user would browse the YANG module content, then load the YANG module in the YANG Explorer and test it by connecting to a NETCONF or RESTCONF server, and finally generate python scripts to start the automation.
This is obviously work in progress and contributions are welcome, as everything is open-source.
Practically, what have we done during this IETF 98 hackathon?
The YANG validator improved, with yanglint as an additional validator and with specific plugins that will check the correct format for the IEEE, MEF, BBF, and Cisco-specific plugins (practically, they will check the urn and prefix).
The YANG DB search laid a framework for the multi-SDO impact analysis, including a color scheme for the standard maturity levels. Below is an example.
Regarding YANG module validation, William Lupton from the Broadband Forum added all the BBF modules to the YANG catalog, including the work-in-progress ones (this means 192 modules in total). While validating those modules, we discovered some issues with some validators. Those issues are now solved and most BBF YANG modules validate correctly. Finally, William updated the YANG catalog With the BBF modules maturity level that will distinguish draft and ratified YANG modules. The example here BBF work-in-progress YANG modules depending on the IETF interface YANG module [RFC 7223].
We created a script to push, as a cronjob, all extracted YANG modules from IETF drafts into Github (we still have to integrate it in the tool chain btw). Background: it should be a priority for the IETF to separate the draft text from its « code » content, such as a YANG module, so that we don’t have to extract YANG module via tooling, and so that the YANG module could progress in Github independently of the draft version.
Another major achievement for this hackathon is the integration of the YANG Development Kit into the YANG Explorer. In this example below, you see the YANG Explorer with the GUI on the left-hand side and the generated python script.
In term of YANG module transition, we also created a script to help with the latest IETF YANG module guideline: a script to convert the -config/-state into a combined tree, to convert from a combined tree to generating an additional -state tree, and to convert from a combined tree to generating an Openconfig style tree. This will be pretty handy for the transition phase, and a good addition to the toolchain.
I have personally great hope for this YANG catalog, as it will solve a real issue in this industry. Now, we should not wait until the next hackathon to continue improving it. « Running code and consensus » I heard someone say!
The 98th IETF meeting wrapped up last Friday in Chicago. It was a typically busy work week for IETF participants, but also a special week, as a number of changes in our leadership became official. We welcomed newly selected individuals into the leadership and gave our thanks to outgoing members of the IESG, IAB, and IAOC, including the outgoing IETF Chair, Jari Arkko. Among his many other accomplishments, it was under Jari’s leadership that this blog came into existence. The blog has proven to be a useful tool for communicating with the IETF community and the world at large, and I intend to keep up the tradition. Same goes for video – you can see a clip of Jari and I recapping the meeting week here:
Amidst all the working group action and leadership transition activities, a few highlights stood out for me last week. Among more than 1000 attendees, nearly 17% were attending their very first IETF meeting this time around. We’re constantly evaluating what more we can do to attract cutting edge standardization work and new participants to the IETF, so it was nice to see many fresh faces.
Last week’s meeting demonstrated that a number of core security and web application standards are on a path towards high levels of maturity and industry adoption. These include:
The work on all of these standards is heading towards conclusion within the respective working groups, and will soon be put out for IETF community review. There was also a large TLS team at the IETF Hackathon representing 18 independent implementations, and they were named the overall Hackathon winners by the judges. Congratulations!
IETF Hackathon in Chicago.
Last week was also very busy for those working on YANG data models related to both network management and routing. While participants continue to press forward with the standardization of hundreds of different YANG modules in the IETF, they’ve also been focusing on guidelines and tooling (yangcatalog.org, for example) to help streamline the model development process and aid interoperability.
Our technical plenary speakers, Niels ten Oever and David Clark, addressed questions about the relationship between internet protocols and human rights. David encouraged us to think of standardization activities as “designing the playing field” and to contemplate how we “tilt the playing field” based on the design choices that we make. As expected, the topic yielded a provocative community discussion session.
Plenary speakers Niels ten Oever and David Clark with IAB member and plenary moderator Lee Howard.
We owe deep thanks to our meeting host, Ericsson, for stepping up to ensure the success of last week’s meeting. As an IETF Global Host, Ericsson has committed to host three IETF meetings in a 10-year period and affirmed its long-standing support for the work of the IETF. We heard at the plenary session just how important IETF work is to Ericsson’s industry and technology goals, particularly as the coming shift towards 5G inspires potential new requirements around packet transport, network and service management, and virtualization.
Until we gather again as a group for IETF 99 in July, work will continue as always on mailing lists, at interim meetings, and increasingly on Github (check out the Working Groups Using Github session for more on that). See you in all of those places …
Alissa Cooper, IETF Chair
Photos from IETF 98
A collection of photos from the IETF 98 meeting held 26-31 March in Chicago, Illinois, United States.
Before IETF 98 began, the IETF Hackathon was in full swing.
Applied Network Research Prize winner Alistair King presents his research at IETF 98 Chicago 26/03/2017
Applied Network Research Prize winner Yossi Gilad presents his research at IETF 98 Chicago 26/03/2017
David Clark speaking on the question:What is the relationship between Internet Protocols and Human Rights? During the IETF 98 Plenary on Wednesday, 29 March 2017 Niels ten Oever, Head of Digital for Article 19, and David Clark, Senior Research Scientist at the MIT Computer Science and Artificial Intelligence Laboratory, tackled this question. They offered different perspectives on the role human rights considerations should play in the Internet protocols and, in particular, how these considerations ought to factor into the work of the IETF. (L to R: Niels ten Oever, David Clark, Lee Howard)
Outgoing IETF Chair Jari Arkko speaking at the IETF 98 technical Plenary, Chicago 29/03/2017
Incoming IETF Chair Alissa Cooper speaks during IETF 98 Plenary on Wednesday, 29 March 2017.
John Mattsson, senior specialist at Ericsson Security Research speaking as part of the IETF Host Speaker Series on ‘The real deal on cellular security’ during the IETF98 meeting in Chicago, Thursday, 30th, March 2017.
IETF 98 Wrap up video with Jari Arkko and Alissa Cooper, Friday, 31 March 2017.
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).
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?
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).