Last June I wrote an article titled “The IETF’s *Other* Diversity Challenge” where I discussed the positive steps the Internet Engineering Task Force (IETF) is taking to increase the diversity of its participants and raised a potentially overlooked demographic: Network Operators. That essay was a problem statement of sorts, and I was long ago taught that you should only raise problems that you have a solution for, or are at least willing to help solve. In that spirit, the post did in fact lay out our plan: To host a survey regarding these issues, synthesize the results, and look for solutions. As you may have guessed, this article is an update to the previous one. Here I’ll look briefly at what survey respondents told us and where that’s leading us for next steps.
First a quick review, to set the context. What is the IETF and who are these Operators? In the original post, I explained the IETF like this:
The Internet Engineering Task Force (IETF) is the standards body for the Internet. It is the organization that publishes and maintains the standards describing the Internet Protocol (IP – versions 4 and 6), and all directly related and supporting protocols, such as TCP, UDP, DNS (and DNSSEC), BGP, DHCP, NDP, the list goes on, and on.
That still sounds about right to me. But who do I mean when I say “network operator?” I touch on this because many folks understand the word ‘operator’ to refer specifically to Internet Service Providers (ISPs). This is not how I am using the term. I’d like you to understand network operators, in this context, under the most broad definition possible: Any person or organization that operates an IP network. This could be an enterprise or corporate network, a campus network, a data center, an education network, a transit network, and yes, it could be an ISP network too.
The question we set out to answer in all of this is, “How do we (the Internet Society, the IETF, network operators, network operator groups, and you) ensure optimal communication between the IETF and network operators, in order to ensure the best possible internetworking protocols are developed?” Let’s take a look at what we’ve found so far.
First Steps: Operators and the IETF Survey Results
The first phase of this project was a survey of the operator community which was conducted over the first half of 2014. That survey closed on 1 July 2014 with over 350 responses. Thank you to everyone who participated! The survey included both multiple choice and free-text essay type questions and was not done in a statistically meaningful way. This was meant as a type of litmus test, to informally (and anonymously) gather opinions, attitudes, and perceptions from the global network operator community.
The second phase included analyzing and synthesizing the survey results, along with all the other feedback we received. Over the second half of 2014 we collected this information into an IETF Internet-Draft (I-D). The I-D includes a report on the challenges to greater operator engagement in the IETF and a summary of potential solutions. Read it here: https://tools.ietf.org/html/draft-opsawg-operators-ietf.
The draft is currently split into three main sections. “Survey Respondents” provides information on who took the survey and their current level of IETF participation and knowledge. “Potential Challenges” digs deeper into this with a look at the areas and items that may be keeping operators (or others) from participating in the IETF today. “Possible Solutions” then takes direct quotes provided by survey respondents about how to make the IETF more open to new and more diverse participation. Below is a very quick summary of these three sections:
Survey Respondents:
- The respondents were overwhelmingly technical and the vast majority were operators.
- Exactly half of the respondents reported that they did NOT currently participate in the IETF at all.
- Almost one third said they participate in the IETF via mailing lists only.
- Only about 18% reported that they were active in the IETF via both mailing lists and in-person meetings.
Potential Challenges:
- Time
- Culture
- Money
- Awareness
Possible Solutions:
- Communication
- Outreach
- Inclusion
Awesome! The survey is complete, the data has been shared, and now it’s time for us all to make something of it, collectively.
The best part about this work, for me, is that it has transcended its original purpose. While we remain dedicated to helping network operators of all types contribute to, and benefit from, the IETF, it has become obvious that the problems (perceived or otherwise) we have uncovered are much more universal. It’s my hope that our (the Deploy360 team, along with you and the rest of our amazing community) efforts will not only benefit network operators but all newcomers to the IETF. This includes of course the new generation of network savvy developers, to name just one additional group.
Next Steps: ‘Synergy,’ an IETF Help Desk, and More!
Now we are in the third phase of this project: Discussion and action! We kicked this conversation off at IETF 91 in November, 2014.
At IETF 91 I got the chance to briefly introduce the I-D to the Internet Engineering and Planning Group (IEPG) and then at greater length in the Operations and Management Area Working Group (OpsAWG) meeting. You can view the video (the Operators and the IETF bit starts at about 01:07:00) and check out the slides if you like. In addition to continuing this discussion with all of the survey results available, we also saw two solid action items come out of the IETF meeting:
- A ‘Synergy’ mailing list for those interested in discussing this topic at greater length: http://snozzages.com/cgi-bin/mailman/listinfo/synergy
- A plan to start hosting an “IETF Help Desk” at regional NOG meetings.
The Synergy mailing list was set up by IEPG and OpsAWG co-chair Warren Kumari on his personal server, to provide a neutral format for these discussions. We expect the list to be used by both IETFers and Operators, as well as those who are both or somewhere in between, to discuss the results of the survey, to generate and discuss possible solutions, and to start coordinating the execution of those solutions. The first thing the list will be used for is finding volunteers for the IETF help desk.
The idea of the IETF help desk is to provide a common / well-known place for operators to bring their questions about the IETF and have them answered by those experienced with the IETF. We do not expect anyone to travel to NOG or NOF meetings specifically to staff this desk. Instead, we’d like to find those folks who have significant IETF clue and are already planning on attending a given NOG/NOF meeting. We can use the Synergy list to self-identify and volunteer for this work. In this way we can prearrange to have the IETF help desk open at specified and pre-published times. We expect questions asked at the desk to be along the lines of, “What is the IETF working on in X space?”, “How do I get involved in the IETF?”, “How do I submit an RFC?”, etc.
IETF Help Desk @ NANOG 63
We are wasting no time, as I mentioned in a recent Deploy360 blog post:
NANOG 63 will be the alpha production of a new concept that grew out of our Operators and the IETF survey results following IETF 91: An IETF Help Desk. Similar to the help desk that ARIN hosts at NANOG, the IETF Help Desk is designed to be your one stop for all your IETF questions. Unlike ARIN, this is not an official (read: approved or funded) IETF activity. We’re just a bunch of folks who happen to attend both IETF and NANOG meetings who’ve volunteered to staff the table and help our fellow community members.
And Beyond
After NANOG 63 next week, we’re hoping to bring the IETF Help Desk to NOGs/NOFs and other relevant implementer meetings all over the world. In various states of planning now are:
- APRICOT 2015 in Fukuoka this March
- MENOG 15 in Dubai this April
- RIPE 70 in Amsterdam this May
- Your event here – Please contact us if you’d like to help with an IETF Help Desk at a meeting you’ll be attending this year!
Along the way we’ll be touring the world again, speaking with operator groups around the globe. In addition to in-person conversations, we’ll be discussing these topics on the Synergy mailing list. It’s time now to start identifying actual changes that can be made. Some of these changes will need to be made by the IETF, some by operators and operator groups (NOGs and NOFs), and some may require action by the Internet Society. The key now is to discuss the potential challenges, evaluate the possible solutions (+ identify more), and then get to work on the low hanging fruit.
Remember too that we’ve now seen that this is bigger than just operators. The question we are trying to answer now is more broad: “How do we ensure optimal communication between the IETF and those who implement and deploy IETF technologies, in order to ensure the best possible protocols are developed?”
I’m excited about the future of this community effort! I hope you are too. If you have additional thoughts, or would like to be more closely involved in this process, please join the Synergy mailing list and/or contact us directly.
This post also appears on CircleID.
