Internet DRAFT - draft-opsawg-operators-ietf
draft-opsawg-operators-ietf
Network Working Group C. Grundemann
Internet-Draft J. Zorz
Intended status: Informational Internet Society
Expires: May 1, 2015 October 28, 2014
Operators and the IETF
draft-opsawg-operators-ietf-00
Abstract
Internet Society has launched a new project to address the perceived
gap between Operators and the IETF. The objective of this project is
ultimately to facilitate communications between the operator
community and the IETF to help ensure that operational realities
inform the development of key standards. The first phase of this
project was a survey of the operator community that was conducted
over the first half of 2014. This I-D aims to synthesize the initial
survey results, along with information we collected directly from
operators during the survey window. The primary purpose of doing
this is to start a conversation which we hope will lead to increases
in the level of operational input and feedback to the IETF standards
making process.
Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119].
Status of this Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on May 1, 2015.
Copyright Notice
Grundemann & Zorz Expires May 1, 2015 [Page 1]
Internet-Draft Operators and the IETF October 2014
Copyright (c) 2014 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Survey respondents . . . . . . . . . . . . . . . . . . . . . . 4
2.1. Job type . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.2. IETF Involvement . . . . . . . . . . . . . . . . . . . . . 5
2.2.1. Do not currently participate in the IETF . . . . . . . 5
2.2.2. Do not currently participate on IETF mailing lists . . 6
2.2.3. Do not currently participate in IETF meetings . . . . 8
3. Potential Challenges . . . . . . . . . . . . . . . . . . . . . 9
3.1. Time . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
3.2. Culture . . . . . . . . . . . . . . . . . . . . . . . . . 10
3.3. Money . . . . . . . . . . . . . . . . . . . . . . . . . . 12
3.4. Awareness . . . . . . . . . . . . . . . . . . . . . . . . 12
3.5. Other . . . . . . . . . . . . . . . . . . . . . . . . . . 13
4. Possible solutions . . . . . . . . . . . . . . . . . . . . . . 13
4.1. Communication . . . . . . . . . . . . . . . . . . . . . . 14
4.1.1. Mailing List Digests . . . . . . . . . . . . . . . . . 14
4.1.2. Alternative Communication Mediums . . . . . . . . . . 15
4.2. Outreach . . . . . . . . . . . . . . . . . . . . . . . . . 16
4.3. Inclusion . . . . . . . . . . . . . . . . . . . . . . . . 19
5. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 22
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22
7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 23
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 23
8.1. Normative References . . . . . . . . . . . . . . . . . . . 23
8.2. Informative References . . . . . . . . . . . . . . . . . . 23
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 23
Grundemann & Zorz Expires May 1, 2015 [Page 2]
Internet-Draft Operators and the IETF October 2014
1. Introduction
The Internet Engineering Task Force (IETF) is an open standards
organization concerned primarily with developing and promoting open
Internet standards, with the goal of making the Internet better.
Their goal, mission statement, and cardinal principles are documented
in [RFC3935], section 1.
In a perfect world, the IETF would create standards for protocols
that meet all relevant network operator requirements, sync with
operational realities, and are relatively easy to deploy and
troubleshoot. In this perfect world, deployment and
operationalization concerns are consistently addressed and the level
of operator engagement always makes sense. Operators always know
when their input is needed and always provide that needed input. In
reality, though, many operators are not engaged enough in the IETF to
create that perfect world. It's widely understood that a significant
portion of operators (particularly small- to mid-size) don't join
IETF mailing lists or attend IETF meetings, effectively writing
themselves out of the process. This leaves vendors, academics, and
some large organizations to rule many decision-making processes
within the IETF. The operators expected to deploy these technologies
often don't even know that the standards are being developed. In
other words, critical new technologies are currently being developed
without sufficient direct operator input.
This disparity is not new, nor has it gone unnoticed. Nine years ago
this month an essay by Randy Bush was published in ACM SIGCOMM
Computer Communication Review. It's titled "Into the Future with the
Internet Vendor Task Force: A Very Curmudgeonly View - or - Testing
Spaghetti - A Wall's Point of View" and it calls out this very issue
of "the devaluation of operational realities."
However, with the advent of OpenFlow, Software Defined Networks
(SDN), Network Function Virtualization (NFV), and an overall trend
toward open source, particularly open application programming
interfaces (APIs), in the network space, this disparity may now be
seen as related to a larger and growing problem. If open APIs become
the de-facto definition of interoperability requirements, the role of
the standardization bodies, and the opportunity for operators to
influence specifications, diminishes. As a result the functional
interoperability (and interchangeability) of vendors and devices will
decrease, potentially leading to a more proprietary and less open and
global nature of the Internet.
In response, the Internet Society has launched a new project to
address the perceived gap between Operators and the IETF. The
objective of this project is ultimately to facilitate communications
Grundemann & Zorz Expires May 1, 2015 [Page 3]
Internet-Draft Operators and the IETF October 2014
between the operator community and the IETF to help ensure that
operational realities inform the development of key standards. We
want to foster a larger and more engaged operator community around
the IETF and protocol development work. To ensure that we take the
most effective action, we focused initially on talking to operators
around the world, gathering information and defining the problem
statement(s). The first phase of this project was a survey of the
operator community that was conducted over the first half of 2014.
The survey closed on 1 July with over 350 responses.
This I-D begins the next phase, which we hope will lead to productive
improvements to the level of operational input into the IETF
processes. The primary purpose of this paper is to synthesize the
survey results, along with information we collected directly from
operators during the survey window.
In the next section we take a quick look at the survey respondents,
including their roles and their relationships to the IETF. Then,
under the following section, Potential Challenges, we delve into the
reasons respondents gave for not participating in the IETF. What are
their personal challenges to injecting more operational reality? We
then move on to discussing ideas for overcoming these obstacles in
the next section, Possible Solutions. In all cases, we are primarily
reporting on the results of the Operators and the IETF survey, open
from January through June 2014 and the text may not necessarily
reflect the views of the Internet Society.
2. Survey respondents
Before diving into what the survey respondents said, and what that
might mean, let's first take a look at who these respondents were.
2.1. Job type
The first set of questions dealt with the respondents' role. We
wanted to ensure that we reached our target audience - technical
network operators. A note on our use of the term "operator:" In the
survey, in this paper, and throughout this Operators and the IETF
project, we use the term operator to mean anyone who operates an IP
network. This includes Internet service providers (ISPs) but also
content providers, data centers, enterprises, wireless networks,
campus networks, and everything in between.
o I'm an Operator - 44% strongly agree and 34% agree, 12% disagree
and 10% strongly disagree.
Grundemann & Zorz Expires May 1, 2015 [Page 4]
Internet-Draft Operators and the IETF October 2014
o My role is primarily technical - 63% strongly agree and 29% agree,
9% disagree and 2% strongly disagree.
The respondents were overwhelmingly technical and the vast majority
were operators. We also drilled into specific roles of respondents:
o I'm an Engineer - 60% strongly agree and 32% agree, 5% disagree
and 3% strongly disagree.
o I'm an Architect - 42% strongly agree and 38% agree, 14% disagree
and 6% strongly disagree.
o I'm an Developer - 9% strongly agree and 29% agree, 39% disagree
and 23% strongly disagree.
o I'm an Manager - 24% strongly agree and 26% agree, 27% disagree
and 23% strongly disagree.
92% of respondents self-identified as engineers and 80% as
architects, while only 38% said they were developers and about half
said they were managers.
2.2. IETF Involvement
The next set of questions dove into the respondents' current level of
participation in, and awareness of, the IETF.
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. This is about the mix we were expecting.
Since we are looking primarily for challenges and obstacles to
participation, we wanted to hear from the people who do not
participate. Mixing in some people with more experience on how the
IETF works today helps provide useful context, though. We then asked
each group of respondents more detailed questions about their level
of awareness, based on their participation level in the IETF.
2.2.1. Do not currently participate in the IETF
Among those who do not currently participate in the IETF at all, a
wide majority know that the IETF exists, know what it does, find IETF
documents relevant to their jobs, and feel that they need to
participate.
So why aren't they showing up? Other responses within this set of
Grundemann & Zorz Expires May 1, 2015 [Page 5]
Internet-Draft Operators and the IETF October 2014
questions provide clues: Over half of this group reported that they
do not know how to participate, and almost half said that they do not
feel welcome.
Detailed results:
o I never heard of IETF: 82% strongly disagree, 14% disagree, 1%
agree, 3% strongly agree In short - 4% report not having heard of
the IETF before the survey
o I don't know what IETF does: 57% strongly disagree, 35% disagree,
8% agree, 0% strongly agree In short - 8% don't participate
because they don't know what the IETF does
o I don't know how to participate: 21% strongly disagree, 21%
disagree, 44% agree, 14% strongly agree In short - 58% of those
who do not participate in the IETF do not know how
o I don't believe IETF documents are relevant to my job: 53%
strongly disagree, 33% disagree, 11% agree, 3% strongly agree In
short - 86% believe that IETF documents are relevant to their work
o I don't feel my operator input is welcomed: 14% strongly disagree,
42% disagree, 33% agree, 11% strongly agree In short - 44% do not
participate because they feel unwelcome
o I rely on my vendors to represent me: 27% strongly disagree, 37%
disagree, 30% agree, 6% strongly agree In short - 36% rely on
their vendors to represent them at the IETF
o I don't need to participate, I just need the output: 24% strongly
disagree, 49% disagree, 23% agree, 4% strongly agree In short -
27% choose not to participate because they are only concerned with
the output of the IETF (RFCs)
2.2.2. Do not currently participate on IETF mailing lists
Among respondents who do not currently participate in IETF mailing
lists, over two thirds believe that it does, in fact, fall within
their job to do so. While most respondents had at least heard of
IETF mailing lists, about half reported not knowing what happens on
those lists and 40% said they don't know how to join. Also, about a
third of respondents do not participate on IETF mailing lists because
"list noise" (off-topic and unhelpful content) is too high.
Almost three quarters report staying off the lists because they don't
think they have enough time. Almost half of those who are not on an
IETF mailing list thought they had to show up to meetings to
Grundemann & Zorz Expires May 1, 2015 [Page 6]
Internet-Draft Operators and the IETF October 2014
participate and were unaware that most IETF work actually takes place
on the mailing lists.
Detailed results:
o I've never heard of IETF mailing lists: 44% strongly disagree, 25%
disagree, 25% agree, 6% strongly In short - 31% had never heard of
IETF mailing lists before this survey
o I don't know what happens on IETF mailing lists: 23% strongly
disagree, 23% disagree, 44% agree, 10% strongly agree, In short -
54% don't know what happens on an IETF mailing list
o I don't know how to join an IETF mailing list: 35% strongly
disagree, 25% disagree, 34% agree, 6% strongly agree In short -
40% aren't on an IETF mailing list because they don't know how to
join
o I'm not interested: 29% strongly disagree, 55% disagree, 14%
agree, 2% strongly agree In short - 16% of respondents don't
participate due to lack of interest
o I find the content too technical or abstract: 27% strongly
disagree, 47% disagree, 25% agree, 1% strongly agree In short -
26% find IETF mailing list content too technical or too abstract
o I don't have enough time: 8% strongly disagree, 20% disagree, 41%
agree, 31% strongly agree In short - 72% say they don't
participate because they don't have time
o I don't find the content relevant: 25% strongly disagree, 58%
disagree, 16% agree, 1% strongly agree In short - 83% find IETF
mailing list content relevant
o It's not my job: 22% strongly disagree, 48% disagree, 25% agree,
5% strongly agree In short - 70% think that following IETF mailing
lists falls within their job duties, even though they don't
currently do it
o There's too much noise on the lists (off-topic discussions,
etc...): 15% strongly disagree, 51% disagree, 27% agree, 7%
strongly agree In short - 34% replied that "list noise" is an
issue for them
Before taking this survey:
Grundemann & Zorz Expires May 1, 2015 [Page 7]
Internet-Draft Operators and the IETF October 2014
o 54% I was aware that most of the work in the IETF happens on
mailing lists between meetings
o 46% I thought I had to show up at IETF meetings to participate
2.2.3. Do not currently participate in IETF meetings
While most respondents had at least heard of IETF meetings, nearly
half of those who do not currently attend IETF meetings reported not
knowing what happens at a meeting and slightly more said they don't
know how to participate. Two thirds of respondents told us they
don't attend IETF meetings because they don't have the time and over
three quarters because they don't have the travel budget to attend a
meeting. Just less than one third feel it's not their job to
participate at IETF meetings. Almost exactly half of the respondents
who do not attend IETF meetings were unaware that remote
participation is available.
Detailed results:
o I've never heard of IETF meetings: 60% strongly disagree, 25%
disagree, 10% agree, 5% strongly agree In short - 15% don't come
to IETF meetings because they hadn't heard of them before
o I don't know what happens at IETF meetings: 31% strongly disagree,
24% disagree, 35% agree, 10% strongly agree In short - 45% don't
show up because they don't understand what goes on at an IETF
meeting
o I don't know how to participate in an IETF meeting: 30% strongly
disagree, 21% disagree, 35% agree, 14% strongly agree In short -
49% don't participate in meetings because they don't know how to
o I'm not interested: 39% strongly disagree, 48% disagree, 10%
agree, 3% strongly agree In short - 13% avoid IETF meetings due to
a lack of interest
o I find the content too technical or abstract: 33% strongly
disagree, 48% disagree, 17% agree, 2% strongly agree In short -
19% don't participate in IETF meetings because the content is too
technical or too abstract
o I don't have enough time: 15% strongly disagree, 21% disagree, 36%
agree, 28% strongly agree In short - 64% don't come because they
don't have enough time to participate
o I don't have the travel budget: 7% strongly disagree, 11%
disagree, 37% agree, 45% strongly agree In short - 82% don't
Grundemann & Zorz Expires May 1, 2015 [Page 8]
Internet-Draft Operators and the IETF October 2014
attend IETF meetings because they lack the travel budget
o I don't find the content relevant: 30% strongly disagree, 56%
disagree, 10% agree, 4% strongly agree In short - 14% don't come
to meetings because they content is not relevant to them
o It's not my job: 26% strongly disagree, 44% disagree, 23% agree,
7% strongly agree In short - 30% don't attend IETF meetings
because it doesn't fit their job duties
Before taking this survey:
o 50% I was aware that most of the IETF meeting sessions are
available to remote participants
o 50% I thought I had to show up at IETF meetings to participate
3. Potential Challenges
In addition to the multiple choice options on the Operators and the
IETF survey, we included several opportunities for respondents to
enter freeform text. We asked questions such as "Tell us about why
you do not currently participate in the IETF in your own words" and
"Why do you think other operators do not participate in the IETF?"
When these responses are evaluated in combination with the numbers
above, some themes emerge.
There appear to be four major perceived obstacles to IETF
participation:
o Time
o Culture
o Money
o Awareness
These one-word captions are, of course, simplifications. The
following sections dig into each of these themes to explore the
potential and perceived challenges a bit more.
3.1. Time
One of the top complaints from both survey respondents and operators
we have spoken with in person is how much time is required to
participate meaningfully in the IETF. As Mr. Bush pointed out in his
Grundemann & Zorz Expires May 1, 2015 [Page 9]
Internet-Draft Operators and the IETF October 2014
2005 paper:
"The IETF has grown so large and so enamored of complexity and
featuritis that it is a full-time job to participate."
We can see this perception confirmed in the numbers above:
o 72% of respondents who do not participate in IETF mailing lists
say they don't participate because they don't have enough time
o 64% of respondents who don't attend IETF meetings report that they
don't come because they don't have enough time to participate
Additionally, the most common response to both "Tell us about why you
do not currently participate in the IETF in your own words" and "Tell
us about why you are not currently a member of any IETF mailing lists
in your own words" were some variation of "not enough time." This
was the second most common response to the "Tell us about why you do
not currently attend IETF meetings in your own words" question as
well. While many of those responses were very terse, some took the
time to explain their challenges a bit more:
"Time restriction is an issue. Keeping up with my "day job"
responsibilities is challenging. There's difficulty in sorting out
where the different BoFs and working groups are in the process - very
hard to step into the middle of an ongoing conversation, translate it
to my world, and engage in the discussion. Makes it hard to do more
than lurk."
When we dig into the details of some of these comments, it appears
that time constraints may be tied in some ways to what we're calling
cultural challenges here.
"I don't have the time to sift through the entrenched autistic and
esoteric arguments. There are very obviously people who are paid to
participate in the IETF by vendors (and other orgs) for whom it's
their full time job, or one of the primary purposes of their job, and
they don't have other significant responsibilities. It therefore
makes debating with these people very difficult if your involvement
in IETF is a secondary (or tertiary) function of your role."
3.2. Culture
Another common challenge we heard about while conducting this survey
is one of culture. While the IETF is open to participation by
anyone, some feel that they are not welcome or that they will be
ignored or treated badly by other participants.
Grundemann & Zorz Expires May 1, 2015 [Page 10]
Internet-Draft Operators and the IETF October 2014
We saw above that almost half (44%) of the respondents who do not
currently participate in the IETF at all avoid it because they don't
feel their operator input is welcomed.
This is echoed in some detail in many of the comments left by
respondents:
o IETF are just concern about the old members and don't think of how
to get new members onboard
o "I do not feel that the IETF is responsive to the needs and
requirements of those delivering services. The responses to the
IPv6 DHCP enterprise requirements are an example of the
disconnection in the IETF. Many times I have read or participated
in discussions on different mailing lists about many of the topics
and the final item pushed out by people in the IETF has been
"you're stupid and an idiot and we're going to do it my way". I
can get that at home with my teenager."
o "Conversations are heavily dominated by academics with little or
no practical experience (but deep theoretical knowledge and
skills), and vendor professionals who are so senior and
experienced. Both folks cast long shadows that are intimidating
to others who can't devote the time to keeping up with what are
often detailed and nuanced discussions."
o "Despite wanting claims that operators were welcome, as I switched
from protocol engineer to operator, I saw growing irrelevance.
The IETF is maintaining an "ivory tower" vision of how the
Internet is used, whereas the world economy has a different view
of how to make use of the medium. The IETF hasn't been welcome to
new sets of requirements. In DNS, the IETF has been effectively
replaced by DNS-OARC."
o "[I don't participate in the IETF] Because its become a political
fight between vendors. Vendors push their individual agendas
without caring about user opinions. A contentious issue will
bring out half the opposition companies employees to bash and kill
it regardless of whether there is a true customer that may benefit
from it."
o "I perceive it to be full of pompous, self-serving, out-of-touch
with reality, technology actors."
o "The IETF is not really focused towards operations and,
historically, operator input has not been well received."
Another aspect of culture is being more open to participation from
Grundemann & Zorz Expires May 1, 2015 [Page 11]
Internet-Draft Operators and the IETF October 2014
around the world:
"Most studies have been conducted in English, which makes it
difficult for those who have not mastered the language."
3.3. Money
The most common free-form response to "Tell us about why you do not
currently attend IETF meetings in your own words" as well as the
fourth most common response to "Tell us about why you do not
currently participate in the IETF in your own words" was money, and
general support from the respondents' organization. Some of the
nuances here are pointed out in the responses:
o "It is too expensive to attend regularly. It is not my primary
job to attend IETF meetings, so is secondary to other things."
o "I don't have enough budget to attend the conference. Based up in
India, my travel budget + accommodation + Food + Visa will come
around 2000 USD (for Conferences in US) at the minimum, this is my
2 months salary."
o "I'm a self-employed contractor. I can't afford to pay for it
myself, and my clients wouldn't pay to send me there because it's
not what gets their business needs met. And every hour I spend at
conferences and the like is an hour I don't get paid."
Additionally, a full 82% of respondents who don't attend IETF
meetings reported that it was because they lack the needed travel
budget.
3.4. Awareness
Throughout the survey, respondents told us that their ignorance of
the IETF, what it does, how it operates, and how individuals can get
involved, is a barrier to their participation. Overall, 58% of those
who do not participate in the IETF at all reported that they do not
know how to.
Among respondents who don't follow any IETF mailing lists, almost a
third had never heard of the mailing lists, over half said they don't
know what happens on IETF mailing lists, and 40% reported not knowing
how to join a list.
Likewise, among those who do not attend IETF meetings, 45% told us
they don't show up because they don't understand what goes on at an
IETF meeting and nearly half (49%) said they don't participate in
meetings because they don't know how to.
Grundemann & Zorz Expires May 1, 2015 [Page 12]
Internet-Draft Operators and the IETF October 2014
As with the other themes, this was echoed in the comments:
o "No awareness of how I can help, what I can do, and where my goals
would align with the IETF."
o "I do not know how can I participate in IETF. I would love to
know how can I participate. not just by subscribing to mailing
list but by doing some work in my part time."
o "I have no idea how to even begin participating"
3.5. Other
There are also other reasons that came up in the freeform answers
that we feel are very important but that don't fit into one of the
themes above. They include:
o Too technical: "Too broad", "Discussions are on an abstract,
technical level above my expertise"
o Not operational enough: "Not enough operational lists",
"Operations guys stay home doing operations"
o Ignorance: "I never felt the need, it never occurred to me to try"
o Management support: "Lack of Management Support"
o Out of scope: "Out of scope of my job", "I really don't care",
"Not relevant to my job"
o Format: "The meetings are all about status of a particular draft
which really isn't that interesting."
o Reliance on vendors: "Operators mainly rely on system integrators
and rarely believe that their voices are heard"
o Not relevant to operators: "Not relevant to the short/mid-term
needs of most operators", "The lead time from idea to RFC to
vendor support to using in a design is years for me. I will tend
to use a technology once it reaches maturity."
4. Possible solutions
The ultimate purpose of collecting this information and identifying
the perceived challenges to operator participation in the IETF is, of
course, to help us find ways to bring more operational input into the
IETF. In other words, we want to determine how we may be able to
Grundemann & Zorz Expires May 1, 2015 [Page 13]
Internet-Draft Operators and the IETF October 2014
solve these potential challenges.
The possible solutions listed here are based on the survey results
and on numerous conversations with operators around the world. This
is not expected to be an exhaustive list but rather a starting point
for further exploration. Note that this paper is simply documenting
potential solutions and is not, at this time, making any
recommendations. The next step of this process is to widen the
discussion and explore all of our options for making the IETF even
better than it is today.
The remainder of this section is dedicated to individual ideas; some
are suggestions for change at the IETF, others point to activities
that operators or operator groups could do to help, and some are
clues to what the Internet Society may be able to do. These ideas
for possible solutions are grouped into three larger buckets or
themes. The themes that the solutions fall into are:
o Communication
o Outreach
o Inclusion
At this time, this is a very raw collection of direct quotes from the
Operators and the IETF survey, and others we spoke with anonymously.
In later versions of this Internet-Draft we intend to update this
section based on conversations both inside and outside of the IETF.
4.1. Communication
The first theme that we saw emerge among possible solutions is one of
communication. Most of these ideas focus on alternative methods of
communication between the IETF and its constituents and specifically
on new ways to provide condensed information to IETF participants and
potential participants.
4.1.1. Mailing List Digests
o "Quarterly summaries for those that are not able to attend."
o "Provide a curation service that takes key developments in a
working group and shares them from time to time - save operators
from having to make sense out of nuanced arguments so that they
can jump into conversations with reasonable confidence they know
what's happened so far and therefore won't embarrass themselves."
Grundemann & Zorz Expires May 1, 2015 [Page 14]
Internet-Draft Operators and the IETF October 2014
o "There's probably no silver bullet, but one thing that I would
find most useful would be a single daily/weekly/monthly digest
mailing list. Just headlines and updates from each of the working
groups. (Along with links to where to find more information for
each.)"
o "Make it dead simple for folks to see the specific topics being
discussed and worked on. If I had some idea what the topics were,
I would be more likely to participate if there was a topic that I
had some expertise in and more importantly an opinion about how to
address the issue."
o "a blog with some updates of things would be nice. reading a huge
amount of emails is not that fast and with a blog post you can
join the discussion when there is something important ongoing"
o "At least provide weekly summaries what's currently in discussion
and which new drafts or RFCs were published."
o "Invest in reducing perceived entropy and lower the time
commitment to do so - both requires energy inputs. Action:
Introduce and invest support staff that write accessible summaries
(like the former Cisco IPJ) - licensed under CC so that they can
be freely translated to other languages without breaking the bank:
Note - I'm associated with IPJ and am biased."
o "Highlight specifically which groups' efforts are looking for
operator input. Or color-code agendas by "how close" different
efforts are to needing operator input. Have those folks write an
operator's abstract. Package the background homework to make it
easy for us to catch up and easy to see if the effort is relevant
to us. Give ways for us to input to the process that is separated
from the "players" usual modes (eg mailing list)."
4.1.2. Alternative Communication Mediums
o "Offer communications options other than e-mail."
o "Surveys like this are a good start. Ask about the vendors we
have relationships with, what technologies we currently use, what
we're deploying now, and what we'd like to deploy in future."
o "Audio-only podcasts are a really great medium for busy people,
IMO. They convey the personality of the people who are presenting
them whilst still allowing us to do things like drive to work,
cook, vacuum, or jog."
Grundemann & Zorz Expires May 1, 2015 [Page 15]
Internet-Draft Operators and the IETF October 2014
o "RSS feeds that help busy people keep track of the really
important happenings would be good (maybe they exist already)."
o "Could RFCs be made more friendly in the following fronts: *
Readability: have an "human" English version and/or summary. *
Viewability: it seems the format followed is from the 80s. Make
changes to the font, format, etc. to make reading them more
appealing."
o "Make it easier and less time consuming, like having a simple
system for feedback on drafts and decisions."
o "Determine the questions to ask of Operators, and then start
distributing those questions/forms via social media and reddit."
o "Transition from ASCII Text RFCs to documents that support
figures. There was a time when text-only made sense, but that was
long ago. Figures made out of ASCII characters are difficult to
read and are not able to convey as much information."
o "Create polls for various important matters where operators vote.
Give the chance to operators to propose their ideas in simple
texts and then have an IETF expert help them translate this simple
text into an IETF doc. Ask the operators for various issues
regarding the current RFCs and get their proposals about them."
o "We need tools which makes IETF-related work more effective. For
example, my main problem is I can not see any way of easily track/
find all discussions related to a particular drafts. Let's say I
see that a very interesting draft has been published. Most likely
there will be a lot of different email threads going on so it is
really hard to track all discussions/comments."
4.2. Outreach
The next theme we heard is one of outreach to the operators,
primarily through existing network operator groups and forums but
also through more traditional marketing and publicity techniques:
o "More liaisons between the IETF and Operator forums"
o "Possibly smaller events like ARIN road show events for the
general IT community"
o "Participation in I.E.T.F needs to be demystified. Internet
Society needs to reach out to the operators and the local
technical community in every country to create awareness that
I.E.T.F is open for participation, it does have a membership
Grundemann & Zorz Expires May 1, 2015 [Page 16]
Internet-Draft Operators and the IETF October 2014
system, and that anyone who participates can equally contribute to
discussions on the same level as more qualified or frequent
participants. And that funding opportunities are open. And that
it is important for operators to take part."
o "I'd recommend signing up to popular mailing lists like NANOG or
CISCO and JUNIPER NSP and promote the ongoing IETF topics/agenda,
current meetings to encourage operators to take part in what they
find interesting"
o "The IETF could do a better job of making themselves known to
newbie networkers. Ask anyone who's been in the field for less
than two years and you're unlikely to get anything more detailed
than "Oh, uh, I think they write RFCs.""
o "Give more information about IETF no local engineers in local
languages with simple example of advantages of participation."
o "Post in relevant worldwide networking mailing lists when you have
information that wouldn't be spam like. For example, when you
post meetings, are also at an event related to the mailing list,
etc etc."
o "co-located sessions in Network Operators meetings"
o "Road shows at other well attended operator events (ie: NANOG,
MAAWG, etc)."
o "Promote IETF events and involvement through regional tech events
& meetups (in the Seattle area: NorthWest Tech Alliance /
SeattleTechForum) and industry related trade-shows and events
(NANOG / ARIN / PTC / SuperComputing / etc.). As well, providing
a brief summary of how to support / become involved with the IETF
which is promoted within the IETF pages and/or search results."
o "Try outreach programs to EDU operators. EDUs are the testbeds of
the past, present, and future. Engage us!"
o "1. IETF members presence on different conferences. 2. IETF must
publish examples of stories or good practices in e-zines or
participate at national events. 3. IETF must invest in promotion
and presence in various technical media, university curriculums,
national events."
o "Collocating (interim) IETF Meetings with RIPE/NANOG/etc meeting -
I attended an interim IETF meeting after a RIPE meeting - at least
for the ops groups."
Grundemann & Zorz Expires May 1, 2015 [Page 17]
Internet-Draft Operators and the IETF October 2014
o "Promote the IETF impact and role of standards to large operators
(education)."
o "Also setting up a IETF operators conference that is design to
bring the long term to the short term relevance and present it
ways that is significant to operators and not just RFCs that
vendors and operators have to figure how to make into products.
This should include the vendors that are creating products based
on new standards to present what they are doing with it. Would
provide real world ties to the work IETF is doing rather than RFCs
that get lost in code and are generally ignored by future
companies. You would be surprised how many new product vendors do
not have a clue about some of the older RFCs that are still HUGELY
significant when developing a device. Things like new vendor mini
conference that goes over operationally significant RFCs that they
should be building into their devices."
o "As for the Internet Society, probably modifying the mentorship
programs to be announced more on local mailing lists and also
require winners to spend some time on mailing lists before
attending events."
o "We are here in ISOC India Chennai Setting up a Remote Engagement
Hub (India) we will be requesting all Stake holders which includes
ISP/Telcos." (Also see LAC-IETF)
o "initially be possible to create regional forums that are
preparatory style operators to approach, understand the benefits
and challenges for both regional and continental as
implementations of the ietf can create a kind of good practice for
operators as Lationamerica less scale and the Caribbean."
o "Provide briefings to operator community on technologies that may
be relevant, and how to get up-to-speed on them. Actively seek
operator feedback on those technologies (this has been tried in
the past, but on a very one-off ad-hoc basis)."
o "Increase interaction and outreach between IETF and operator
forums, probably by identifying a subset of IETF drafts and areas
that could most benefit from additional operator input such that
we can focus the help that we're asking for - simply trying to
convince people to participate generically isn't likely to be
successful, while asking for specific feedback on specific items
will be seen as a better use of time. It may even be useful to
try to coordinate one meeting per year or every two years with an
operator forum to encourage cross-pollination."
Grundemann & Zorz Expires May 1, 2015 [Page 18]
Internet-Draft Operators and the IETF October 2014
o "It's a tough question... You need a "hot RFC" and turn it into a
media-backed frenzy. Something focus interest of a large number
of technical folks. You may also want to just elevate a few
select 'products'. Keep a few key items "up front". For
instance, take a look at Mozilla and Mozilla Labs. Even Google
and (now defunct) Google Labs. Push a few key "products" (of the
IETF's 7136 RFC's) and put them everywhere, showcase a few more.
Focus and push the technologies forward and you may get more
participation."
o "ensure that meaningful RFC's and other publications get more
press than TCP over Avian Carrier."
o "Strategic Plan of publicity about IETF and its main activities.
This strategic plan should be in several languages to reach
everyone."
o "I would love to see a list of reasons why operator participation
is needed and what the pay-off is for the operator, as well as the
community as a whole."
4.3. Inclusion
The final theme we found amongst the offered possible solutions is
one of inclusion. How can the IETF be more welcoming, in order to
bring participants in and keep them engaged? Survey respondents had
several ideas:
o "Welcoming our participation would be helpful."
o "make the operators feel more welcome"
o "Education."
o "Travel subsidy?"
o "Make remote participation easier."
o "Asking vendors to bring operators to the meetings. Planning a
few IETF meetings right before or after a big operator meeting
(e.g. RIPE, NANOG)"
o "Encourage non-technical participation, cultural/educational
program, beginner training."
o "Introduce works in multi language."
Grundemann & Zorz Expires May 1, 2015 [Page 19]
Internet-Draft Operators and the IETF October 2014
o "Well you see... [respondent wrote in Chinese characters here,
which we can not include in Internet-Draft formatting]"
o "Probably topical meetings (only for some area of IETF work) might
lessen the burden on the main meetings."
o "Provide some training opportunity during meetings to help justify
participation."
o "Provide scholarship and/or sponsorship to students, small
operators."
o "Provide more sponsorships"
o "Facilitate joining committees."
o "better discovery of projects. this may seem strange but perhaps a
match making site to better express interests and goals if
individuals and projects." (constituencies)
o "Smaller focused sessions"
o "It's hard for people in an operations-led post to make a
justification for a portion of their time and budget to be
invested in participating in the IETF. There's also the challenge
that as an operations person does manage to spend some more time
involved in the IETF and the standards process they end up doing
less operations and more standardisation work, and therefore their
input becomes less operationally relevant. There needs to be a
greater acceptance among the IETF attendees of the fact that
operationally focused people will dip in and out of the IETF as
their work requires."
o "Add more operational content."
o "Require standards to get the buy-in of a variety of operators."
o "if operator input was required in a "peer-review" fashion -- and
operators were represented from very large to very small"
o "Create a Service Provider input channel that is taken seriously.
The SPAC (Service Provider Action Committee) is an example that
exists within the Broadband Forum."
o "Having dedicated listeners might help. As in: someone who
actually listens to what operators say, tries to understand
whether "reality" looks different than the perfect theoretical
network design, and ensures that this is not drowned in other
Grundemann & Zorz Expires May 1, 2015 [Page 20]
Internet-Draft Operators and the IETF October 2014
discussions."
o "New ways of gathering people reducing the cost (remote
participations from multiple locations?)."
o "48 hour days :-) Back-to-back WG meetings with other relevant
conferences (ICANN or RIPE for DNS related topics would be the
obvious choices) to reduce travel time/budget."
o "Publish agendas early, lower the price of meetings and hotel
accommodations, have more operator relevant side meetings, gather
relevant working group meetings on the same day. Some interesting
side meetings would be, Internet Exchange meetings like Euro-IX,
joint NOG meetings, Peering forums, capacity update meetings,
etc."
o "Perhaps consider consolidating time by interest areas so that the
travel time demands were not as great."
o "I guess, having a BCOP (best current operational practices; like
http://bcop.nanog.org/ and http://www.ipbcop.org/) would attract
more operators." "Acknowledge operators. Provide them ways to
make a difference. For example, define a class of documents that
require the participation of at least two operators. That can be
against the usual convention of "individual" participation, but
anyway we know that it no longer holds..."
o "Suggest that the IETF working groups, especially the ones dealing
with topics that operators would have a significant interest in,
start to accept that operator requests may be valid even if they
are not in agreement with existing opinions."
o "I would restructure IETF to be more agile and remove the
political hierarchy of IETF that prevents wider participation.
The use of operators as working group Operator Councils rather
than just having Co-Chairs to determine what topics are good and
not good for that working group. ... The #1 thing is to remove
the politics of IETF so people with ideas and good suggestions are
not stifled by the IETF machine and the fulltime IETF
politicians."
o "While I know it can't be (and shouldn't be done), reduce the
voice of the people who seem to have nothing else to do than reply
to emails whole day. IETF should be about different views not
destroying everyone who don't agree with you."
o "Do some IETF meetings in our region, especially where there is
dense penetration of internet users as well as a strong technical
Grundemann & Zorz Expires May 1, 2015 [Page 21]
Internet-Draft Operators and the IETF October 2014
community (such as Southern and Eastern Africa)."
o "Try and group more operationally-relevant sessions together so
that it doesn't require a full week to participate."
o "It needs more open leadership. The top of the IETF is like merry
go round. The same folks make sure their colleagues all get jobs,
same names, same people, no change"
o "Operators don't care how the things are fixed, we do care if the
requirements are addressed. Create a WG for operators to
establish business needs, and customer needs - let them create
"requirement's documents" in the form of conceptual abstraction
meta models that can be put out in the body. Treat this as an
Open Framework a bit more, and lower the tribal culture a bit
less."
o "One day ticket is good idea. And place is important for us."
o "Better stewardship/shepherding of drafts and stopping the brain
damaged drafts from wasting WG time. Not everything requires IETF
work, nor needs to be written in a standard."
o "Internet society should do more educations in operators
management level. I notice that my company seems fonder on ATIS
and Cablelabs. I guess because the white papers published that
usually not require most technical people to understand. Thus,
management level can know what actually go on in industrial. On
the other hand, RFC is very technical. Management doesn't know
how that applies to them. So, some user-friendly introduction of
WG and how they can help operators may be good to present to
managements."
5. Conclusions
This section will be completed after WG discussion.
6. IANA Considerations
This document makes no request of IANA.
Note to RFC Editor: this section may be removed on publication as an
RFC.
Grundemann & Zorz Expires May 1, 2015 [Page 22]
Internet-Draft Operators and the IETF October 2014
7. Acknowledgments
Because the survey and many of our conversations were conducted
anonymously, we have left this section blank at this time. We have
however received lots of help from many members of the IETF and
operator communities. If you feel that you made a significant
contribution and would like your name to appear here, please let us
know and send us cookies :)
8. References
8.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
8.2. Informative References
[RFC3935] Alvestrand, H., "A Mission Statement for the IETF",
BCP 95, RFC 3935, October 2004.
Authors' Addresses
Chris Grundemann
Internet Society
150 West 9th Ave.
Denver, Colorado 80204
US
Phone: +1 303 351 1539
Email: grundemann@isoc.org
Jan Zorz
Internet Society
Frankovo naselje 165
Skofja Loka 4220
Slovenia
Phone: +38659042000
Email: zorz@isoc.org
Grundemann & Zorz Expires May 1, 2015 [Page 23]
