Many of us have been working over the last two years on a small change to the way the IANA functions are managed. Today, IANA is operated by the Internet Corporation for Assigned Names and Numbers (ICANN) under a contract from the US Department of Commerce (though the National Telecommunications and Information Administration, or NTIA). But the plan has always been for the NTIA to step out of that role, and about two years ago they asked the Internet community to put together the detailed proposal for how to complete the plan.
We have now passed an important milestone. The various operational communities — for names, numbers, and protocol parameters — have come together and produced a unified proposal under which IANA stewardship can be performed by the Internet community. The proposal keeps in place the same operational realities that have supported the Internet’s enormous growth since the 1990s. The arrangements are really the same ones that have always been in place: they work, and there is no reason to change them. The NTIA has the proposal, and is now following the procedure to evaluate it.
The proposal is yet another piece of evidence that the multi-stakeholder way works. We’re not done yet, of course, but we are very happy that the next phase of the transition process has begun.
My previous blog post was about the IETF BoFs, but there are also new meetings in the research arm of the IETF, the IRTF. The proposed Measurement and Analysis for Protocols (MAPRG) research group is meeting for the first time in Buenos Aires. Another proposed research group, the Network Machine Learning (NMLRG)is also meeting in Buenos Aires, and this is their second meeting.
This is what the planned charter says about the role of the MAPRG:
Our Internet has grown into something that differs from what was envisioned. Its protocols sometimes operate in an environment other than than that for which they were designed. For instance, some network elements treat some protocols differently than others and those protocols themselves are sometimes reused and abused in ways initially unforeseen. The Measurement and Analysis for Protocols (MAP) Research Group (RG) explores such phenomena by measurement with the aim to inform protocol engineering and practice.
Many protocol engineering efforts in a standards development context, as well as best practices for the operation of IETF-defined protocols, can benefit from insight provided by Internet measurements of various kinds. Likewise, Internet measurement research efforts can stand to gain from contacts with the IETF. The Measurement and Analysis for Protocol Engineering (MAP) Research Group aims to provide a forum for interchange between these two communities.
And this is what the NMLRG plans to do:
Machine learning technologies can learn from historical data, and make predictions or decisions, rather than following strictly static program instructions. They can dynamically adapt to a changing situation and enhance their own intelligence with by learning from new data. This approach has been successful in image analysis, pattern recognition, language recognition, conversation simulation, and many other applications. It can learn and complete complicated tasks. It also has potential in the network technology area. It can be used to intelligently learn the various environments of networks and react to dynamic situations better than a fixed algorithm. When it becomes mature, it would be greatly accelerate the development of autonomic networking.
The Network Machine Learning Research Group (NMLRG) provides a forum for researchers to explore the potential of machine learning technologies for networks. In particular, the NMLRG will work on potential approaches that apply machine learning technologies in network control, network management, and supplying network data for upper-layer applications.
I think these are very exciting topics! Hopefully you all can join the meetings of these groups! The MAP RG is currently scheduled for Monday 15:50-17:20, but schedules may still change. The NMLRG is currently scheduled for Thursday 10:00-12:30. Registration for the meeting is open at the IETF meeting page. It is also possible to follow and participate the meeting remotely.
With the preliminary agenda just published (or soon will be), I wanted to report what Birds-of-Feather (BoF) sessions there will be at IETF-95. This time there is quite a lot of work following up on a recent IAB workshop on the effect of encryption on network operators.
The BoF sessions are one way for IETF to adopt new work, typically discussing a problem or a need for new standards. The IESG has approved these sessions for the meeting.
SPINOFFS FROM THE MARNEW WORKSHOP
These topics are results of the MARNEW workshop held in September 2015 (minutes) to determine what could be done to help operators perform network management, even when the traffic carried in their networks is becoming increasingly encrypted.
Limited Use of Remote Keys (LURK). Communication protocols like IPsec, SSH or TLS provide means to authenticate the remote peer. Authentication is based on the proof of ownership of a private key. Today, the deployment of services on the current Internet largely relies on multiple distributed instances of a service and CDNs. Can a service be offloaded to a CDN without giving the CDN also a complete control of a private key?
Alternatives to Content Classification for Operator Resource Deployment (ACCORD). This proposal focuses on the ability of radio-based mobile access networks to perform some traffic classification for the purposes of managing radio resources efficiently, without exposing any privacy sensitive information. The increased use of TLS and other encrypted transports makes these types of classification attempts more difficult. This proposal suggests that it would be useful to examine both what specific network treatments need to be elicited for the efficient operation of radio access networks, if any, and what the minimal communication to elicit those treatments for encrypted traffic would be.
ADMINISTRATIVE
IAOC Meeting Venue Selection Criteria & Procedures (MTGVENUE) – the community has expressed a concern regarding the process followed when selecting a meeting venue. The IAOC and IAOC Meetings Committee have undertaken to document that process (currently in preparation) in an internet draft for community discussion. The IAOC would like to discuss it with the community. The draft will be posted soon.
NETWORK PLUMBING FOR THINGS, VEHICLES, AND HOMES
Intelligent Transportation Systems (ITS) – the goal is to standardize and/or profile IP protocols for establishing direct and secure connectivity between moving networks. A draft charter for the potential new working group has been suggested here.
Low-Power Wide Area Networks (LPWAN) – this proposal deals with long range low-power and lossy networks, many of which operating in license-exempt bands. Existing pilot deployments show promise, but the loose coupling with the Internet makes the device management and network operation complex and specific. As of today, there is little to no use of IETF technologies in LPWANs at large, and there is a need to evaluate their applicability.
Babel routing protocol (BABEL) – this distance vector routing protocol has been described in detail in RFCs 6126 and 7557, which are both Experimental. The goal of this proposed BoF is to discuss whether it is necessary to create a standards track successor these RFCs, including discussing what technical topics need attention as part of advancement.
NAMING
Alternative Resolution Contexts for Internet Naming (ARCING). While the most common Internet names by far are those which are part of the domain name system, that set of names is not the whole. There are also independent naming and resolution contexts, such as onion routing or multicast DNS, Handles, and proprietary names such Twitter handles. This creates some ambiguities, and the proponents of this effort believe that the IETF should describe the architectural issue and document best practices for identifying alternative resolution contexts.
Some time ago I mentioned the Internet of Things Semantic Interoperability (IOTSI) workshop organised by the IAB. This workshop is important for the work on application data formats, semantic definitions, and interoperability in the Internet of Things space. Can we ensure that this work gets completed and aligned across the industry?
I wanted to provide a small update, as the paper submission deadline has closed. The workshop proved very popular, with over 50 high-quality submissions from a diverse set of organisations and covering many different angles into the topic.
The accepted papers are available from the workshop page. Do read them, as they provide many interesting thoughts on where various standards organisations are on this topic and what problems remain.
This blog post is not about technology. A while ago I asked for volunteers to help us understand some of the non-technical changes around the IETF. Some of these changes may affect how we should run our operations: changing participation, changing forms of co-operation, changing landscapes in the area of standards organisations, open source, and so on.
My goal was to set up a design team. This effort was inspired by involvement in various decisions that the IETF leadership has to take part in. I find myself often wishing to be able to draw more on the understanding trends and their impact on the IETF.
Alia Atlas, Avri Doria, Tobias Gondrom, Olaf Kolkman, Steve Olshansky, Benson Schliesser, Robert Sparks, Russ White joined the team (thank you!) and the first result from the team is now available as an Internet Draft.
You can read the full draft here, but I have copied some words from the abstract below:
While most of the work in the IETF is technical, the IETF should and does regularly examine itself, including its processes and goals, to determine if the technical community is truly serving the larger network engineering community effectively. Changes in this area tend to be incremental, as is fitting for an organization with decades of experience and history in developing and managing the process of building technical specifications.
The rapid and ongoing changes in the world have recently caused a number of IETF participants to examine the current processes and operation of the IETF, particularly in the context of the culture of the IETF. This memo discusses some cultural and global trends in relation to the IETF’s operating environment, how these trends might affect the operation of the IETF, and notes some topics for further exploration.
This memo is also input for discussion that the IETF community should have.
The memo has no particular official standing, nor does it claim to represent more than the authors’ thinking at the time of writing.
But our opinion is just that — our opinion. What do you all in the IETF community think about this? What changes do you foresee? Please direct discussion about this topic to the [email protected] mailing list.
As a side note, if you are interested in the picture, it is of an IESG meeting in 2010, held in Second Life. The setup was pioneered by Lisa Dusseault. And at least for me, the experience far surpassed phone conferences, at least as good as today’s high-quality Internet conference calls can be. The IETF also had its own island in Second Life. Where can we take the IESG or the IETF in 2016?
Thinking of some new ideas that could be worked on by the IETF? This Friday, February 19th, 23:59 UTC is the deadline to submit proposals for what we call Bird-of-a-Feather (BoF) sessions at IETF-95 in Buenos Aires.
BoFs are not the only form of adding work to the IETF program, of course. Existing working groups take smaller new pieces of work in their area of work all the time, and in clear cut cases working groups can created even without a BoF.
Our steering group, the IESG, will decide what BOFs are ready enough to go forward on February 26th. Some BoFs are intended to be, for now, discussion meetings. Others intend to lead to the creation of a working group, if the community feedback is positive.
The current proposals that we have include the following:
Low-Power Wide Area Networks (LPWAN) – this proposal deals with long range low-power and lossy networks, many of which operating in license-exempt bands. Existing pilot deployments show promise, but the loose coupling with the Internet makes the device management and network operation complex and specific. As of today, there is little to no use of IETF technologies in LPWANs at large, and there is a need to evaluate their applicability.
Alternative Resolution Contexts for Internet Naming (ARCING). While the most common Internet names by far are those which are part of the domain name system, that set of names is not the whole. There are also independent naming and resolution contexts, such as inion routing or multicast DNS, Handles, and proprietary names such Twitter handles. This creates some ambiguities, and the proponents of this effort believe that the IETF should describe the architectural issue and document best practices for identifying alternative resolution contexts.
Babel routing protocol (BABEL) – this distance vector routing protocol has been described in detail in RFCs 6126 and 7557, which are both Experimental. The goal of this proposed BoF is to discuss whether it is necessary to create a standards track successor these RFCs, including discussing what technical topics need attention as part of advancement.
Limited Use of Remote Keys (LURK). Communication protocols like IPsec, SSH or TLS provide means to authenticate the remote peer. Authentication is based on the proof of ownership of a private key. Today, the deployment of services on the current Internet largely relies on multiple distributed instances of a service and CDNs. Can a service be offloaded to a CDN without giving the CDN also a complete control of a private key?
Alternatives to Content Classification for Operator Resource Deployment (ACCORD). This proposal focuses on the ability of radio-based mobile access networks to perform some traffic classification for the purposes of managing radio resources efficiently, without exposing any privacy sensitive information. The increased use of TLS and other encrypted transports makes these types of classification attempts more difficult. This proposal suggests that it would be useful to examine both what specific network treatments need to be elicited for the efficient operation of radio access networks, if any, and what the minimal communication to elicit those treatments would be.
I cannot think of a better example where interoperability is important than the Internet of Things. Without interoperability, lights won’t work with the switches, sensor’s can’t be read by your smartphone, and devices cannot use the networks around them.
And of course, the IETF along with other relevant organisations is working on those standards. But there’s work left to do.
I wanted to point out a particular area where further work on interoperability would be useful. Devices that operate on their own without human supervision need to automate all their operations. As a result, it is important that the devices can not only connect to the appropriate radio and IP networks, but they also need to work well with others with regards to transport and application protocols, security, and data that they pass around.
The IAB is organising a workshop in San Jose, California, March 17-18, 2016 on semantic interoperability, relating to standardising the formats and semantics of data that is carried in IOT applications. As the workshop announcement notes:
With the expansion of the Internet of Things (IoT), interoperability becomes more and more important. Standards-developing organizations have done a tremendous amount of work to standardize protocols to simplify implementation and to lower the cost of IoT products. As a result, new protocols were developed, existing protocols were combined in new ways, and lightweight profiles were defined.
At the application layer, interoperability is not yet mature; the work on data formats (in the form of data models and information models) has not seen the same level of consistency throughout various standardization groups. Examples of standardization efforts in this area include the work by IPSO on their Starter Pack, the Cluster Library developed by the Zigbee Alliance, the OMA LWM2M, or the UPnP Management and Control:1 specifications.
One common problem is the lack of an encoding-independent standardization of the information, the so-called information model. Another problem is the strong relationship with the underlying communication architecture, such as an RPC or a RESTful design. Furthermore, different groups develop similar concepts that only differ slightly, leading to interoperability problems. Finally, some groups favor different encodings for use with various application layer protocols.
A call for position papers is ongoing until February 22. Please join us!
As we work on the day-to-day tasks needed to make the Internet work better, or even as we look back over last year and gaze ahead to the year to come, from time-to-time it is useful to consider our work on timescales that are a bit larger.
This week marks the 30th anniversary of the meeting that became the very first edition of IETF meetings now held three times per year. On 16-17 January 1986 in San Diego, California, 21 people attended what is now known as IETF 1. Some names and topics found in the proceedings [1] from that meeting are still familiar to current IETF participants! Although IETF meetings now regularly bring together more than 1000 participants, the goal of addressing challenges to improve the network and the principle of meetings being a means to the end of getting work done remain the same.
Of course, even the ~50x growth in IETF meeting participation is dwarfed by the growth of the Internet itself. In 1986, there were a few thousand hosts in the Internet, and today there are over three billion users, many of them using mobile devices [2,3,4]. This incredible growth is a testament to the flexibility of the Internet architecture, but also to the engineering effort that has been put in over the years by IETF participants and many others. Today’s Internet users employ many technologies that have become IETF standards during our 30 years of existence. Such as HTTP and TLS that form the basis of the web communications, or RTP and other protocols that enable real-time multimedia conversations. And many others.
Skipping ahead a bit from 1986, the initial specification for IPv6 was published 20 years ago [5]. A motivation for IPv6 was that IETF participants understood the long term need for more Internet addresses to make sure the Internet continued to “work better”. While IPv6 deployment has initially languished, the situation has recently changed. Observed use has been doubling in recent years—and it just recently passed 10% globally [6]. Some leading economies are even further; US is at 25%, for instance. Of course there is still much work to do, but the fact that an “upgrade in place” of a fundamental component of the global network connecting billions of people seems possible is quite encouraging!
Looking ahead from today, it seems impossible to forecast with any certainty what the Internet will look like 30 years into the future. Yet, in the nearer term, we know that billions more people will be connected around the world over the next few years, and that the Internet will also provide connectivity to objects in our environment as information technology is used to enhance those objects.
Much work is needed to bring about these changes. There will also be challenges, such as privacy of our communications or interoperability in new applications. The Internet is also used in even more diverse environments and applications, and developed in diverse ways, such in open source projects. Technology evolution needs people who understand these environments!
Connection to running code, open standards and transparent, evolving processes have been foundations for the IETF and the Internet over the past 30 years. I believe those, and constant attention to improving them, are key to future success. While we will have more meetings, I expect their form, too, will evolve to meet the needs of participants, preserving their role as a means to an end, and not the ends in themselves.
With the year closing, I wanted to make a post highlighting some of the events and hot topics of the year. And say a few words about the challenges that lie ahead.
Lets start with technical and big-Internet affecting issues. When I talked with the steering group about the events of the year, these came up:
The publication of HTTP/2 in RFC 7540 [1]. This is the new protocol that supports web traffic in an efficient and secure manner, widely adopted in software and increasingly used in Internet [2,3,4].
Publication of the DNS privacy problem statement and subsequent work on potential solutions to address this problem [5,6].
More generally, eighteen months ago we made a promise that the IETF would understand the implications of pervasive surveillance on Internet technology [7]. We are starting to deliver on that promise, and as a result, are better equipped to look at improvements.
The IETF took on data modelling work for network management, mostly focused around YANG and various standards organisations and open source efforts that use these models [8,9].
We chartered new work to extend security protections to vulnerable parts of the real-time communications stack, such as the security work in PERC, STIR and the continuing work in RTCWEB WGs [10,11,12].
The IAB worked with operators to understand the implications of Internet traffic being more commonly encrypted [13].
We started supporting IEEE efforts on deterministic networking using IETF protocols for broader geographical coverage [14].
But there were also more internally oriented events for the IETF. For me the big thing was focusing more on open source and bringing back the running code aspect to the IETF. Our Hackathon events have now seen their first year, and grown to a successful ~100 person event. We are looking forward to the second year, and the next event will be April 2-3, just before IETF-95 in Buenos Aires [15].
We also re-organised the IETF areas, creating the new Applications and Real-time area (ART), and helping the steering group organise its work in a flexible manner on current topics [16].
We also saw development and increased usage of remote attendance facilities through Meetecho and other systems. Did you know that all 2015 IETF sessions are on YouTube [16]?
Here are some of the challenges that we saw coming up:
We need to continue the work on increasing the security of web and e-mail traffic. It will not be easy, and technology can only provide a part of the answers. But we must continue this work, as at least from my perspective the loss of privacy and personal control of information relating to a person is the most critical challenge facing the Internet today. It is also important to consider threats to privacy as a systemic problem, and not something only related to surveillance. The current Internet enables legitimate services to have a lot of privacy-sensitive information, and building ways to minimise exposure would be beneficial to both users and service providers in the long term.
The expanding Internet of Things applications, with their security, privacy, interoperability, and manageability issues is another major Internet future challenge. It is essential, for instance, that interoperable devices can be used to build systems around us, enabling competition and innovation.
We must start work on new tools that help operators to manage traffic in an all-encrypted world.
We need to continue extending management capabilities and security aspects for routing protocols.
The Internet transport protocols are evolving to match current day needs, with respect to security and efficiency. It is likely that a fairly large change will happen in this space, and proposals such as TCPINC or QUIC will change how we think about transport protocols [18,19].
We must accelerate the publication of the standard YANG data models, the challenge being the coordination of all these models.
We need to deliver on our promises to provide the privacy enhancements, real-time communication security tools, and many other topics that the working groups have been chartered to do.
We need to execute the IANA transition, finally. A plan for this transition has been produced by the IETF together with other Internet organisations [20].
What other challenges do we face in the Internet, and are there proposals that you would like to see taken forward to solve them? Let us know on [email protected].
Inside the IETF, one of the key issues continues to be that we remain the most useful place for today’s Internet technologists to work with each other. I’m happy about our reach into more open source folks, our meetings and ISOC programs reaching out to different groups and different regions, but that is only the start. What can we do to make the IETF a better place for you to develop standards that you need?
With this, I want to thank everyone who has participated in IETF projects and wish you happy holidays. We have more work to do, but we should be happy about the things we’ve achieved in 2015. See you next year!
It’s been a while since we’ve had a diversity related update and with the approval of the Anti-Harassment BCP [1] and publication of the Independent Stream Editor (ISE) document, RFC7704 [2] it seems timely. The anti-harassment BCP helps to establish a code of conduct supported in the IESG statement on the same topic from 2013. RFC7704 is an opinion piece from the editors citing issues from the 2011-2012 time period that while still surface on occasion, have seen improvement due to many efforts from IETF participants.
While the IETF has diversity issues, and like any other organization we will have to work on this continuously. In 2012, when these behavior and diversity issues were glaringly apparent to the IETF, the chair, Jari Arkko worked with others to establish a “Diversity Design Team”, of which I was appointed as one of the co-chairs with Suresh Krishnan. The final readout from the Diversity Design Team was given at the IETF 87 Plenary in July 2013 [3], switching the focus to inclusion from diversity. The Internet Society was already working on important programs to increase regional diversity, such as the Fellows and Policy programs, which bring new people from various regions of the world to meetings to introduce them to the IETF. Other efforts, such as the Mentoring Program were established by individual participants in 2013, with Alissa Cooper and Brian Haberman leading the effort with other individuals on the team [6][5]. The mentoring program assists newcomers at their first IETF meeting pairing them with volunteer mentors that guide them through their first IETF and helping them negotiate the new environment as well as procedures. The IETF culture and complex procedures are tough to negotiate and this effort is key toward improving retention of newcomers. The IETF does quite a bit of work from the bottom up, so if a need for something is seen, individuals are welcome and encouraged to drive them as was shown by the mentoring program. The 2013 nominating committee (NomCom), led by Allison Mankin, took it upon themselves to first raise awareness on implicit bias amongst committee members in self assessments, as well as taking steps to have those nominated for IETF leadership positions provide ‘blind’ questionnaire responses as not to identify themselves in the initial selection process. These techniques were supported by research to improve diversity and in from their own research and awareness raised by the Diversity Design Team. The 2013 NomCom appointed 3 women to the IESG and 1 to the IAB. The 2014 NomCom added one more woman to each of those leadership groups as well, matching (at least for the IESG) a prior high point of 4/15 women in the IESG.
On a personal note, I could be considered as part of the 2012 Systers ‘experiment’ mentioned in RFC7704. I was not appointed in that cycle as a Security Area Director (although am currently serving in that role), so I do count in the numbers cited. I bring this up as a few women in the nominating cycle for 2012, like myself, fully expected that the nominating cycle would be a dry run for the following year. While that may sound odd, if all things are equal with two candidates, the NomCom will select the incumbent for a second term. This is a result of the complexities of the position and the amount of time it takes to come up to speed fully in the responsibilities for the role. In the 2012 cycle, Stephen Farrell was an incumbent running for his second term. Stephen and his co-AD at the time, Sean Turner encouraged me to accept their nomination as they wanted the NomCom to have reasonable candidates to select from and they also wanted me to consider a possible appointment the following year when there was no incumbent. Several very qualified IETF participants accepted nominations the following year, 2013. Since I was the Global Lead Security Architect at EMC, this would take discussions with management to determine if there was support for me taking on this time consuming appointment and stepping away from a very important role at EMC. This is not uncommon for many candidates as they tend to be in high-level positions in their organizations. For me, this was quite helpful for the long term process. While there may have been a bias in the 2012 NomCom as cited in RFC7704, at least a couple of the qualified females had no expectation of being appointed that year. Another woman accepted a nomination for an Area Director role just in case the incumbent was selected for a more senior role and the NomCom needed a reasonable nominee/volunteer to appoint. She was also appointed by a subsequent NomCom as she is also well qualified for the role of an Area Director and held senior level positions in her supporting organization.
The IETF leadership has been very supportive of fostering an inclusive environment, which from studies is one of the most critical factors to improving culture and working towards a more diverse environment. In addition to supporting a number of programs, an anti-harassment statement was issued by the IESG in November 2013 [4] and was followed by a consensus draft, on it’s way to final publication as a Best Current Practices RFC [1]. Research has also demonstrated that programs are the most effective way to make progress in an area that will require continued focus for the IETF. We are not perfect but have come a long way in a few years. The IETF will need continued support from the Chairs, IESG, and IAB to foster continued improvements. As such, this consideration is part of the NomCom evaluation process now.
Unfortunately, the problems cited in RFC7704 are not unique to the IETF, so there was plenty of research for the Diversity Design Team to draw from. The final readout from the Diversity Design Team was given at a recorded IETF87 plenary [8] with slides available [3], where the focus was changed to one of promoting an inclusive environment. While the male/female ratios may have sparked the IETF conversations, we also needed to consider regional diversity and ways to develop a pipeline of potential IETF leadership candidates along all measures of diversity. This goal is supported by research that shows the benefits of diverse groups toward improved outcomes and higher collective intelligence of diverse groups versus homogeneous groups. Working Group chairs and Area Directors support these goals by providing training opportunities to individuals and considering diversity when selections are made. If you take the time to watch the recording, you’ll notice an interaction at the end that might be more typical of the cited RFC7704 behavior. While on the surface this may look bad, what followed the plenary demonstrated progress in that apologies and an additional acknowledgement of the problems we face as a community were the result. What this boils down to is that the IETF is not perfect, but we have moved to an environment where bad behavior is called out more readily and have options now such as working with an ombudsmen to have neutral arbitrators, thanks to the work in the anti-harassment BCP [1].
For my own working groups, I do feel they are welcoming environments for all to participate both on the lists and in the room. When an occasional comment that is not appropriate occurs (very rare), it’s been called out immediately and this is a new norm where the behavior is corrected on the spot. It’s progress. If I or other ADs are missing behaviors we should be catching, please let us know. This is a community effort.
