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
Do you have an idea that you believe would be worthwhile standardising? Now would be a great time to start talking about it, in time for our meeting in Chicago in March!
New ideas can be proposed in the IETF in many ways:
Small improvements and features of ongoing work: these fit right in, just take the idea to the relevant working group. You can send that mail today!
Bigger new ideas may need a working group’s charter be extended or a new working group be created. Often these can be done directly online after discussion; talk to your WG chairs or Area Directors to get the process started. The proposals for significant new work always get discussed in the whole IETF community, on the mailing list, and approved by the steering group (IESG).
Some bigger ideas benefit from face-to-face discussion with the larger community. This is helpful particularly on complex topics, where we need some time to even get to understand the topic well. This also allows discussion of various common trade-off situations, as improvements often come with cost, for instance.
These ideas need to be discussed in a so called Birds-of-Feather (BoF) session; talk to your Area Director about your idea, and follow the RFC 5434 recommendations for setting up a successful BoF. The deadline for submitting BoF proposals for Chicago is February 10, which is one month away! But the process with new Internet-Drafts, mailing lists, and so on needs to start earlier.
I wanted to send a post summarising my thoughts of the discussions at IETF-97. We had 1042 people from 52 countries on site in Seoul, very active development on a number of fronts, and I thought a successful meeting! (Apologies for sending this post out late, other tasks, holidays, etc intervened.)
The meeting was supported by our host Huawei and co-hosts CNNIC and KISA (Korean Internet & Security Agency), and a long list of sponsors. Thank you for your support!
The topic of the meeting was of course Internet tech and its evolution. The two most active discussion topics were the increasingly serious Denial-of-Service attacks that we are seeing, and the development of a new transport protocol, QUIC, as an alternative to TCP and TLS, especially being more optimized for HTTP/2 usage.
The most recent Denial-of-Service attacks involved a number of compromised Internet of Things devices attacking DNS infrastructure. The IAB had organised a discussion of these attacks as an example of a more general concern: the addition of millions of new hosts has the capability to overwhelm the Internet infrastructure when those hosts misbehave. There are ways to mitigate the attacks, but not without impacts in other ways — such as finding it necessary to deploy your services on large providers.
At the very least, I think it would be beneficial for the IETF community to continue to call attention to folks that the minimum bar when introducing a large number of devices (or any device) to the Internet includes things like automatic software updates and avoiding default passwords. I used to think this was so obvious and it needn’t be said, but I’m not so sure anymore. Nevertheless, the area for us to have an impact is improving on defence and mitigation mechanisms.
You can watch the video from the IAB plenary discussion here:
The IETF recently chartered a working group to specify QUIC (Quick UDP Internet Connections). This new protocol combines the TCP and TLS layers, is typically implemented in user space rather than kernel space, and aims for faster connection setups using resumption, integrated security, and capabilities to evolve the protocol faster (not being in the kernel).
A previous version of the protocol is also already in relatively wide use at Google, and was taken as a starting point for discussion in the working group.
I’m quite excited about this development, and eager to see where it takes us, and it seems that I’m not alone:
Once again the IETF Hackathon was running the weekend before the IETF. I thought it was outstanding to see large student groups among the participants. A student team from SungKyunKwan University worked on the Interface to Network Security Functions (I2NSF) framework, for instance. With jackets made for the event!
There was also a second large student team – on the other side of the world! The team from Université Catholique de Louvain worked on Multipath TCP, but much of their team did their work from back home in Belgium. They won the best of show award:
All videos from the sessions, interviews, etc from the meeting are available as a YouTube playlist. The official proceedings with slides, minutes and everything else are on the IETF website. See also the blog post on routing area outcomes from IETF 97, and the blog post from Srimal Andrahennadi from his experiences in participating as an ISOC fellow at the IETF.
Besides the ISOC fellows group, there are a number of other gatherings happening during the IETF week. ISOC also runs a “Policy Fellows” program, with participants from regulators, governments, and other policy makers that do not usually attend technical conferences. Contact Konstantinos Komaitis at ISOC if you want to participate in this program! The IEPG meeting on Sundays is a discussion among network operators. And the Systers Lunch gathers the women participants. Contact Allison Mankin if you want to join!
So, what’s next? The work has already been going on in the mailing lists and virtual meetings after IETF-97, and will intensify as people come back from holidays. IETF’s official work happens on the mailing list. Our next meeting is at the end of March in Chicago, hosted by Ericsson:
The Internet Governance Forum or IGF is a discussion forum on matters relating to the administrative and policy questions surrounding the Internet. A handful of IETFers attended the yearly IGF meeting, this time happening in Guadalajara, Mexico, in December. We wanted to report what we saw and talk about why the discussions at the forum are important.
From an IETF geek perspective 2000+ people gathering to discuss policy issues in the Internet was quite amazing. The best moments are when people with very different backgrounds can connect. When the medical doctor from India explains the benefits of telemedicine just in reduced travel costs, let alone faster start of treatments. Or when you can connect the Bollywood movie director’s difficulties in getting paid for content in the sharing economy to your friends’ difficulties in your local newspaper industry. I felt we learned to understand the world better in some of these discussions.
IANA, and its transition had dominated global discussions of Internet Governance for the last couple of years. Perhaps unfairly; IANA is not the only and certainly not the most complex issue in this space.
But with the IANA transition behind us, you could feel the change from last year. There was a positive feeling about the community being able to complete this change and a even clearer support for the multistakeholder model of working together on Internet issues than in previous years. And of course, the forum was now able to concentrate more on other issues.
Role of the IGF
The IGF meeting is not all happy progress, however. First off, many of the issues are difficult and global trends run their own course. What can you or me or the Bollywood movie director do about the sharing economy, for instance?
Secondly, people really are different, ranging from the government officials to business specialists to lawyers to techies. And in many cases our ability to be multilingual, to speak both about our tech, policies, and business aspects is limited. You see the (rare) government official who just reads statements, you see people who have a difficult to understand that the world really has changed, us techies sometimes struggle to see the big picture, and all of us would benefit from even better connection to ongoing Internet practical reality.
But the value of the IGF in our view is that it offers a place for discussion, place for understanding the global challenges and opportunities better. It is not a perfect solution to get rid of your favourite Internet annoyance; but there may not be perfect solutions.
We’re also kind of fond of the IGF’s new working methods that focus on Best Practice Forums (BPFs) and Dynamic Coalitions (DCs) that operate throughout the year, and produce guidance that is voluntary but can help various parties recognise how they can deal with a particular issue.
As an example, the Dynamic Coalition on the Internet of Things (DC-IoT) has produced a document that outlines guidelines for “ethical” IOT applications, including meaningful transparency, user-control of data collected by the application, and so on.
Also, in the Geneva Internet Platform’s report, they asked IGF-longtimer Markus Kummer if he thinks the IGF being ‘just a talking-shop’ is really a weakness. I thought Markus’s answer was spot on:
This is one of the reasons why some governments don’t come here; they feel it is not serious enough, it is not some place we negotiate. But this is precisely the strength of the IGF – the absence of pressure to negotiate outcomes allows people to speak freely and also to think a bit outside the box, to do some brainstorming, and then go home and actually try to implement the ideas.
Key Topics at the 2016 IGF
Connecting the next billions of people remains as a key focus in many of the discussions. This is obviously very important, but we were also glad to see many references to more complex goals, such as ensuring the openness of the Internet; quality and not just quantity is important. And lets not forget that connecting all the people will not be the end of our efforts. Think of how much, say, agriculture or traffic would benefit of the optimisations that Internet communications can bring. This is true of both the developing and developed world.
The Internet of Things was also a key issue in many sessions, with a lot of focus on how it can be sufficiently secured. While Internet of Things as a technology in its own right, it also seen as an enabler for sustainable development, education, and helping the “global south” catch up.
Free and open source software is also considered as another enabler for the global south. Open source can help the poor use the tools they need, without having to afford additional expenses. It also allows auditing to protect people’s rights and information. A concern was raised from the floor of the meeting that big companies don’t care about open source. It’s important that the IETF continues putting our efforts into connecting with open source projects and supporting development of free and open source software (Hackathon, encouraging open-source implementations as we develop protocols, etc). And contrary to the concern perhaps, we think that is likely inline with what small and big businesses also want us to do.
The growing digital divide was referenced many times. While a lot of progress has been made in enabling more and more people to use the Internet, at the same time the divide is also growing. Think of the elderly who may be falling behind on the ability to use new technology, and are being shut out of many functions of the society that have moved online. Or the poor who cannot afford connectivity, which in turn may lead to the even worse outcomes due to more difficult access to commercial services, job markets, etc.
There was also discussion of big data, with suitable anonymisation and privacy protection, to assist governments and other actors in providing services, being aware of important trends, and the like – but data must be timely, relevant, and local.
Other topics of high interest included gender and diversity, freedom of expression, education, and legal matters.
The thinking sparked by these discussions will continue throughout the coming year at local and regional IGF gatherings. And, IGF 2017 will be held in Geneva, Switzerland on 18-21 December.
Jari Arkko, Andrew Sullivan, Ted Hardie, and Barry Leiba
Photos: The IOT Dynamic Coalition meeting with Max Senges speaking with Joe Alhadeff, Vint Cerf, Maarten Botterman and Avri Doria in the background (photo by Jari Arkko), Larry Strickling speaking at the IGF Opening Session (photo by Jari Arkko), and your IETF and IAB chairs hard at work on the in-the-meeting-compound Tequila farm (photo by Ted Hardie).
When we pause to reflect on what happened during an IETF meeting, it’s always encouraging to realize how much got done and how many excellent discussions happened. Of course, part of that reflection is writing down all the Action Items that each of us has managed to accumulate. We’d like to share with you some of the highlights.
As the WG responsible for maintaining BGP, IDR is well-known for requiring two implementations before requesting that an internet-draft be published. That might make one think that IDR is always slow to advance work – but the recent experience with BGP Large Communities reminds us that what has drafts progress quickly is the amount of interest and work put into it. While BGP Large Communities is a small feature, it is very critical for operators who need to use 4-octet Autonomous System Numbers in their policy. This Internet-Draft went from individual on July 5 to WG adopted on Sept 23 to WG Last Call done on Nov 3; it is currently in IETF Last Call and on the Jan 5, 2017 IESG telechat. It took less than 4 months for IDR to be ready to progress it – and there was plenty of discussion!
SIDR was originally chartered to develop standards to secure inter-domain routing: origin and path validation. Origin validation is being deployed in pockets around the world, with most notable advances in the LACNIC and RIPE regions. The BGPsec specification for path validation is scheduled for the Jan 5 IESG Telechat. The WG has now completed its objectives and will be closed once the publication process is completed to the outstanding work. Because we are now in a deployment phase, the SIDROPS WG has been chartered in the OPS area.
In the last year, NVO3 has had limited technical discussion beyond discussing different encapsulations. Before IETF 97, NVO3 created a dataplane encapsulation design team with the consensus of creating a single encapsulation to progress as Standards Track. At IETF 97, Matthew Bocci, Sam Aldrin, and Alia decided to make use of the IETF 97 face time to strongly encourage smaller group discussion. With the help of three facilitators for each discussion and large pads of paper, the first NVO3 meeting broke up into 3 discussion groups – on OAM, Control Plane, and Data Plane in 3 corners of the room. Each group had around 15 people with a number actively contributing and others focusing and learning. The facilitators summarized their discussions for the second NVO3 meeting the next day; there weren’t missing viewpoints and there was additional discussion. Not only were the small group discussions useful, the energy level and interaction in the room noticeably increased in the second meeting. It really helps to know exactly which other people are extremely interested in the same detailed topic. As discussed in the WG Chairs Forum at IETF97, the IESG is encouraging WG Chairs to experiment more with making better use of face time. This was one such successful experiment.
YANG continues to be a focus in the Routing Area and many of our YANG models (BGP, OSPF, IS-IS) are nearing completion. RFC 8022, the base model for Routing Configuration, is a key dependency that is now completed. At IETF97, TEAS, MPLS, CCAMP, and PCE had another joint meeting to discuss the YANG models for RSVP-TE, Traffic-Engineering, LDP and mLDP, TE Topology, PCEP and others. This is an example of how multiple WGs can collaborate to make sure that the models reflect operators’ perspective rather than the specific protocols or IETF Working Group structure. I2RS has finished with the models for Network Topology and for Layer 3 Topologies and is awaiting implementations for the RIB model. RTGWG has completed WGLC on the Routing Key Chain model; RTGWG is discussing adopting draft-rtgyangdt-rtgwg-routing-types-00 to provide common types for the models.
Large data-centers have interesting routing problems. RFC 7938 provides information on a way to use BGP in a CLOS data-center network. There continues to be different efforts to better handle routing in data-centers based on significant changes to existing protocols. RTGWG will have a virtual interim on January 25 to discuss the specific problems of data-center routing. We are hopeful that the discussion will help clarify reasonable paths forward and would strongly encourage those able to describe the current operational issues to participate.
During its interim, BIER reached an agreement to make a generic encapsulation based on the existing MPLS and proposed Ethernet encapsulation. These changes were discussed during the meeting and – as often happens – the technical concerns raised led to a side-conversation that had time for the technical depth to resolve the concerns. BIER continues to discuss ideas around an IPv6 encapsulation and brought the discussion to 6man; the possible use-case of using an IPv6 encapsulation to help in IoT was also discussed. Extensions to Babel to support BIER were discussed in BIER and brought to the babel WG; extensions are a bit different for Babel and an initial implementation is being encouraged to explore the idea. It is interesting to see a possible expansion of BIER to handle the multicast requirements in homenet.
As announced on email@example.com, we had another open meeting to discuss and facilitate the interaction of Open Source projects with the IETF Routing Area. Interactions between the IETF and other organizations work well when there are overlapping participants who understand the different communities. We continue to be interested in ways to encourage interactions and mutual understanding of the different maturity levels that projects and different internet-drafts & RFCs provide. CodeStand is a recent website to connect up, among others, open source development communities and link work to standards.
At the IETF 97 Hackathon, the ACTN (Abstraction and Control of Traffic Engineered Networks) team won the best input to a Working Group Award!
CCAMP has kicked off a new design team on Transport NBI modelling. The work will coordinate with TEAS.
The MANET WG has reached an important milestone in the development of protocols for the rapidly changing mobile ad-hoc networks with the soon-to-be-published specification for DLEP (Dynamic Link Exchange Protocol). The exchange of dynamic information between a router and associated modem/radio is critical to optimize routing decisions. DLEP has applicability in both military and commercial networks.
Of course, we could easily go through all 25 WGs in the Routing Area, but these are a few of the highlights. We encourage you to check out the others and tell us what we should have mentioned!