Last week I had the opportunity to participate at the 3GPP plenary meeting in West Palm Beach, Florida, USA, at the invitation of the 3GPP liaison to the IETF, Georg Mayer. In addition to attending meetings of 3GPP’s radio access network group and system architecture group, I had the chance to kick off their new “Wednesday Speaker Club” series with a discussion of how 3GPP and the IETF can cooperate on 5G standardization.
The push towards the next generation of wireless networking technology has been gaining increasing attention and spurring new work across the industry, SDOs, and open source projects. 3GPP participants are investing tremendous effort to define and prioritize 5G requirements to help bring this technology to fruition. They are also working against very tight timelines, with the initial set of 5G standards due to be completed by June 2018. It is therefore both timely and important to identify whether dependencies between 5G and IETF work exist, as well as to identify mechanisms to ensure smooth collaboration.
The IETF and 3GPP have a long history of working together and many successes to build on, including our experience with SIP/IMS, EAP-AKA, and Diameter. Because 5G encompasses a broader swath of folks than those who have been involved in previous joint efforts, I spent part of my time at the meeting introducing how the IETF works, our focus on broadly deployable internet technology, and what we work on. I highlighted some areas of existing IETF work that may be of relevance in the 5G context, including our work on data models, service chaining, deterministic networking, and QUIC (look for more details on these areas in a forthcoming blog post). And I engaged with 3GPP participants around specific strategies to help our two organizations collaborate. You can see my slides here.
The speaker club Q&A session focused on the potential and practicalities of improving collaboration. We talked about the need to have technical experts from each group engage directly with each other (in addition to our existing liaison managers working in both directions), opportunities to provide more introductory presentations in both directions so people not familiar with 5G or specific IETF work can learn more, and ways to identify potential 5G requirements that may yield IETF protocol dependencies early on, even if later analysis in 3GPP reduces the urgency of the need for IETF protocol work.
IETF 99 should serve as a useful opportunity to continue this dialogue and gain more clarity about what specific dependencies we might expect between the 5G plans and IETF work. As noted in my recent post about BOF proposals, we’ll have a slot on the agenda to discuss some of the network slicing work motivated by 5G, in addition to numerous hallway conversations and ad hoc discussions I’m sure. For those working on other aspects of 5G not covered in the BOF proposals and who may be looking for guidance or input about overlaps with IETF work, feel free to reach out to the IAB, the IESG, or our liaison to 3GPP, Gonzalo Camarillo, with questions and comments. Several of us have been working to understand the 5G requirements better and would be happy to hear from you.
BANdwidth Aggregation for interNet Access (BANANA) will be having a working-group-forming Birds of a Feather (BOF) session at IETF 99. BANANA is concerned with providing coordinated Internet Access to a device over multiple links of different types to allow for increased bandwidth utilization, load-balancing and/or higher reliability. The goal of this BOF is to determine whether the scope of the problem is well defined and understood, whether there is a critical mass of participants willing to work on the problem, and whether in general the working group would have a reasonable probability of success if chartered. The BANANA mailing list is here.
IDentity Enabled Networks (IDEAS) will be having a working-group-forming BOF. The goal of this work is to standardize a framework that provides identity-based services that can be used by any identifier-location separation protocol. The new requirements driving this framework go beyond the traditional discovery service and mapping of identifier-to-location for packet delivery. The goal of the BOF is to identify what specific work items are appropriate for IETF standardization. The IDEAS mailing list is here.
Network Slicing (NETSLICING) will be having a non-working-group-forming BOF. In this work proposal, a “network slice” is conceptualized as a logical network comprised of the union of resources (connectivity, storage, computing), network functions, and service functions. Network slicing is a concept garnering much attention as part of 5G standardization and development efforts. The goal of the BoF is to identify whether a shared understanding exists of terminology, decomposition of the problem space, and relationships between the goals of the work and existing protocol work in other IETF working groups. Getting clarity on the priority of relevant requirements from 3GPP is also critical. The relevant mailing list is here.
We also received a proposal for a WG-forming BOF concerning 5G IP Access and Session Management Protocols (5GIP), which was not approved for this meeting cycle so as to provide more time for refinement. The responsible area director and others in the IESG and IAB who have been exploring the overlap between 5G and IETF work will continue to engage with the proponents to help gain more clarity, refine scoping, and understand overlaps with other SDOs.
Finally, we’ll have one newly chartered working group meeting for the first time at IETF 99: DKIM Crypto Update (DCRUP). The DCRUP working group is chartered to update DomainKeys Identified Mail (DKIM, RFC 6376) to handle more modern cryptographic algorithms and key sizes. The mailing list is here.
Looking forward to productive discussions in all these areas at IETF 99.
Emergency calls placed by vehicles involved in a crash can provide significant benefit, especially when vehicle occupants are injured or unable to place a 9-1-1 call themselves. Sometimes called “Advanced Automatic Crash Notification” or “vehicle telematics”, the ability to automatically or manually place an emergency call when a vehicle is involved in a crash has been available for over two decades in the U.S., while the EU has a mandated system called “eCall” that is in the process of being deployed. Recently published IETF RFCs aim to expand the capabilities of such services, and to make them more broadly implementable.
Current U.S. systems are proprietary; some use non-standard in-band modems to send vehicle location and crash data from the vehicle to a call center, which then relays the information to the Public Safety Answering Point (PSAP, also known as an emergency call center). The relaying is done either by non-standard out-of-band data transmission or orally by a service center agent. Other systems place a 9-1-1 call, play a prerecorded message to the PSAP call taker, and use text-to-speech to convey vehicle location and sometimes crash data. The EU eCall system uses a standardized in-band modem to convey vehicle location and crash data from the vehicle to a specialized PSAP, which has a corresponding modem to receive the data.
The IETF has published two documents: RFC 8147 and RFC 8148 that specify how such calls operate using next-generation (all-IP) technology. Vehicles using these RFCs initiate emergency calls either manually or automatically in the event of a crash or other serious incident; the calls carry a standardized set of vehicle location and incident data. Such a call can be routed to a PSAP equipped for this, where the data can be automatically processed and displayed to a call taker at call assignment. During the call, the call taker can request that the vehicle send updated data or perform an action such as flashing its lights.
The IETF developed a generalized mechanism for making data related to an emergency call available to the PSAP along with the emergency call. This mechanism, called “Additional Data”, RFC 7852, allows standardized data “blocks” to be sent in a SIP (RFC 3261) call, either as data in the body of an INVITE message, or as a URL sent in the header which, when dereferenced, yields the data block. RFC 8148 defines a data block for the U.S. “Vehicle Emergency Data Set” developed by the Association of Public-Safety Communications Officials (APCO) and the National Emergency Number Association (NENA), while RFC 8147 defines a block for the eCall data set used in the EU. These RFCs also provide a mechanism for the call taker to request that the vehicle perform an action, such as honking the horn or flashing the lights to allow the responders to locate the vehicle.
Periodic posts on the IETF Blog highlight individuals who serve in IETF leadership roles, people who have recently begun working in the IETF, and organizations that make the work of the IETF possible. Each post aims to describe experiences working within or supporting the IETF. This one is by Mirja Kühlewind, who is an IETF Transport Area Director. You can also see her interview here.
Mirja Kühlewind, IETF Transport Area Director at IETF 98.
I first got involved with the IETF when I started my PhD. A colleague, who was already involved pointed out that it was starting work closely related to my own interests. I attended my first IETF meeting in 2010, when the CONEX [Congestion Exposure] Working Group (WG) held a Birds-of-a-Feather meeting. From then on, it was my own initiative that kept me working with the IETF—I had support from my group, and they usually had enough travel budget for me to attend the meetings.
Three years ago, I became chair of the RMCAT [RTP Media Congestion Avoidance Techniques] Working Group. I only gave that up when I became Transport Area Director (AD). I also was chair of the TCPINC Working Group for half a year. So I became an AD just six years after starting to participate in the IETF.
There are a limited number of people involved in the Transport Area. As soon as I became more active, I was encouraged to take the role of a Working Group chair. Transport AD wasn’t an option until I finished my PhD. Ultimately, though, it worked out nicely because I got stable funding for a project for a little more than two years, which freed me up to consider the position.
The project is generally funded by the European Union, with additional funding by Switzerland for my part, which includes work we planned to bring into the IETF. This would have allowed me to justify spending so much of my time on IETF work. However, since the project funding is coupled to certain research goals, I additionally contacted some companies and they provide support for some of my time and travel budget.
I hope that my experience as AD can count as management experience and that people value it. It’s a good way to improve your skills because you are in a management position where you don’t have any power, but you need to motivate people. For me, it is about how well I manage Working Groups and how well I manage my time. I spend 40% of my time on my AD work and 60% on my research project. It can be a challenge to balance them.
I don’t think that ETH directly benefits from me being Transport AD. But they did get external funding for our project, and that funding had a strong focus on making an impact on industry. So my standardization work may have helped to get the project funded. I don’t think I needed a leadership role for that. Being a Working Group chair was probably enough to show that I had IETF experience, but my AD role of course also makes a good impression.
Everybody’s biggest concern about taking on an IETF leadership role is time management. I do it on a 40% basis. It’s a little stressful, yes, but it is possible. The other reason it’s hard to find people for the Transport AD role is that the right person not only needs support, money, and time for the IETF, but also must have an overview about what’s going on in Transport. I was in the unique position that I was following the same Working Groups that I now carry as AD—it’s no extra effort.
I don’t have a plan yet for when my term is over, but I know I’d like to stay involved in the IETF. When my ETH project is finished, I’ll be a four-year post doc. I’ll need to make a decision about whether to stay in academics or go into industry. If I apply for a job next year, I won’t stand as Transport AD—I can’t ask a new employer to let me spend 40% of my time on the IETF. Even as a professor, it would be hard for me to get 40% of my time off for the IETF.
It’s been an interesting experience, particularly because I’m just starting my career. I’ve learned a lot, and I’ve made a lot of industry contacts that I’ve gotten to know well. I’m grateful—the IETF as a community has provided me with networking opportunities and a source of ideas for research.
Montreal skyline. Photo by Taxiarchos228 CC BY 3.0
The IESG held its annual retreat last week, meeting one day jointly with the IAB and two days on our own in Montreal, Canada. With several new members joining us as of the last IETF meeting, it was a good opportunity for everyone to spend more intensive time discussing hot topics and getting to know one another.
We focused a significant amount of our time together discussing the interaction between increased use of encryption, information available to observers on the network path, and existing operational practices. This has been a frequent topic of conversation in a variety of venues in the IETF as of late, including the MaRNEW workshop, numerous BoFs, charter and document discussions in the QUIC, TLS, OPSAWG, SAAG, and RTCWEB working groups, and on the IETF discussion list.
We examined the topic from a variety of angles. With the IAB we talked about the relative merits of signaling information explicitly versus implicitly, whether replacing implicit signals (about, say, path resources) with explicit signals could be viewed as an architecturally sound design approach, and what the real-world impacts of such a shift might be. We followed that up with discussion amongst IESG members about how to recognize proposals early on in the IETF process that could carry with them significant implications for current approaches to network manageability. As a next step we agreed amongst ourselves to flag such proposals for each other during our bi-weekly informal telechats to increase the likelihood of early cross-area review. Finally, we debated an approach being taken in the security community towards encryption of “all the things” — not things as in IoT, but things as in everything, including identity information, IP-level routing information, operations on data at rest, and a number of other “things” for which the robust application of encryption is still in nascent stages. The discussion teased out differences in perspective about the notion of which entities on the network might be perceived as trusted, or be perceived as attackers, under different network scenarios (e.g., enterprise versus consumer). I can’t say that we ended up with consensus on the topic as a whole, but we did garner greater appreciation of each others’ perspectives, and individual ADs are likely to funnel our conversation into broader community discussions.
IESG at work.
We also spent some time considering ideas to help spur further interaction between standards development in the IETF, development of running code, and open source efforts in the industry. In particular, we talked about ways to allow for working groups to iterate more quickly on YANG models, both from a tooling and a process perspective. We also had Charles Eckel and John Brzozowski join us remotely to brainstorm about future improvements to the IETF Hackathon and Bits-n-Bites events to support more opportunities for participants to collaborate on implementations and showcase works-in-progress. We don’t have concrete details to share on either of these fronts just yet, but we hope to have updates in the near future.
It wouldn’t have been an IESG retreat without some of our more typical housekeeping discussions. This year we touched on a number of IANA-related issues, discussed RFC sub-series, guidance concerning BoFs and side meetings, IETF communications, the future trajectory for remote participation, a suggestion to have more shorter WG meeting slots, and a variety of other issues. All in all, the retreat was a good opportunity for IESG members to gain insights into how we’re each approaching challenges and opportunities big and small in the IETF, and how we can collaborate for the benefit of the IETF community.
Overhead photo of the Circle Interchange in Chicago. Photo by Stratosphere. (CC BY-SA 4.0)
As Routing Area Directors, we have now made it a habit to share some of our thoughts after each IETF meeting. This is a short summary of some of the highlights from the recent one in Chicago.
YANG continues to be a focus in routing and the IETF as a whole. While in Chicago, many working groups had YANG models in their agenda and even specific sessions to review and move the work forward, as was the case for the joint meeting of the mpls, ccamp, pce and teas WGs. The importance of some of this work is reflected in a recent IETF Journal article: Working Group Update: Microwave Modelling at CCAMP.
The netmod WG is making progress with the Network Management Datastore Architecture (NMDA) that will allow access to system-derived state (think of new interfaces learned by inserting a line-card) and cleaner access to operational state versus configuration by having explicit operational and intended datastores. Knowing this future direction allows us to recommend how affected YANG models can be finalized in RFCs.
Along with the Operations and Management (OPS) ADs, we will be sending out precise guidance (thanks to lots of work from the NetMod DataStore Design Team and the Routing YANG Architecture Design Team) that should allow most YANG models to be completed and implemented without delay. To summarize, the models should include all configuration and state in a single normative module to be NMDA-ready. When needed, it should have an optional state module that provides access to the state not otherwise accessible until NMDA and the associated protocol work is implemented. Of course, there are rarely one-size-fits-all rules and this guidance is no different; the exceptions will need to be individually discussed.
In the period before IETF 98 the spring WG has accelerated the work on several of the key documents that will open the way for the segment routing-related extensions defined throughout the area, including use cases and the Segment Routing Architecture document. The chairs opened the discussion about which topics should be the subject of an updated charter for this WG.
The sidr WG is also close to finishing its charter – just a couple of documents remain. While it didn’t meet in Chicago, the participants met as part of the new sidrops WG (in the OPS area). This transition from the development of solutions (origin and path validation in this case) to the understanding that implementation and deployment should now take center stage is critical to this work, but also to the routing area in general. Another good example of the same trend is the trill WG, which is also finishing up the currently chartered work; additional work based on strong operational needs may still be considered.
It is very important for the WGs in the area to keep a close eye on operational requirements, experience and feedback. Besides sidrops, other WGs also deal specifically with the operations of routing-related technology, including grow and mboned.
One of the topics for discussion in rtgwg was “Routing in the DC”, which has several proposals on how to make routing in the data center more efficient, scalable and flexible. This session served as a review of some of the proposals and the opportunity to listen to operators express their needs in response. We look forward to a continued and tighter participation from the operations community.
The detnet WG is making good progress on their Deterministic Networking use cases, architecture, and selecting a data plane. The DetNet Data Plane Design Team gave an update on their work and proposed their DetNet Data Plane solution document is ready for adoption.
The bier WG has made excellent progress with a unified encapsulation that will work for MPLS and Ethernet. The WG took an important step forward in deciding to continue with the WGLC and eventual publication of their work as Experimental RFCs, instead of waiting for deployment experience and pursuing the Standards Track. The decision was aided by the existing ability to do RFC Status Changes without impact to the IANA registries or even the RFC number.
The babel WG had a good discussion on adding unicast hellos to the protocol; several implementers have use-cases that need them. The WG remains small but active with focused technical discussions and an emphasis on experimenting with ideas via implementations before agreeing on changes.
NVO3 discussed the recommendation of its Design Team to select an updated Geneve as the standards-track encapsulation. The consensus is being verified on the mailing list. For the second IETF meeting, nvo3 experimented with meeting twice and having small group discussions on data-plane, control-plane, and security. The WG could use more folks interested in discussing security extensions and use-cases.
While we would like to walk through every WG in the area, this summary is meant to be just that, a summary. If you want more information, please take a look at the IETF 98 Routing Area Working Group High-Level Summary that the WG Chairs put together. Just a few more work items that are worth listing here:
The lisp wg is making progress with the transition of their core experimental documents, RFC 6830 and RFC 6833, to the Standards Track.
The teas wg has been refining the ACTN (Abstraction and Control of TE Networks) Framework and Requirements
IPv6 is not optional – the need to specify, implement and deploy IPv6 is well understood by everyone. During the Routing Area meeting we made a call for the WGs to consider the deployment of IPv6-only networks, and the transition to them from IPv4-only and dual-stack implementations. The intent is to consciously find and fill any specification gaps as vendors and operators clearly work towards that goal.
As Area Directors, our interests go beyond the technical work and into, for example, the topics of outreach and remote participation. To that effect, we are working on efforts to better characterize and eventually measure the participation at remote hubs, from new people to the IETF all the way to established contributors. Also, we are currently involved in other IESG-wide topics including side meetings, BoFs and the application of the Note Well. We welcome any comments or ideas about these topics or others that you think the IESG should be addressing.
Finally, the IETF meeting in Chicago marked the start of Deborah and Alvaro’s second term as Area Directors. We are very happy to be able to continue to work together.
About a month ago I officially took on the role of IETF Chair. My predecessor Jari Arkko noted upon beginning his term as chair just how much can change from one chair’s term to the next. As I’ve started settling into my new role over these last weeks, I’ve been thinking a lot about what has been changing and what has been staying the same in the IETF.
Past and present IETF Chairs with IETF Senior Meeting Planner Marcia Beaulieu. From left, Fred Baker, Jari Arkko, Alissa Cooper, Marcia Beaulieu, Russ Housley, and Harald Alvestrand.
When I first started participating in the IETF, it didn’t take long for me to realize the importance of the IETF as a venue for creating the building blocks of the internet. The significance of the IETF derives from the combination of what we choose to work on and how we carry out that work. Producing core standardized protocols wouldn’t have nearly the same impact on the internet as the existing body of IETF work if it were done behind closed doors, if a single constituency could dictate the outcome, or if broad interoperability were not the main objective. To my eye, the core principles of the IETF process – open participation, cross-area review, and consensus – contribute to the success of IETF protocols in tandem with the design choices and technical trade-offs inherent in protocol design.
Of course, those process features are also often cited as drawbacks of IETF participation. “The IETF moves too slowly,” some people say. “They’re not adaptable,” “they can’t compete with open source,” “the biggest players aren’t interested in consensus.” Sound familiar? Sure, it’s true more often than not that if you’re trying to find agreement among a large, heterogeneous pool of people, that will require a different investment of work and time than deciding things among you and your close group of friends, or hacking something together all on your own. The challenge I see for the IETF in the coming years is to preserve the benefits of the essence of the IETF model while adapting to changes in the industry and the environment. With collaborative styles of engagement flourishing across both open source and standards development, there is a lot of opportunity for synergy.
How can we do a better job of integrating our work with open source development efforts? How can we evolve our tools and processes to align with how software is being developed and deployed today? How might we apply the model of cross-area review and consensus more broadly than to static text specifications? How can we evolve the administration of the IETF to give the community more flexibility and room to experiment? I have my own thoughts about these questions, but far more important are the ideas and efforts of the IETF community.
Personally I think we have many reasons to be optimistic about tackling these questions, based on recent IETF standards development work as well as ongoing community conversations and activities. Over the last several years we’ve seen protocol development efforts deeply intertwined with and informed by running code, with the concurrent development of 10 or more independent implementations, for instance in the case of HTTP/2 and TLS 1.3. We’ve seen broad interest across the industry in the kind of security expertise that has become a hallmark of the IETF, and resulting security and privacy improvements being developed for web, email, DNS, DHCP, real-time, and other kinds of traffic. We’ve seen tremendous energy behind the specification of YANG data models and their integration across the industry into standards processes. And community discussion and activity continues to grow around the IETF Hackathons, use of Github, remote participation, and IASA 2.0.
I’m excited to work with the community on how we face the changes around us while retaining the core of what makes the IETF most effective. We have lots of existing venues for discussions of specific aspects of this, but of course you can always send me your thoughts or post them to the IETF discussion list.
The IETF 98 is now over. This was a successful IETF meeting in multiple ways, one of which is the IETF hackathon, two days of hacking on Saturday/Sunday.
Before delving into the hackathon results, let’s briefly review the YANG « state of the union ». As you know, YANG became the standard data modeling language of choice. Not only is it used by the IETF for specifying models, but also in many Standard Development Organizations (SDOs), consortia, and open-source projects: the IEEE, the Broadband Forum (BFF), DMTF, MEF, ITU, OpenDaylight, Open ROADM, Openconfig, sysrepo, and more. Here is a nice summary presentation “SDN and Metrics from SDOs” by Dave Ward during the Open Networking Summit 2017.
This data model-driven management applies throughout the automation « stack »: from data plane programmability with the fd.io honeycomb open-source project that exposes YANG models for VPP functionality via NETCONF and RESTCONF, to operating systems with the sysrepo open-source project (Sysrepo is a YANG-based configuration and operational datastore for Unix/Linux applications), to network control via the networking specifications in IETF/IEEE/BBF/openconfig/etc., to service models specification (YANG Data Model for L3VPN Service Delivery as an example), to controller and orchestrator and open-source projects such as openconfig), to cloud and virtualization management, without forgetting the orchestration and policy aspects (for example, the MEF Livecycle Service Orchestration).
With the rise of data modeling-driven management and the success of YANG as a key piece comes a challenge: the entire industry develops YANG models but those models must work together in order for operators to automate coherent services. And they must work together NOW. We don’t have the luxury to work in well planned sequences and all the modules. On one side, the YANG modules are constantly improved, and on the other side, they depend on each others.
In order to resolve this challenge, we’ve been working during IETF hackathons to provide the right open-source tools for the industry. Previous results after the IETF 97 have been highlighted. At this IETF, a team of around 10 people went one step further by integrating tools around a YANG catalog.
Note: I went the easy way to create this blog with « we » as opposed to stress individual achievements, but many thanks to Joe Clarke, William Lupton, Einar Nilsen-Nygaard, Gary Wu, Mahesh Jethanandani, Radek Kreji, Sudhir Rustogi, Abhi Ramesh Keshav, Carl Moberg, Rob Wilton, Miroslav Kovac, Vladimir Vassilev, and more.
What is the idea behind a YANG catalog?
From a high-level point of this YANG catalog goal is become a reference for all YANG modules available in the industry, for both YANG developers (to search on what exists already) and for operators (to discover the more mature YANG models to automate services). This YANG catalog should not only contain pointers to the YANG modules themselves, but also contains metadata related to those YANG modules: What is the module type (service model or not?) What is the maturity level? (for the IETF: is this a RFC, a working group document or an individual draft?), Is this module implemented? Who is the contact? Is there open-source code available? And we expect much more in the future. The industry starts to understand that the metadata related to those YANG modules become equally important as the YANG modules themselves. We based on work on openconfig catalog, as a starting point but we realized that we have slightly different goals.
The YANG catalog added value, compared to a normal Github repository resides in the toolchain and the additional metadata:
the demonstration of data model-driven management with open source tools: YANG Explorer (a GUI-based tool to explore modules, generate some code, and connect the devices) YANG Development Kit (a more advanced tool for code generation)
Using this one-stop set of tools, the typical flow for a YANG module designer is to validate the YANG module and to populate the YANG catalog (via an IETF drafts, via Github, or directly via the YANG catalog).
And the typical flow for a YANG module user is to search for an existing YANG module, to look up the metadata (such as maturity level, implementation, etc.), and to look up the import and include dependencies if any. Once the YANG module of choice is found, the YANG module user would browse the YANG module content, then load the YANG module in the YANG Explorer and test it by connecting to a NETCONF or RESTCONF server, and finally generate python scripts to start the automation.
This is obviously work in progress and contributions are welcome, as everything is open-source.
Practically, what have we done during this IETF 98 hackathon?
The YANG validator improved, with yanglint as an additional validator and with specific plugins that will check the correct format for the IEEE, MEF, BBF, and Cisco-specific plugins (practically, they will check the urn and prefix).
The YANG DB search laid a framework for the multi-SDO impact analysis, including a color scheme for the standard maturity levels. Below is an example.
Regarding YANG module validation, William Lupton from the Broadband Forum added all the BBF modules to the YANG catalog, including the work-in-progress ones (this means 192 modules in total). While validating those modules, we discovered some issues with some validators. Those issues are now solved and most BBF YANG modules validate correctly. Finally, William updated the YANG catalog With the BBF modules maturity level that will distinguish draft and ratified YANG modules. The example here BBF work-in-progress YANG modules depending on the IETF interface YANG module [RFC 7223].
We created a script to push, as a cronjob, all extracted YANG modules from IETF drafts into Github (we still have to integrate it in the tool chain btw). Background: it should be a priority for the IETF to separate the draft text from its « code » content, such as a YANG module, so that we don’t have to extract YANG module via tooling, and so that the YANG module could progress in Github independently of the draft version.
Another major achievement for this hackathon is the integration of the YANG Development Kit into the YANG Explorer. In this example below, you see the YANG Explorer with the GUI on the left-hand side and the generated python script.
In term of YANG module transition, we also created a script to help with the latest IETF YANG module guideline: a script to convert the -config/-state into a combined tree, to convert from a combined tree to generating an additional -state tree, and to convert from a combined tree to generating an Openconfig style tree. This will be pretty handy for the transition phase, and a good addition to the toolchain.
I have personally great hope for this YANG catalog, as it will solve a real issue in this industry. Now, we should not wait until the next hackathon to continue improving it. « Running code and consensus » I heard someone say!
The 98th IETF meeting wrapped up last Friday in Chicago. It was a typically busy work week for IETF participants, but also a special week, as a number of changes in our leadership became official. We welcomed newly selected individuals into the leadership and gave our thanks to outgoing members of the IESG, IAB, and IAOC, including the outgoing IETF Chair, Jari Arkko. Among his many other accomplishments, it was under Jari’s leadership that this blog came into existence. The blog has proven to be a useful tool for communicating with the IETF community and the world at large, and I intend to keep up the tradition. Same goes for video – you can see a clip of Jari and I recapping the meeting week here:
Amidst all the working group action and leadership transition activities, a few highlights stood out for me last week. Among more than 1000 attendees, nearly 17% were attending their very first IETF meeting this time around. We’re constantly evaluating what more we can do to attract cutting edge standardization work and new participants to the IETF, so it was nice to see many fresh faces.
Last week’s meeting demonstrated that a number of core security and web application standards are on a path towards high levels of maturity and industry adoption. These include:
The work on all of these standards is heading towards conclusion within the respective working groups, and will soon be put out for IETF community review. There was also a large TLS team at the IETF Hackathon representing 18 independent implementations, and they were named the overall Hackathon winners by the judges. Congratulations!
IETF Hackathon in Chicago.
Last week was also very busy for those working on YANG data models related to both network management and routing. While participants continue to press forward with the standardization of hundreds of different YANG modules in the IETF, they’ve also been focusing on guidelines and tooling (yangcatalog.org, for example) to help streamline the model development process and aid interoperability.
Our technical plenary speakers, Niels ten Oever and David Clark, addressed questions about the relationship between internet protocols and human rights. David encouraged us to think of standardization activities as “designing the playing field” and to contemplate how we “tilt the playing field” based on the design choices that we make. As expected, the topic yielded a provocative community discussion session.
Plenary speakers Niels ten Oever and David Clark with IAB member and plenary moderator Lee Howard.
We owe deep thanks to our meeting host, Ericsson, for stepping up to ensure the success of last week’s meeting. As an IETF Global Host, Ericsson has committed to host three IETF meetings in a 10-year period and affirmed its long-standing support for the work of the IETF. We heard at the plenary session just how important IETF work is to Ericsson’s industry and technology goals, particularly as the coming shift towards 5G inspires potential new requirements around packet transport, network and service management, and virtualization.
Until we gather again as a group for IETF 99 in July, work will continue as always on mailing lists, at interim meetings, and increasingly on Github (check out the Working Groups Using Github session for more on that). See you in all of those places …
Alissa Cooper, IETF Chair
Photos from IETF 98
A collection of photos from the IETF 98 meeting held 26-31 March in Chicago, Illinois, United States.
Before IETF 98 began, the IETF Hackathon was in full swing.
Applied Network Research Prize winner Alistair King presents his research at IETF 98 Chicago 26/03/2017
Applied Network Research Prize winner Yossi Gilad presents his research at IETF 98 Chicago 26/03/2017
David Clark speaking on the question:What is the relationship between Internet Protocols and Human Rights? During the IETF 98 Plenary on Wednesday, 29 March 2017 Niels ten Oever, Head of Digital for Article 19, and David Clark, Senior Research Scientist at the MIT Computer Science and Artificial Intelligence Laboratory, tackled this question. They offered different perspectives on the role human rights considerations should play in the Internet protocols and, in particular, how these considerations ought to factor into the work of the IETF. (L to R: Niels ten Oever, David Clark, Lee Howard)
Outgoing IETF Chair Jari Arkko speaking at the IETF 98 technical Plenary, Chicago 29/03/2017
Incoming IETF Chair Alissa Cooper speaks during IETF 98 Plenary on Wednesday, 29 March 2017.
John Mattsson, senior specialist at Ericsson Security Research speaking as part of the IETF Host Speaker Series on ‘The real deal on cellular security’ during the IETF98 meeting in Chicago, Thursday, 30th, March 2017.
IETF 98 Wrap up video with Jari Arkko and Alissa Cooper, Friday, 31 March 2017.