In March the US government announced their intent to move their role in overseeing the IANA system to the Internet community. Since the announcement, the communities impacted by IANA functions have been working hard to develop a transition proposal.
The IANA transition Coordination Group (ICG) was set up to coordinate the process. However, most of the responsibility for the work resides in the communities served by IANA, such as ICANN global names and country-code name communities, the regional address registries (RIRs), and the IETF. The ICG requested these communities to make proposals for the parts that they are affected by.
The IETF’s response to this request, our draft proposal is now in IETF-wide review. The IANAPLAN working group was created for the purpose of developing a proposal, and the work started in August. The draft proposal is relatively straightforward, owing to the stated IETF community opinion that the existing arrangements between IETF and ICANN should be continued. But the details needed to be written down, and consensus found to support the proposal.
It was clear that everybody wanted a stable, secure, and well-working IANA oversight system for the IETF. We had some disagreements about the methods to achieve this, however, but talking through these issues helped everyone better understand the different viewpoints. In the end, I thought the working group had found quite reasonable agreement. And the chairs and the document shepherd have concluded that the WG has sufficient consensus to move forward to the broader review.
The proposal is now subject to review from the IETF community, in the Last Call process. The purpose of last calls is to identify any latent issues (while, of course, respecting the discussions and conclusions already stated in the working group process). The last call runs until December 15th, and after that the IESG will determine if it is ready to be approved. Some changes may also be made to documents in this stage, depending on IESG and community comments.
Jari Arkko, IETF chair
Just after the IETF 90 meeting last July, I posted this “YANG Takes Off in the Industry” blog.
One IETF meeting 91 later (just 2 weeks ago), the trend is confirmed: a big wave of YANG models is coming!
This big wave was confirmed by Dave Ward, in his “Open Standards, Open Source, Open Loop” talk to the IETF community.
New YANG models are not only seen in the OPS area, but also in the RTG, INT, TSV, and SEC areas. In total, about 20 working groups, 65 YANG model Internet-Drafts currently active, and 43 of these are at version 00. Granted, there are some redundant drafts, while the community organizes itself, but this shows a willingness to build data models with the YANG language [RFC 6020]. There are two types of models. First, the protocol-specific YANG models: For example QoS, ISIS, OSPF, MPLS, Traffic Engineering, 6Tisch, Multicast … to name a few. However, the end goal is for the operators to create services out of these building blocks, and some services YANG models start to appear at IETF, such as L2VPN or L3VPN. Some (services) YANG models were discussed in the different BoFs: In Abstraction and Control of Transport Networks (ACTN), in I2NSF (Interface to Network Security Functions, and also in the SUPA (Shared Unified Policy Automation) bar BoF
The second YANG Advice and Editing Session, was again a success with 15 YANG models reviewed by the YANG doctors. I was extremely pleased to see one operator, with a “newcomer” badge, present at this session to get feedback on his YANG model. Note that, in preparation for the review of all these YANG models, the YANG doctors team recently expanded.
Finally, a new working group, LIME, has been created just before the IETF meeting, focusing on YANG data model(s) for generic layer-independent and technology-independent configuration, reporting and presentation for Operations, Administration, and Maintenance (OAM) mechanisms.
It’s great to see some YANG traction within the IETF, and in the industry. My prediction is that more YANG models will follow. Many more, and not only from the IETF but from different Standard Development Organizations and consortia. Now it’s time to organize the coordination of all these YANG model so that the big wave doesn’t turn into a tsunami.
Benoit Claise, OPS Area Director
Our meeting in Honolulu is over. How did it go? Let us know. In the following I have collected some of my own observations.
I thought the meeting and all facilities worked very well this time. All the practical arrangements worked smoothly. An easy place to have both our official meetings and all those hallway and side discussions that many of us find important. I would like to thank all the volunteers, our contractors, the host Cisco, all the sponsors, and you all for making the meeting a success. Thank you! I also want to thank Cisco for the great social event and NBCUniversal for the welcome reception. Both events were very much appreciated by all the attendees.
We had 1100 participants from 50 countries. That is a good turnout, though slightly less than we predicted. This may be partly explained by some visa trouble for Chinese participants that we reported earlier. We’ve also heard other similar meetings in the industry having issues this fall. We are doing everything we can to avoid getting into a similar situation in the future, but there are no easy solutions.
We also had seven remote hubs throughout Latin America, which was great. And we had 25 presentations held by people attending remotely, a new record! Remote attendance will be growing in the future, of course due to technologies that IETF and others have worked on. This is good, because it enables more participation, and lowers barriers to being involved in the IETF.
But what about our technical work? Here are some of the highlights from my perspective:
- Privacy – Our work on the difficult problem of improving security and privacy of the Internet continues in multiple working groups. For me the highlight of this effort was the newly chartered DPRIVE working group that addresses DNS privacy. Their meeting systematically walked through various design alternatives to allow DNS queries to be done in a private manner.
- Encryption – The Internet Architecture Board (IAB) released a statement indicating how important confidentiality is for Internet communications. Of course, while that gives a direction for us to aim, we already know from past experience that getting to the end result is not easy. We need deployable security solutions, we need technology that enables the network to do its work (addressing, caches, …) while protecting privacy, and we need algorithms that we know we can trust. Hard work ahead!
- Video codecs – The RTCWeb working group made some long-awaited progress on the question of what codecs are required for implementations. In the proposal, some system components still have to implement multiple codecs, and the decision itself is still in the process of being confirmed on the mailing list. However, if confirmed, it will greatly help interoperability.
- IANA transition – The IANAPLAN working group had a very active discussion about the IETF’s transition plan regarding the role of US government in overseeing IANA services. As often happens in IETF meetings, a broader set of participants follow the discussion during the meeting. The participants were clear on how they wanted the proposed plan changed, with less focus on contractual details and more focus on maintaining the current operational model.
- Open source – Dave Ward gave an excellent presentation about working with standards in an increasingly open source world. We’ve certainly recognised this in the IETF, but there’s so much more that we could and should do here. Dave’s presentation slides are here and a recording of the presentation here.
- Data models – One clear growth area (and one with a lot of open source relations) is data models, building schemas of information that can be used to control and monitor routers and other devices.
We also used the IETF network to run a MAC address privacy experiment. Could MAC addresses change, and what implications would that have for the rest of the traffic? Juan Carlos Zuniga describes some of the learnings in his blog article. I would love to see more experiments like this in future IETF meetings. If you have an idea, let us know about it!
And what’s next? Dallas, in March 2015. In the meantime, back to the mailing list for the important work on many of the above issues.
There is also a short video version of this summary here.
Jari Arkko, IETF Chair
This week at IETF91 we carried out an experiment to randomize Wi-Fi MAC addresses of users to improve privacy. MAC addresses used in over-the-air communications by protocols such as the IEEE 802.11 WLAN have been identified as privacy risks that expose individuals to unauthorized tracking. As part of the joint collaboration between IAB/IESG and IEEE 802, and the work carried out by the IEEE 802 EC Privacy SG, an experiment was suggested to assess implications of MAC address changes on Layer 2 and Layer 3 protocols.
A parallel network was setup for this experiment. An ietf-RandPrivMAC SSID was broadcast during the meeting and users were asked to run some scripts in their laptops to randomize their MAC address when connecting to this network. The network was isolated from the rest of the IETF meeting by means of using a different VLAN with separate DHCP and switching infrastructure. Statistics were captured and a detailed analysis will be performed over the next few days. Nevertheless, preliminary observations show that several client drivers support this technique, no major changes are required on the network configuration, and the probability of address duplication in a network like this is negligible. This is the first time we try this technique outside the lab, and now that we know more what to expect we can fine tune the setup in the future to have a better understanding of the different practical implications.
IETF is the best place to carry out an experiment like this, as users are not only willing to participate, but also provide active support and very smart observations. We received a number of suggestions about how to make the experiment more interesting, from adding support for more client devices to providing guidelines about improving DHCP allocations and usage of MAC addresses in IEEE protocols. The IETF NOC team was instrumental and extremely helpful before and during the experiment. Overall, this has been an excellent learning experience and we believe it is a first step in the right direction to provide better privacy for users of this widespread technology.
Juan Carlos Zuniga
New to the IETF, or exploring new topics for your work? I wanted to point people to the various introductory sessions and materials that we have about the IETF and Internet technology.
On the Sunday before each IETF meeting, we traditionally hold a number of tutorial sessions. For IETF-91, the sessions can be found here. The tutorials are run by volunteers, as a part of the EDU team. The volunteers are often the best experts on a topic, and the sessions are well worth following, even for us who have been at the IETF for a long time.
For someone getting involved with the IETF, the newcomer’s page on our web site is the best place to start. Among other things, you will probably end up reading the Tao of the IETF (also available in several languages). And I particularly like the video that introduces what goes in IETF meetings, or various other videos on the IETF YouTube channel.
Many of the tutorials are also available as videos that you can watch any time. The IETF- and process-oriented ones are here, and the technical topics are here.
I also wanted to thank the EDU team, all the volunteers, ISOC, and everyone who has been involved in setting up the above materials, holding presentations, and sharing their expertise. Appreciated. Thank you.
Jari Arkko, IETF Chair
I wanted to welcome everyone to the 91st IETF meeting that is starting tomorrow, November 9th, here in Honolulu, Hawaii. I also wanted to welcome our remote attendees!
The host for this meeting is Cisco. I am very happy about their support! Our connectivity sponsor is Time Warner Cable, welcome reception sponsor is NBCUniversal, and the other sponsors are bright house networks, Cable, CableLabs, Cablevision, Charter, Comcast, Cox, and Rogers. Thank you! Without your support this meeting would not be possible.
The meeting agenda can be found here, the floor plans (which you will need!) are here, remote attendance tools here, and presentations online are in here. And if you are on site, and for some reason have not registered, you can just walk up to the registration desk and register.
I have written about interesting new work in a blog article, Jim Martin has written about what it took to build the IETF network for the meeting in his blog entry (the instructions for in-room Internet are also useful).
Also, various ISOC people have written excellent guides to where discussions are ongoing at the IETF:
New to the IETF or exploring new topics? On Sunday there are many tutorials, all held by volunteer experts. Well worth attending! We also have a lot of material that you can watch and browse at any time, on both the IETF as well as Internet technology. Take a look at the materials that we have gathered.
Jari Arkko, IETF Chair
We wanted to let you know that a number of Chinese participants have had trouble for getting visas to this meeting. Ray Pelletier and several others* have made a heroic effort to improve the situation by exerting any influence they might have on various embassies, the state department, even congressmen. We cannot thank you enough!
This effort was initiated after we learned that three Nomcom members did not have visas, and that polling registered Chinese participants, 25 other people were in a similar situation. The situation has now improved greatly, although several people were still waiting for visas a couple of days ago (including one IAB member). But a handful will not get their visas in time.
Our meeting is about to start, and by all accounts looks to be very interesting and successful. The meeting is well attended, we will be in a beautiful place, and we have a lot of support from many volunteers, hosts and sponsors. We look forward to working with you all!
But we did want to point out that the visa situation is bad. Imagine what it would feel like to be a week or two away from having to fly to a meeting and not having a visa. Or not getting one at all. We wanted to convey how much the IETF leadership cares about this situation. Looking into the future, we need our key people in the meetings, and we need to minimise the uncertainty involved in travelling to the meetings! We believe this issue is a key problem for our efforts in ensuring that the IETF is an accessible forum with broad participation from everyone who wants to work on Internet standards.
Chris Griffiths, IAOC Chair, Michael Richardsson, Nomcom Chair, and Jari Arkko, IETF Chair
*) You know who you are. Thank you.
The network for the IETF is a bit of a unique beast. It has elements of a service provider network, an enterprise network, and a campus network, has to be setup in just a few days, and has some of the most … ahem … knowledgeable, users on the Internet. It also is built entirely of donated equipment, using donated circuits with a largely volunteer team.
Both for this meeting and the next one in Dallas, our friends at Time Warner have generously donated two 1G Internet links, providing fast IPv4 and IPv6 connectivity for all attendees.
The equipment we’ve been using for the last few years have been routers donated by Juniper (Thanks Juniper!) and switches and wireless equipment from Cisco. This year, Cisco has generously made a huge donation to upgrade the switching and wireless gear and setup the IETF for the next few years. We’ve upgraded all the switches to handle modern software and support a 10G core. We’ve also swapped out all the older 802.11n capable wireless access points for the newer, faster and more capable 802.11ac units. We’ll also have a new server infrastructure for 2015. Many thanks to Dave Ward, Hoang Pham, Joe Clarke, and Shaun Jones of Cisco for all their help making this donation a reality!
Bringing this new kit to Hawaii presented a few challenges. While having lots of new gear is exciting, having a solid IETF network is the ultimate goal. We shipped both the new gear, plus a core of the old kit “just in case”. We’re using tried and true configurations, making as few changes as is reasonable to meld this pile of shiny kit into the IETF network we all know. The NOC team has been onsite since Monday, and as expected, the road has been a bit bumpy and there are a few things to file, but everything seems to be working. In just an hour or two at Noon on Friday, we’ll be activating the IETF presence in the guestrooms (the ietf-hotel SSID and a somewhat unique way of getting wired access … look for mail to 91all), as well as the public space (the ietf-public and ietf-public-a SSIDs). The Hilton technical staff have been a great help to get this all working!
As usual, the Terminal Room and the help desk will be opening on Sunday afternoon. Please come by and let us know if you have any questions or issues, or submit them to email@example.com. It’s certainly possible that with all this new equipment that there may be some incompatibilities and we’d love to know about them as early as possible!
Finally, let me take a moment to thank our NOC team. We’ve got volunteers from all over the world that donate huge amounts of time, expertise and hard work to make the network what it is. We also have the deployment help of our contractor VeriLAN, who has been a great partner for many years. If you see any of the NOC in the halls, please thank them for everything they do!
The IETF meeting in Honolulu starts a week from now. This is the second time the IETF goes to Hawaii, the previous time being 25 years ago; the t-shirt design from back then is shown above. But now we get to the second episode of nerds in paradise. I am looking forward to it!
But what are the hot technical topics that we will cover in the meeting? Everyone has their favourite topics, but the following ones are the most interesting ones from my perspective:
- Software-defined networking, virtualisation, and data models is a large cluster of current IETF work. The work relates to making network functions virtualised and network nodes programmable. The industry is only in its beginning stages of this big transformation. In Honolulu, the SDN and NFV research groups, the I2RS, NVO3, SPRING, NETMOD and SFC working groups, and the I2NSF and ACTN BOFs discuss this topic. In addition, there is a lot of work on data models (such as this draft for BGP) in various working groups, with the intent to make it possible to program the network.
- Privacy. The new DPRIVE working group will be designing solutions to make DNS traffic more private than it is today. The UTA working group continues its work to specify best practices for using TLS in applications. They have already published a document on attacks, and are now last calling their best practises document. The HTTPBIS working group continues their discussion of the upcoming HTTP 2.0 standard. One of the topics in the meeting is how the new standard should utilise opportunistic security.
- Deterministic networking is about the ability to guarantee network throughput and delay for special applications, such as industrial control or video transmission. Deterministic L2 networks exist. The DETNET BOF proposal asks whether some L3 work is required.
- Efficient multicast forwarding architectures. The bit-indexed explicit replication (BIER) BOF suggests a new architecture for multicast forwarding.
- Archive media types (ARCMEDIA). This BOF asks whether a new top-level media type is needed for archive formats.
- Transition of USG role in IANA to the community. The IANAPLAN working group is the place where IETF develops a plan for this transition. A working group last call for the proposal is currently ongoing. A lot of activity is going around this topic in the world. See here or here for some discussion of the overall situation.
- Data-center latency. A new research group is proposed for this topic.
We also have a Code Sprint on the Saturday before the IETF. Join us to write the tools that you think we need when making standards.
If you have not registered to the meeting yet, please do so at the meeting page. I would also like to thank everyone who has been involved in setting up the meeting, and in particular I want to thank our host Cisco and the sponsors, Time Warner Cable, NBCUniversal, bright house networks, Cable, CableLabs, Cablevision, Charter, Comcast, Cox, and Rogers.
Jari Arkko, IETF Chair