An excerpted version of this article first appeared in Human Infrastructure Magazine. HIM is written by the Packet Pushers team plus special guests about what it’s like to be a human being working in the technology industry.
If you’d like HIM flown to your inbox by digital angels who’ll carry every word on a pillow knit from the tears of hackers you’ve defeated with reverse DDoS attacks, you can subscribe here. It’s free and imbued with anti-suck properties guaranteed to make your Internet traffic prioritized, your coffee more potent, and your configuration stanzas self-correcting.
I attended the 98th meeting of the Internet Engineering Task Force (IETF) in Chicago in March 2017. What is the IETF? The IETF is made up of folks that write, among other things, the RFC documents you hear so much about in IT–especially networking. As such, the IETF is a standards development organization (SDO).
The IETF meets 3 times per year, with locations scattered around the globe. In between meetings, mailing lists are the crucial communications tools where ideas and documents are developed and critiqued.
Anyone can participate in the IETF. All mailing lists and meetings are public. There are over 1,000 IETF videos on YouTube. The meetings cost several hundred dollars to attend, plus travel and lodging. Remote participation in the meetings is possible. Each meeting room has a screen and projector where remote participants can be seen and heard by those who have gathered in person.
What Does The IETF Do?
The way I think about the IETF is that they are in the Internet problem-solving business. The Internet is a complex internetwork that operates at a global scale. The Internet is a platform for commerce, free speech, and knowledge sharing. The Internet is, in this sense, a global equalizer of great interest to all of humanity. That sounds admittedly grandiose, but those are the facts.
However, the Internet is also technically challenging to operate, as you might imagine any network functioning at global scale across many service providers would be. The Internet is also politically challenging to operate, spanning every continent and country, with ramifications for governments and their peoples.
Therefore, while the problems the IETF attempts to solve are largely technical, these technical problems have a backdrop of business and global politics. That means that the IETF does not operate in an environment of technical idealism. Rather, IETF solutions are often compromises designed to meet as broad a number of (sometimes competing) requirements as possible.
Interestingly, the IETF also tackles issues that affect small, local networks. That means that the “Internet engineering” part of the IETF is sort of a misnomer, as much of what the IETF works on are technologies that are, in fact, not deployed at a global scale, and might not impact the global Internet directly.
How Is The IETF Organized?
The IETF is organized around areas of technical interest, with specific working groups formed inside of broader areas. Areas have directors. Working groups have chairs.
As best as I can tell, area directors attempt to unify efforts among working groups, minimizing duplicate efforts and heading off opposing efforts when possible. Area directors need to know what both the left and right hands are doing. Working group chairs are cat herders, maintaining a semblance of order and forward motion among the many drafts and RFCs that are working their way through the working group process.
Review this page to see IETF areas and their working groups, along with area directors and working group chairs as well as their contact information. I am not 100% clear on how area directors and working group chairs are selected, but my impression is that they serve both at will and by consent of working group active participants. I am unsure if there are limited terms that are served or not. That information is doubtless to be found on ietf.org, but exceeds my search-fu at the moment.
I am clear from talking to several directors and chairs that these roles are time intensive. The folks in these roles fulfill them as volunteers. A lucky few might have permission from their employers to more or less do IETF work full time. Most do not have this luxury, serving the IETF in their so-called spare time.
Area directors and working group chairs are not in positions of power. They can’t decide things on their own. Rather, they strike me as being coordinators in a complex, interdependent system of working groups. Perhaps grease in an interlocked system of gears would be an apt analogy.
How Does The IETF Get Things Done?
Working groups are bound by charters. The charter defines the scope of the working group–the things the working group is meant to accomplish. When a working group wishes to exceed the mandate specified by the charter, the charter must be amended. The charter also helps define when a working group has fulfilled its mandate and can be disbanded. Ergo, working groups are not necessarily meant to last forever.
In accordance with the charter, interested parties can submit draft documents that provide commentary or technical solutions to issues the working group is addressing. These drafts rise and fall based on their merits as well as the political strength of the organizations backing them. It is possible for documents to expire if not enough people are interested in moving them toward adoption.
Working group meetings, such as the ones I attended at IETF 98, are an open forum where anyone has the right to stand up and speak their mind, so long as they are willing to go on the public record. That said, fools are not suffered. It is assumed you have a relevant (and intelligent) point to make in these meetings, and that you have been keeping up with the mailing list and drafts before getting up to the mic to unburden yourself.
Decisions are made inside of working group meetings, often along the lines of approving or not approving the current status of a written document. Decisions are not made by formal voting, but rather through discussion that eventually leads to rough consensus.
Rough consensus might be determined by humming, where a working group chair calls for the assembly to hum to express their agreement. If there is preponderance of humming for a particular point, the chair might consider that to be rough consensus and move ahead.
A great deal more can be said about IETF culture and processes in their Tao document. I recommend reading it. (I still need to finish it myself.) I might make an audio recording of it, as I don’t believe such a thing exists, although the structure would make that a bit challenging.
My Impressions Of The IETF 98 Proceedings
I made it a point over the week to sit in a variety of different working groups to gain as broad a perspective as I could on how the IETF does things.
- IETF governance is the best and worst thing about the IETF. Without a centralized power structure, documents can, and do, take years to be adopted. Despite this, documents might not result in the best solution, but rather an odd amalgamation of viewpoints, none of which are optimized for any particular situation. Also, documents might try to solve every use case, corner case, and odd little situation that can be imagined, i.e. ocean boiling or yak shaving. This is exactly what happens in many IETF working groups as some active IETF participants have quietly told us, and as evidenced by even a casual perusal of drafts working through the system.
On the other hand, anyone and everyone can have a voice, which I believe is critically important. There are limited chances for a power-hungry leader to force their will on others or for a vendor to stack the deck in their favor. Interesting technical ideas can rise on merits to be considered by a global organization of engineers. Those points stand in favor of IETF governance as it exists.
- Most of the work is being done by vendor employees. Vendor participation in the IETF isn’t a bad thing, but can mean that the vendor’s chief concern is ensuring their commercial interests are represented. That could be by representing their own customers’ interests and/or their existing investments.
For example, imaginary vendor Amazing Networks Inc. might be behind a draft that creates a protocol in some particularly nuanced way. That particular way might align with what their customer wants as well as with an ASIC they already have on the market. While that’s not necessarily bad, it could be that the result that’s the best for Amazing Networks Inc. isn’t the result that’s the best for the Internet community at large.
- Many of the operators involved represent huge special interests, i.e. corner cases. Of the operators (i.e. not vendors) I saw taking part in the proceedings, many of them were from mega-corporations like Google and Microsoft, or global service providers. Obviously, these folks have specific networking needs that the IETF can help address.
Conversely, those needs aren’t typically the needs of smaller operators. The concept of GIFEE notwithstanding, the vast preponderance of networks do not have the challenges of hyperscale networks nor of global service providers. And yet, smaller network operators seemed, based on the meetings I attended, largely a non-existent force.
This begs the question whether the IETF is spending a lot of time solving problems that don’t actually need to be solved or that should be solved by mega-operators in their own way rather than grinding through the gears of the IETF. I don’t have a considered answer to that question yet, but it’s worth contemplation.
- Drafts for the sake of drafts is a problem. As I listened to the drafts being proposed, I found myself–in some cases–mystified as to the importance of the issue. Many of the drafts seemed so trivial and of so little interest to the broader networking community, that I couldn’t see their relevance. Why should the IETF be burdened with seeming trivialities?
One answer is that I don’t know what I don’t know. Just because I, personally, don’t recognize an issue being addressed as an actual issue, that doesn’t mean it isn’t one.
There is another somewhat troubling answer, though. Several active IETF participants have explained to me that having one’s name on a draft has become a status symbol in the networking community. Therefore, IETF participants are spending lots of time writing drafts more for the notoriety it brings to themselves or their company, and less for the problem being solved.
One example of this relates to YANG. YANG is a modeling language purposely created for networking. A current IETF trend is to create a technical draft, but then to also create a companion draft that proposed a YANG model for the technical draft. Two drafts for the price of one! Almost every single meeting I attended had a YANG draft component to it.
- The IETF is an incubator for good work being done by altruistic, brilliant engineers. Don’t think I’m negative about the IETF. Far from it. I can see much good that comes from what the IETF is doing, and I think it’s a candidate for the best of what we have in the SDO world.
The IETF is, no matter what politics there might be, a launching pad for clever ideas that receive nurturing in a way that reduces adoption barriers. I found myself highly engaged in several of the meetings, as I listened to the participants share their viewpoints on issues. I even found myself with an opinion or two along the way, not that I got up to the mic.
In addition, I highly value the public nature of the IETF. I am weary of elitist SDOs that hide in their ivory towers behind golden doors refusing to engage with the riffraff. The IETF is anything but that, and their willingness to engage with Packet Pushers and YOU is evidence, if any evidence were needed.
I think I just called us all riffraff. Sorry about that. 😉
The IETF On Packet Pushers
We’ve been critical of SDOs and the IETF in particular on Packet Pushers podcasts over the years. However, we don’t merely want to criticize. We’d like to do a little more than cast stony aspersions.
We’d also like to bridge the gap between regular network operators and the IETF. There’s this idea that the IETF is a sort of prophet handing down the tablets from the mountain with RFCs written on them. The process is quite different from that, so much so that I wish I’d been involved as a younger man.
To help us with these goals, the Packet Pushers have been sponsored by Huawei to attend two IETF meetings in 2017. Huawei didn’t ask for anything other than we attend and cover the meetings for the benefit of the broader networking community.
I attended IETF 98, and was lucky enough to capture five recordings. You’ll hear those on the Priority Queue channel as episodes 111 – 115, starting this week. Give them a listen to hear us discuss several interesting drafts, including BIER, RIFT, and BGP as a control plane for service function chaining (SFC). We’ll also hit goings-on in the world of DNS, IETF hackathons, YANG, and telemetry. These are all issues that seemed to me to be of interest to the broader networking community–i.e. not trivialities–as they might affect us in the real world someday soon.
I was also able to record a show on the FreeRangeRouting project, a fork of Quagga. FRR is not an IETF issue specifically, but thanks to Russ White, I was able to chat with a lead developer and a lead tester for FRR who happened to be in town for IETF 98.
Greg will be attending IETF 99 in Prague during July, and grabbing some recordings there as well. With any luck, all of this activity will prompt more of us to be involved with the IETF.