In 2003, RFC 3535, “Overview of the 2002 IAB Network Management Workshop” documented the outcomes of a dialog started between network operators and protocol developers to guide the IETFs focus on future work regarding network management. The 14 operator documented requirements led to the sequential creation of the NETCONF Working Group the same year, the NETMOD Working Group in 2008, and the core data models. The work resulted in XML-based Network Configuration Protocol (NETCONF) RFCs 6241, 6242, 6243, and 6244, in 2011 (respectively revised from 4741, 4742, 4743, 4744) and the associated data modeling language YANG RFCs 6020 and 6021 in 2010. Unfortunately, the deployment of new management protocols takes longer compared to non-management protocols. Indeed, it takes a while to get those RFCs implemented in the majority of devices. But now we see that the new protocol and data modeling language are picking up.
At the IETF 90 last week, starting on Sunday, the “YANG Advice and Editing Session” took place. A “pyang” tutorial, presented by Ladislav Lhotka, and a presentation on code generation experience from the OpenDaylight project started the afternoon (both sessions were recorded and will be shared). Then, during 2h30, the YANG doctors provided their advice on existing YANG models, both individual and WG documents. In total, 13 YANG models were reviewed, and some updated on the fly during the afternoon. This experience, which received very good feedback, should speed up the development of standardized YANG models in the industry. The YANG doctors found this session useful as well, for their update of “Guidelines for Authors and Reviewers of YANG Data Model Documents” RFC 6087bis. We plan on repeating this “YANGathon” sesion in future IETF meetings.
At this IETF, “YANG” was the subject of many discussions. The I2RS WG selected YANG for their work a couple of weeks ago. The routing experts discussed OSPF, ISIS, BGP models, all of them based on the foundational “YANG Data Model for Routing Management”. YANG was mentioned as potential solutions in BoFs, for example the Abstraction and Control of Transport Networks (ACTN), as a way to specify service models. And also in side meetings such as “Application-based Policy for Network Functions” (APONF). Confirmed by hallway conversations, we can expect way more YANG models in the future. This is a good problem, but also one we have to prepare for.
Is this YANG interest only in the IETF? Not quite. We see a lot of interest for YANG models in the Open DayLight open source project, with more than 100 YANG models. At the last IEEE meeting, Andy Bierman provided a tutorial on NETCONF and YANG, targeted for people who have been using SNMP and MIB modules. This will certainly trigger a process of transformation in the IEEE 802 management space. Regarding MIB modules, let me stress one more time the “Writable MIB Module IESG Statement” IESG statement, which explains that SNMP is not ideal for configuration of devices, while NETCONF is.
On the tools side, the NETMOD WG is experimenting with using github for faster data model development. So far, a github repository has been created that a number of YANG models from standards organizations such as the IETF, open source such as the Open DayLight project, or vendor proprietary ones. After the “YANG Advice and Editing Session” on Sunday, some models were directly updated in github. This repository should not only speed up data model iterations and developments but also brings bridge the gap between two communities, the IETF community and the open source community.
To the question “Where should the YANG models be specified in the IETF?”, discussed on regularly, the answer is: The end goal is that the different Working Groups produce their own YANG models. For example, the “6TiSCH: “IPv6 over the TSCH mode of IEEE 802.15.4e” charter mentions data models. The YANG doctors reviewed two 6tisch WG documents during the “YANG Advice and Editing Session“, guiding the authors in the right direction.
However, not all WG charters consider data models at this point in time. Note the recent change in the NETMOD charter:
The NETMOD WG may also develop any additional data models written in YANG that the WG considers core building blocks and that do not fall under the charters of other active IETF working groups. The NETMOD WG may simply add such milestones as it sees fit, with the advice and consent of the responsible AD.
Finally, the NETMOD WG scheduled weekly calls to go over the YANG 1.1 issues. With all the energy around NETCONF and YANG, and the willingness to work more efficiently and faster, a physical NETMOD interim is planned for September (see the NETMOD mailing list for the details).
All these observations point to a single conclusion: YANG takes off in the industry! The YANG community is dedicated to hep make YANG a success.
IETF-90 is over and I wanted to provide a summary of what I saw in the meeting. But first things first, a number of other people have also made very useful observations. Andrew Sullivan wrote a blog article earlier about his perception of the IANA discussions. And Benoit Claise talked about industry interest for YANG in his article. Dan York’s blog reported his perceptions from the meeting. And finally, in my blog series, Nik Tomkinson relayed some of his experiences on attending the IETF as a robot.
Overall, I think we had a great meeting, with a good turnout of 1231 people on site from 54 countries. My personal highlights for the week include improving the security and privacy, Internet of Things and dealing with the transition of IANA oversight.
I would like to thank all of our participants, remote or on site. I would also like to thank the our sponsors and in particular Ericsson for being the host of the meeting. Thank you!
The Internet of Things
This is a big topic for the IETF. And we seem to add more work in every meeting! The first new item last week was the low-power and lossy networking plugfest, an event where the participants were testing their implementations against each other. Such tests are a big part of the IETF mode of operation. While formally outside the meeting, implementors often gather at the IETF meeting to run such tests.
The second new item was the ACE working group, focusing on the question of how to bootstrap security and authorisation in a network of smart objects.
The third new item was the Bits-and-Bites event, which has been running for some years, but this time we had a new format and a focus topic. We had ten different organisations demonstrating Internet of Things solutions, and a lot of interested participants looking at the demos. We will be continuing the Bits-and-Bites event series in future IETFs in the same fashion – please propose focus topics that you would like to see.
Security and Privacy
Earlier this year we came to the conclusion that the IETF needs to do its part to ensure that Internet technology provides better tools against mass surveillance activities. Of course, improving the security of the Internet is no easy task, but we are working hard on several fronts, including updating the TLS and HTTP protocols (see TLS and HTTPBIS working group efforts).
One of the difficult tradeoffs that we have discussed this week is how increased use of encryption affects caching and other network functions. This continues to be a challenge, but at least it is clear after this week that HTTPS remains as an end-to-end security solution. Various caching and secure tunnelling solutions may arise for other traffic, however.
The newly formed TCPINC working group had it first meeting on developing a new layer of opportunistic security, mainly for applications that don’t use current transport layer security as used for example in the web.
The IETF has been discussing this actively since the announcement from the US government in March. I am happy about the transition, but I think we at the IETF see it as a part of longer term evolution that has already happened with regards to how we deal with the oversight of IANA. In the last 15 years, we have developed contracts, oversight mechanisms, and processes that our part of IANA is running on.
Our meeting this week confirmed that the IETF community believes these mechanisms are sufficient also going forward. We will be documenting how these mechanisms address the requirements for the oversight in the coming weeks and months. I feel very optimistic about the process.
IETF-91 is coming up in November, held in Honolulu. I would like to welcome everyone to the meeting!
But the IETF work runs all the time on mailing lists. What can we expect in the coming months? The major projects, such as WebRTC, HTTP 2.0, and so on will of course continue. Some of the key milestones ahead include the publication of the final HTTP 2.0 RFC (later this year), as well as concluding our part in the IANA transition work (also planned for completion within 2014).
Please visit our newcomers page if you would like to join us in this important work.
We have built a lot of support for remote attendance in the IETF, but this week I saw something new. Nik Tomkinson was attending the meeting as a robot, while himself staying back in UK. We’ve all been through video conference experiences, but the feeling that you get from a robot that is moving around, turning to look at you… mingling in the IETF receptions… is different, and quite life-like.
Nik and his colleague Nathaniel Borenstein from Mimecast have teamed up to attend IETFs, one in person and the other one as a robot, and this time it was Nik’s turn to be the remote attendee. They use a commercial telepresence robot from Double Robotics. The robot is connected over the Internet back to the user’s home, and its movements are controlled by the user.
This is what Nik had to say about his experience:
Attending the IETF conference as a robot was quite a unique experience. It enabled me to engage and be part of the sessions to a much higher degree than with the unidirectional ‘listening in’ to the live audio stream. I was able to attend sessions throughout the whole week, take part in a face to face meeting and even drive around among the crowds at the Bits and Bites reception. Also, I was not restricted by the location of the cameras and microphones, as I carried my own around with me.
Currently there are a number of operational issues which requires a ‘helper’ to assist at the conference, but I can see that over time the dependence on someone in this role would diminish with improved software, hardware and networking.
It certainly was a more practical and convenient way to travel across the Atlantic and to take part in such an event. Saying that, it was a little frustrating not being able to shake someone’s hand when you meet them at the conference. Maybe we need to develop a bluetooth appendage.
Will we see a crowd of these robots in future meetings?
On Thursday morning of the IETF 90 meeting, we had a Birds of a Feather (BoF) session called IANAPLAN: Planning for the IANA/NTIA Transition. Last March, the National Telecommunications and Information Administration (NTIA) announced a plan “to transition key Internet domain name functions to the global multistakeholder community.” The NTIA’s plan is to do this in conjunction with the expiry of its contract with ICANN in September of 2015.
NTIA asked the Internet Corporation for Assigned Names and Numbers (ICANN) to convene various stake-holders, including the IETF, to develop a proposal for how to complete the transition. ICANN did that, and various organizations appointed members of the IANA Stewardship Transition Coordination Group (ICG). The IAB appointed two (Russ Housley and Lynn St. Amour), and the IETF appointed two (Jari Arkko and Alissa Cooper).
Given those activities going on outside the IETF, the IESG concluded that it needed to know what the IETF community thinks. The IAB has a programfor IANA evolution, but the IAB isn’t tasked with representing IETF consensus. The goal of the BoF was to understand whether an IETF working group is needed to respond to the NTIA’s request and to work on the overall questions related to the IANA transition. To me, at least, the BoF was successful in learning what we needed to know.
There were three clear messages from the BoF. The first, clarion message was that we have an existing, working, well-functioning system, and we should take extreme care to avoid changing it, while documenting how it satisfies requirements from the NTIA. It appears that this was a value already shared, but it was good to have it confirmed.
The second message was that, because there are changes to the overarching framework in which our existing system fits, we need to understand how those changes might affect us by accident. We need to have a complete analysis of that, and ensure that anything that could affect us is addressed. That way, we can avoid unwanted changes to our smoothly-functioning existing system.
The final message was that, given the very short time we have, it would be best if the IAB’s IANA evolution program undertook most of the work. At the same time, we need a newly-created working group to review that work and achieve (and demonstrate) consensus.
What is particularly heartening about this is that the apparent strong consensus in the BoF is itself a clear example of the existing IETF procedures working. There is a question — in this case, a policy question, and not a protocol one — that needs a decision, and the community comes together and makes a decision based on both rough consensus (the agreement displayed in the room) and running code (the actually functioning procedures we have today). This gives us the opportunity both to state how we wish to proceed, and show how well that works in practice.
The 90th IETF starts next Sunday in Toronto, Canada. Canada is one of our favourite places to meet at. We are there now for the 10th time. And for the second time in Toronto, our previous visit being exactly 20 years ago!
The meeting next week is shaping up to be an exciting and well-attended meeting. We already have over 1358 registered attendees and the numbers are growing.
The host for this meeting is Ericsson. I am of course very happy about their support, which is important for the meeting arrangements. I am also happy that the wireless industry in general continues to be very active in developing Internet technology. The number of mobile broadband connections to the Internet is expected to grow from 2 to 7 billion by the end of this decade. Much work remains on not just setting up the accesses, building the devices, but also making the Internet technology and services suited for the even more diverse situations that it will have to run in.
I also wanted to provide a couple of highlights on what I think are interesting next week:
BoFs – The many new work proposals or “Birds-of-a-Feather (BoF)” sessions that we have this time. My particular favourites are UCAN which is about automating even more about network configuration and DTNWG which is about standardising a delay-tolerant-networking protocol after years of research. Read more about the BoFs in a separate article.
IANAPLAN – The IANAPLAN meeting will discuss how the IETF should deal with the transition of NTIA’s stewardship of IANA functions to the global Internet community (such as the IETF). My personal belief is that for the IETF, the transition is relatively easy, because offer the years we have built up the agreements, processes, groups, and RFCs that define how we work together with IANA.
RTGAREA – The Routing Area has been discussing various options for restructuring the working groups in the area to enable more efficient and focused work. The Routing ADs will be available to discuss the options all week including in their office hours on Sunday afternoon, and the Routing Area open meeting on Thursday afternoon will spend time debating the issues.
YANG – One of the interesting topic sin the Operations and Management area is YANG. In the industry there is a growing interest for configuration management with YANG modules. On Sunday, the YANG session, the YANG doctors will be available to provide advice on your YANG models. This session is not a tutorial on how to design YANG models and use NETCONF, but a place to get feedback on your data modeling questions, language usage questions, tools to use, and so on.
LLN plugfest – As may be obvious from the above, many IETFers work on the Internet-of-Things topic. In addition to working on specifications during working group sessions, they often arrange interoperability test events. The Low-Power-and-Lossy networking event runs on Sunday, join the test!
Privacy – Our efforts to improve the privacy and security of Internet communications continue, for instance in the TLS, HTTPBIS, UTA, and TCPINC meetings.
I look forward to the meeting in Toronto. I would like to welcome you all to the meeting! And if you have not signed up yet, you can still register.
Last week, I visited the ICANN50 meeting in London. The meeting was held at a location well known to us at the IETF – the Hilton London Metropole. The meeting drew a record 3100 attendees on site, ranging from governments to businesses, civil society, and technical community. The hot topic of the week was the transition of NTIA’s stewardship of the IANA functions to the global multi-stakeholder community. This topic was discussed at almost very meeting during the week.
On the last day of the meeting, Patrik Fältström and I moderated a session that focused on the transition. The NTIA made its announcement in March, and there has been a lot of discussion about how to go about the process in the months that followed. In late April, the IAB made a widely recognised contribution on the topic. In June, ICANN published an outline of the process that will be used for the transition, known as “the plan for the plan”. Among other things, the process calls for the establishment of a Coordination Group to assemble a proposal from components provided by respective communities. The final proposed plan should be delivered to the NTIA by September 2015.
Patrik and I believe that the real work in moving forward with planning IANA stewardship without NTIA should now begin. A big part of this work rests on the individual communities (e.g., IETF, RIRs, gTLD and ccTLD communities) that are the IANA functions customers. Our session discussed expectations both for the communities and the community’s expectations of the Coordination Group moving forward.
The session was organised as a set of invited introductory talks around a number of topics, followed by open discussion with the community. The introductory talks were given by members from various constituencies, Alissa Cooper from IETF, Heather Dryden from the Government Advisory Committee (GAC) of ICANN, Olaf Kolkman from NLnet Labs (for ISOC), and Marilia Maciel from At-Large Advisory Committee (ALAC) of ICANN. All introductory slides are available here and the transcript here.
Patrik and I talked about how IANA works and lessons learned so far in the three-month process. We also pointed out that the transition is not rocket science: for instance, we at the IETF are likely pretty close to what is required for the transition, with our agreements, role definitions, groups that track the relationship, and so on. Alissa talked about the role of the communities vs. the coordination group, which is an important topic for us at the IETF, as the IAB’s model for evolution of IANA is that the IETF can control its own destiny.
The session ended with with an hour of community discussion in the room and from multiple remote hubs. My summary of the input that we heard was as follows:
There is a need for continuity in the transition, as the Internet and the registry and other systems are operational. The transition needs to be an adjustment of the existing mechanisms, rather than replacing them with new organizations and mechanisms.
Accountability has been a big topic for debate at ICANN. But for the purposes of the transition, what matters are those aspects of accountability that relate to the IANA functions. And those aspects need to be addressed in the transition. There are other aspects of accountability in the ICANN system that may require a different and longer process.
We should strive for diverse participation in the Coordination Group, but not employ strict geographic assignment.
The role of the communities is key in the process, and the coordination group is only for coordination. It is not the centralised place for designing the transition solution.
The room supported this summary. Interestingly, this support was measured with the first-ever ICANN consensus hum 🙂 (see RFC 7282)