[Docs] [txt|pdf|xml] [Tracker] [Email] [Nits]

Versions: 00

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]


Html markup produced by rfcmarkup 1.126, available from https://tools.ietf.org/tools/rfcmarkup/