Internet DRAFT - draft-arkko-ietf-trends-and-observations

draft-arkko-ietf-trends-and-observations







Network Working Group                                      J. Arkko, Ed.
Internet-Draft                                                  Ericsson
Intended status: Informational                                  A. Atlas
Expires: September 1, 2016                              Juniper Networks
                                                                A. Doria
                                                                     APC
                                                              T. Gondrom
                                                                  Huawei
                                                              O. Kolkman
                                                       S. Olshansky, Ed.
                                                        Internet Society
                                                           B. Schliesser
                                                  Brocade Communications
                                                               R. Sparks
                                                                  Oracle
                                                                R. White
                                                                LinkedIn
                                                       February 29, 2016


                      IETF Trends and Observations
              draft-arkko-ietf-trends-and-observations-00

Abstract

   While most of the work in the IETF is technical, the IETF should and
   does regularly examine itself, including its processes and goals, to
   determine if the technical community is truly serving the larger
   network engineering community effectively.  Changes in this area tend
   to be incremental, as is fitting for an organization with decades of
   experience and history in developing and managing the process of
   building technical specifications.

   The rapid and ongoing changes in the world have recently caused a
   number of IETF participants to examine the current processes and
   operation of the IETF, particularly in the context of the culture of
   the IETF.  This memo discusses some cultural and global trends in
   relation to the IETF's operating environment, how these trends might
   affect the operation of the IETF, and notes some topics for further
   exploration.

   Writing this memo has been inspired by involvement in various
   decisions that the IETF leadership has to take part in, often wishing
   to be able to draw more on understanding trends and their impact on
   the IETF.

   This memo is also input for discussion that the IETF community should
   have.



Arkko, et al.           Expires September 1, 2016               [Page 1]

Internet-Draft        IETF Trends and Observations         February 2016


   The memo has no particular official standing, nor does it claim to
   represent more than the authors' thinking at the time of writing.
   There is no intent on the part of the authors for this to be
   published as a RFC.  Please direct discussion about this topic to the
   ietf@ietf.org mailing list.

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 September 1, 2016.

Copyright Notice

   Copyright (c) 2016 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.  Goals of the IETF . . . . . . . . . . . . . . . . . . . . . .   4
   3.  Problem Statement . . . . . . . . . . . . . . . . . . . . . .   5
   4.  Observations Relating to Participation  . . . . . . . . . . .   8
   5.  Observations Relating to Internet Technology Development
       Styles  . . . . . . . . . . . . . . . . . . . . . . . . . . .  15
   6.  Concluding Thoughts . . . . . . . . . . . . . . . . . . . . .  17
   7.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .  18



Arkko, et al.           Expires September 1, 2016               [Page 2]

Internet-Draft        IETF Trends and Observations         February 2016


   8.  Informative References  . . . . . . . . . . . . . . . . . . .  18
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  19

1.  Introduction

   While most of the work in the IETF is technical, as represented by
   the charters and daily work of the various working groups, the IETF
   should and does examine itself on a regular basis, looking at its
   processes and goals to determine if the technical community is truly
   serving the larger network engineering community effectively.
   Changes in this area tend to be incremental, as is fitting for an
   organization with the decades of experience and history in developing
   and managing the process of building technical specifications.

   Examples of recent non-technical topics include adjusting the IETF
   areas to be more suitable for the current work topics, discussion of
   IANA stewardship transition, adjustment of NomCom rules, and
   increasing diversity.

   The current rapid changes, both in the social and technical
   environments in which the IETF operates, have led a number of
   participants to spend time examining the IETF's operating
   environment.  This memo makes some observations about developments in
   the larger world, placing them in the context of larger ongoing
   changes, and discusses how these changes might impact the operation
   of the IETF.  After considering these things, this memo presents some
   avenues of thought about what "good" might look like within those
   trends - which might be helpful in considering incremental changes in
   the structure or operational procedures of the IETF.

   This memo is NOT focused on technical trends in the technology that
   the IETF is developing - while that discussion would be interesting,
   the focus of this memo is on things that affect the IETF as an
   organization.

   Will the IETF become a valuable repository of the past and a largely
   academic institution focused on the evolution of the Internet?  Or
   will it become the go-to place for companies to resolve their
   competing standards and protocols, relying on the wisdom of those
   that went before to devise a solution?  Or will it be reinvigorated
   by a new generation, finding their places due to the exit of the old
   guard and bringing new perspectives and approaches.

   Along these lines, the 30th IETF anniversary article in The Register
   [McCarthy2016] posed some interesting and relevant questions, noted
   here for reference.





Arkko, et al.           Expires September 1, 2016               [Page 3]

Internet-Draft        IETF Trends and Observations         February 2016


   In some cases, this memo also tries to provide some insight about
   what actions might be considered useful for the IETF to take within
   those trends.  The authors intend this document to be part of a set
   of ongoing discussions.  It discusses change, but is not trying to
   make any changes itself, particularly to standing documents like
   RFC3935.

   If the IETF better understood what its environment was doing and how
   it wants to evolve, it would be far easier to understand how to react
   to various new ideas or challenges that arise.

   This would also be helpful in the numerous concrete decisions that
   the IETF is facing.  For instance, the IETF website is undergoing
   redesign, and the Internet Society (ISOC) continues to make decisions
   regarding how it helps IETF reach sponsors or how outreach such as
   the fellows program is run.  Many of these decisions are tactical
   ones, but they would benefit from understanding the overall direction
   of the world around the IETF.

   Writing this memo has been inspired by involvement in various
   decisions that the IETF leadership has to take part in, often wishing
   to be able to draw more on understanding trends and their impact on
   the IETF.  Right now the leadership is taking some decisions in a
   fairly ad hoc manner, without as much written guidance as they would
   like.  This memo is also input for discussion that the IETF community
   should have, and as a foundation for discussing what the community
   might ask of the Internet Society ongoing in terms of support.

   The memo has no particular official standing, nor does it claim to
   represent more than the authors' thinking at the time of writing.
   Some of the memo may be useful background for the IETF leadership
   when they think about new ideas or change proposals.  There is no
   intent on the part of the authors for this to be published as a RFC.

   Please direct discussion about this topic to the ietf@ietf.org
   mailing list.

2.  Goals of the IETF

   The starting point of our work is that the IETF does not exist for
   the sake of itself.  It exists because (and only if) it can improve
   Internet technology, as noted in [RFC3935]:

        The goal of the IETF is to make the Internet work better.

   The broad purpose of the IETF is therefore Internet technology
   improvements.  Historically, the organization has developed the core




Arkko, et al.           Expires September 1, 2016               [Page 4]

Internet-Draft        IETF Trends and Observations         February 2016


   Internet technology, focusing on widely used and usable technologies
   rather than on more specific technologies.

   These technology improvements and extensions are of course only
   useful for the Internet, when the IETF can "... produce high quality,
   relevant technical and engineering documents that influence the way
   people design, use, and manage the Internet ..." [RFC3935].

   An often quoted key goal for the IETF work is that it should be
   relevant and timely.

   o  Horizontals and Verticals

   The IETF typically organizes its work around providing standardized
   building blocks for specific engineering challenges - "horizontals."
   It does not define or adapt "vertical" frameworks like "Smart
   Cities," "Internet of Things," or "5G networks."  It is implicitly
   assumed that the participants will apply the building blocks within
   the verticals.  As a result, organizations that work on technologies
   within those frameworks may not know, without understanding and
   following the technical scope of the various working groups, that
   they can contribute.  Conversely, it may in some cases be hard to
   recognize the applicability of certain IETF standards as building
   blocks within those verticals.

3.  Problem Statement

   Currently the various IETF topics are approached from, at best, an
   implicit acknowledgment of the changes in the landscape that the IETF
   operates in.  Since "A good strategy honestly acknowledges the
   challenges being faced and provides an approach to overcoming them"
   [Rumelt2011], a good understanding and analysis of the environments
   leads to a more coherent approach of the various issues.

   A more explicit understanding of the challenges is needed to help
   IETF leadership make better decisions, and so the community can
   decide what our general stance is towards various broader changes.

   Some examples may help illustrate where this more explicit
   understanding may be applied.

   One particular trend is the growing importance of the Free and Open
   Source Software (FOSS) movement.  The authors believe there is strong
   agreement within the IETF that we as a community need to be a part of
   the change by helping FOSS and open standards work together,
   combining their respective strengths in a way that creates value for
   the entire network engineering community.  Open source and open
   standards have a natural and symbiotic relationship, and



Arkko, et al.           Expires September 1, 2016               [Page 5]

Internet-Draft        IETF Trends and Observations         February 2016


   instantiation of open standards in open source projects strengthens
   the standards and the community at large.

   The IETF Hackathons are a second example.  How do they fit with our
   overall goals?  What are they expected to achieve, and what are the
   metrics for success?  Who should recruited to participate?  Should
   they aim for engagement with the broader technical community?  Should
   they focus primarily on implementing IETF technologies, or should
   they also have an explicit goal of promoting the adoption of those
   technologies in the broader technical community?  The question also
   arises as to whether hackathons should be considered outside of IETF
   meetings (as has been suggested).

   A third example is funding.  The IETF needs to understand what
   evolution its funding and sponsorship model will see in the coming
   years, amidst changing meeting participation style (such as remote
   participation, discussed next) or our increasing use of
   professionally run (outsourced) services.  While meeting attendance
   numbers have been relatively stable, costs are rising.

   A fourth example is the increase in remote participation, which
   drives several changes, including:

   o  decreased on-site meeting registration revenue

   o  significant changes under way in how working groups conduct their
      business at the main IETF meetings as well as at interim meetings

   o  fragmentation of the core community, resulting from less
      opportunities for all participants to engage in in-person
      interactions and ad hoc "hallway conversations" which are often
      among the most valuable aspects of the meetings for many
      participants, and which are the source of many serendipitous
      connections among attendees.

   Being able to understand potential changes is not just important for
   us.  With the long lead-times involved in implementing changes in an
   organization like the IETF, it is important that the community and
   leadership look ahead and make plans accordingly, to the extent
   practical.  It is also important for communicating with the sponsors
   and other funding sources.  It is a fortunate situation that there is
   substantial willingness to fund the IETF from all of these sources.
   But the IETF still needs to set the format and terms of this funding
   and make the right requests, in a long-term fashion.

   Some of these changes and trends may be obvious, and some not so
   obvious, but even for the obvious ones we have found that writing
   down the commonly agreed truths is useful in increasing our focus on



Arkko, et al.           Expires September 1, 2016               [Page 6]

Internet-Draft        IETF Trends and Observations         February 2016


   dealing with those truths.  And some of the topics mentioned above
   probably eventually deserve their own, in-depth treatment in threads
   or documents of their own.  But as the first step, we would like to
   get to the point of at least identifying the trends that we as a
   community need to talk about.

   Are there certain things that are or should be off limits for
   changing?  For example, the WG ID/RFC process?  The IETF mission is
   well understood and agreed, but the processes beneath it could use
   some work to refine and improve.  Interoperability is and will remain
   a key element in the work we do.

   A software release or document publication is a valuable rallying
   point.  How might we more effectively utilize these opportunities to
   increase our visibility and effectiveness?

   Can the IETF processes keep up with open source software development
   "in the wild," which is very rapid?  What changes could we consider
   which would serve to make us more agile and able to accommodate
   rapidly moving environments?  One possibility to consider would be to
   move to a standards release process that more closely resembles a
   software release process.  The bis process, and the inability to
   delete parts of specifications which have been overtaken by events or
   which no longer make sense without long and difficult arguments, or
   to delete things that just aren't being used at all, makes it harder
   to really understand and process the output of the IETF for those who
   are new or not very familiar with it.

   A key question to consider is what would motivate someone to bring
   new work into the IETF, instead of other potential alternatives?
   These alternatives typically include a combination of other Standards
   Developing Organizations (SDOs), open source efforts, and proprietary
   solutions.  What kinds of new work make sense to try to attract, and
   how do we make those decisions?  What could we do better to attract
   the sorts of new work that are appropriate for us?

   It has been observed that some vendors have been bringing
   technologies they have developed to the IETF seeking endorsement as a
   standard, and that this has been the case for a long time (i.e. this
   is not a new trend).  While some measures have been taken in the past
   to address this, e.g. some of the rules about document streams,
   should should other steps be taken?  If so, what?

   How can we encourage people to bring their problem sets to the IETF
   earlier in the process?  On the other side of that question, how can
   we as an organization avoid ideas being brought in that seem to be
   not fully thought out, and with little or no likelihood of community
   adoption.  In many cases it seems that the people promoting these



Arkko, et al.           Expires September 1, 2016               [Page 7]

Internet-Draft        IETF Trends and Observations         February 2016


   ideas are seeking use cases and problem statements, but not really
   going anywhere that we as a community would consider productive.
   This can be a major frustration, particularly when an area of work
   develops its own internal vocabulary that isn't (apparently) related
   to the rest of the world, or the complexity jumps to points where few
   people can read and understand the work because of specific corner
   cases.  Does the current working group process adequately address
   this, and if not, how might it be changed to better do so?  How could
   we better avoid trying to solve all problems and every corner case?

   In contrast to the early days of the Internet, which had the luxury
   of being able to work in a relatively smaller and more constrained
   and trusted environment, The Internet of Things (IoT) and its
   associated market forces are stepping up the pressure to move
   rapidly, while adding significant complexity and heterogeneity.  Does
   the IETF have a seat at this table, and should it?  If so, how might
   our processes evolve to enable us to be better equipped in this
   arena?

4.  Observations Relating to Participation

   Here are some trends and observations relating to participation in
   professional organizations such as the IETF:

   o  Over-the-net participation

      The ability to work together without being in the same place
      continues to improve; effective global communities can be built
      based on - at least to large extent - over-the-net collaboration.
      As engineers working on real-time communication among other
      things, this trend should be apparent to IETF participants.  This
      is not to say that in-person meetings will cease to be useful.

      There is usually an advantage to in-person meetings, and core
      participants of any significant organization will find ways to
      arrange such meetings.  IETF meetings will continue to run.
      However, it is just as likely that there will be some participants
      who would prefer to engage entirely over-the-net.  Or, to put it
      in another way: over-the-net participation significantly enlarges
      the pool of potential participants.

      Some of the implications of this trend relate to the growth and
      renewal of the IETF participant base, process rules related to
      meeting participation (such as nomcom eligibility), and financing
      models based primarily on meeting fees and meeting sponsorship.

      The IETF might consider evolving its participation models to
      ensure that growth in over-the-net participation is technically



Arkko, et al.           Expires September 1, 2016               [Page 8]

Internet-Draft        IETF Trends and Observations         February 2016


      possible, is an equally attractive alternative for the
      participants, and can be made an integral part of participant and
      sponsorship funding arrangements.

      An ideal situation might be meetings with a roughly equal number
      of participants as the IETF meetings have today, but a larger
      number of participants that attend only remotely, or only engage
      outside meetings.  There are a number of challenges facing current
      and potential participants, including restricted travel budgets,
      difficulty in obtaining visas, inability to leave work commitments
      for the necessary time, and difficulty in understanding and
      communicating in spoken English.

   o  Culture

      The culture of the IETF is evolving.  We have a joint set of
      values and traditions, some of which will stay but some of which
      will also change, with resulting benefits for IETF as an
      organization as well as for individual participants.

   o  Ecosystem

      The environment we are working in has become much larger and more
      complex over time, much of which is the result of more connected
      devices and services and the number of SDOs which are working on
      various pieces of the bigger picture.  If more of this work goes
      elsewhere (to other SDOs), there is the real risk that the overall
      community will see additional costs and other challenges in
      coordination.

      With this expansion comes a substantial increase in complexity,
      and along with that comes the risks of fragmentation.  This can be
      seen in different standards being developed on different parts of
      the ecosystem (Apple vs. Android, for instance) vs. more and
      possibly useful modularization of the ecosystem itself (e.g.
      IETF, IEEE, and 3GPP addressing different facets of the problem
      space).

      While the IETF has a history of liaising with other SDOs such as
      W3C and IEEE, more work on defining the IETF liaison role and
      activities would seem to be in our collective interest.

      The IETF brand is core Internet technology, and improving the
      Internet, not specifically new things.  The fundamental strength
      of the internet is that it is at the base of so much of our world,
      and the IETF keeps the internet running.

   o  Outreach



Arkko, et al.           Expires September 1, 2016               [Page 9]

Internet-Draft        IETF Trends and Observations         February 2016


      It is becoming clear that outreach will be an increasingly
      important component as the IETF moves ahead.  This could take many
      forms:

      *  outreach aimed at reaching new sets of people who deal with
         Internet technology, such as those working on open source

      *  outreach as in going out of our way to "market" our brand, for
         instance by underlining IETF's role as a key SDO in Internet
         technology matters

      *  outreach as in doing more to encourage and enable the use of
         remote hubs, and making them a key element of our participatory
         culture

      *  outreach as in paying for people from developing regions to
         participate, such as funding travel to IETF meetings or
         regional hubs

      It will be important for the IETF as a community to understand and
      come to consensus on where on this continuum we want to be.  In
      any case, outreach only makes sense in terms of reaching people
      who have a reasonable chance of becoming contributors in Internet
      technology standard matters.

   o  Marketing

      This includes being clear about what the IETF is doing, how, and
      why we do it the way that we do.  It is to our benefit to
      strengthen the IETF brand and to make the IETF and IETF results
      visible, and to make the IETF the preferred forum in which to
      start relevant new work.

   o  Political perception

      Politics and technology are becoming ever more intertwined,
      including things like the need to justify why standards-based
      systems are "acceptable" to various government entities with
      differing ideological and cultural norms.  We need to make sure
      that the adoption of and support for open, global standards are
      perceived as desirable.  Political acceptance of, and respect for,
      the IETF is important in this context.

      We note that awareness of the bigger ecosystem and political
      issues has been and remains a problem for the IETF community.
      Should we consider taking steps to inform and educate people more
      about these matters, for example by holding informational sessions
      at relevant events?  This might be something that the IAB/ISOC/



Arkko, et al.           Expires September 1, 2016              [Page 10]

Internet-Draft        IETF Trends and Observations         February 2016


      IETF liaisons should be prepared to do more often, on topics not
      just related to the specific organization/event but also other
      ongoing world developments.  Pervasive monitoring, IANA
      transition, and the current furor over encryption are examples of
      the types of opportunities in which the IETF could play a valuable
      role by providing reliable and credible information to counter
      misinformation and misunderstanding among policymakers and the
      press.

      There appears to be a perception among some that the IETF is, at
      least sometimes, beholden to vendors.  Working more effectively
      with the open source community, and working to expand
      participation among actual users (not just developers), might help
      this problem and the one described above.

      Finally, and related to the observation of variety of
      participation modes in the previous section, the Southern
      hemisphere is underrepresented in the IETF community.  This may,
      in the long term, impact the acceptance of the IETF output in
      those situations where policy support for its implementation is
      needed.  What should or could we as a community do to encourage
      broader participation?

   o  Internal Communication

      Along these same lines, internal communication among the community
      does and should also happen in ways other than in-person meetings.
      This is something that needs to be explored in more depth.
      Similarly, there is benefit to supporting communication channels
      outside of working groups, for example non-working group mailing
      lists.  Some of these may later become working groups, and some by
      their very nature are solely for discussion of topics that do not
      fit anywhere else.  A recent example of this is the "ietf-and-
      github" mailing list, and another is the "rtg-yang-coord" mailing
      list to allow cross-WG and cross-area coordination of YANG models
      related to the Routing Area; this has existed for over a year and
      seen significant use.

   o  Renewal and Diversity

      Many organizations, IETF included, go through a rapid initial
      growth phase, followed by more stable long-term existence.  It is,
      however, essential that organizations renew themselves, both in
      terms of how they work and their participation.  In particular,
      the inclusion of new generations of Internet technologists is
      essential to the long-term viability of an Internet standards
      organization.




Arkko, et al.           Expires September 1, 2016              [Page 11]

Internet-Draft        IETF Trends and Observations         February 2016


      But the renewal can obviously be thought of along different
      dimensions.  An important topic that has generated a lot of
      discussion at the IETF is the topic of diversity.  This is
      important in two ways.  First, creating an environment that is
      good for diverse participants is the right thing to do.  It brings
      substantial benefits to the IETF by enabling diverse teams to work
      together more effectively.

      Secondly, trends in deployment of the Internet in the developing
      world, for instance, may seem foreign to current participants.
      Being able to include participants that understand different
      business and cultural environments, different economic conditions,
      different branches of industry ("verticals"), and so on, is
      essential to developing technology that matches needs in those
      areas.

      The IETF works well due to the continued participation of many
      people with a broad range of expertise.  New people are attracted
      to work within the IETF when that expertise adds value to what
      they are working to achieve (see the geojson working group for a
      recent example).  We have a relatively simple set of processes,
      even if it sometimes feels heavy.  We have a framework for dealing
      with IPR issues that enables quick and open progress and
      resolution.

      In the IETF, as in many organizations with a long history, there
      can be a tendency of the "old guard" to become set in their ways,
      and to resist changes.  This sort of climate can be counter-
      productive, in that it can discourage participants from even
      suggesting substantive changes, and is something that we need to
      be able to recognize and address proactively when we see it.  As
      our environment evolves, such as the move toward the use of FOSS
      development methods, or the growing use of Github and other tools
      and services as collaboration and development platforms, we must
      be aware of how these changes are and will be affecting us, and be
      prepared to adapt.

   o  Modes of Participation

      Importantly, the IETF community is relatively quick to adapt to
      new styles of working together.  We expect groups to self-organize
      and choose ways of completing their work that fit the group best.
      The xmpp related groups sometimes met, often with very little
      meeting structure, over instant messaging.  The httpbis working
      group is making effective use of Github to track discussions and
      develop documents.  Groups are working with open source
      communities to build implementations and specification together,
      with quick feedback informing and improving each of those tasks.



Arkko, et al.           Expires September 1, 2016              [Page 12]

Internet-Draft        IETF Trends and Observations         February 2016


      As we evolve, we should find ways to make adopting new working
      techniques even easier.

      As the IETF grows, and people from more diverse parts of the world
      get involved, it might be useful to look at making greater use of
      remote participation to involve greater numbers of people and get
      work done.

      *  Working Group efforts

      Sometimes, periodic meetings drive work being done.  People
      naturally work to deadlines, and while the IETF meeting 3 times a
      year does serve as a forcing function for work to be completed,
      these meetings are far apart.  On the other hand meeting every two
      weeks or even monthly can help to drive a more uniform and
      continuous cycle - with more frequent milestones.

      *  Meetings - remote participation

      While some remote participation is used at meetings, it is still
      awkward.  Remote contributions, as opposed to just remote
      listening, often needs to be setup in advance.  While it is still
      possible to type something in a chat that is read by a jabber
      scribe, this does not really qualify as remote participation.  The
      software exists to do at least bi-directional voice, even if there
      are bandwidth limitation in some remote areas.  It should be
      largely an effort in implementation and education for chairs and
      others in the use of remote participation.

      *  Meeting - locations

      There has been discussion among some about the perceived benefits
      of settling on a few cities that we return to repeatedly, rather
      than moving around as we do.  A lot of this has to do with the
      availability of suitable meeting venues/hotels, and ease of
      travel.  There are valid arguments on both sides of this issue,
      and this will not be resolved easily or soon (given the long lead
      times required for meeting planning) but it is noted here as a
      topic needing further consideration.

      *  Use of hubs

      One way to do augment remote participation and increase diversity
      is to create hubs.  These hubs can participate in the sessions of
      the main meeting, but can also holds sessions in their local time
      zone on protocols or other relevant issues that have particular
      local or regional significance.




Arkko, et al.           Expires September 1, 2016              [Page 13]

Internet-Draft        IETF Trends and Observations         February 2016


      Hubs can augment existing IETF meetings and bring some of the
      benefits of face-to-face interactions to those who cannot travel
      consistently to IETF.  They may also be able to help crystallize
      geographically close communities of contributors to do technical
      collaboration.

      While it is possible to participate in the IETF on mailing lists,
      building personal relationships and understanding of the
      personalities of active participants helps greatly in
      interactions.  Traveling to IETF meetings involves significant
      amounts of time and money, and can require justifications of the
      usefulness and benefits to an employer - which are hard to
      articulate without having been there.  It is important that the
      IETF support and encourage not merely highly active "standards
      people" but also less standards-active people - such as
      developers.

      The IETF has some experience with Remote Hubs from the Internet
      Society's work encouraging them to prepare for the Buenos Aires
      IETF.  There are several factors that would collectively
      contribute to the success of remote hubs, which will be addressed
      in a separate document.  One factor that bears mentioning here is
      that for a hub to be effective, some of the "core" participants
      should participate in each hub.  This in turn involves travel
      expenses, as well as expenses for the venues if they do not have a
      local sponsor.

      Hubs however are not without challenges, and thus need to be
      managed carefully.  For example, there will be tendency for hub
      participants to look to each other even when they need to engage
      with the larger community.  Similarly, there may well be a
      tendency for the larger community to discount or misunderstand the
      participation at the hubs.

      *  Use of hackathons in the hubs

      There are many developers, especially of FOSS code, around the
      world in location that would never be able to travel to the major
      IETF meetings.  Not only would funding and time away from work be
      difficult, but visas might be very difficult or impossible to
      obtain.  This developer community, if sufficiently motivated,
      might be able to improve the tools we are using for remote
      participation and collaboration.

   o  Collaboration Considerations

      Deploying new collaboration tools and methods to established
      communities such as the IETF requires care and planning to ensure



Arkko, et al.           Expires September 1, 2016              [Page 14]

Internet-Draft        IETF Trends and Observations         February 2016


      success.  Leveraging the enthusiasm of influential early adopters
      can be a very effective strategy.  In SDOs like the IETF,
      participants might be broadly generalized as those engaged because
      they want to actively contribute and participate and influence the
      direction of the standards and technology, and those who are
      monitoring activity to stay informed about trends and directions
      that they can incorporate into their work as early adopters.  The
      tools and methods that are most effective and acceptable for these
      two types of participants will vary somewhat, and will be
      addressed in a separate document.

      An example of use of a collaboration platform that grew from
      community interest is Github.  As more of our participants become
      comfortable in its use and utilize it for their work, it has come
      to be used for document and code development in our context as
      well.

      As noted above, it has been widely observed that hallway meetings
      are often as, if not more, important than formal working group
      sessions, and this is one of the key motivators for many
      attendees.  A growing challenge is utilizing the available online
      tools to enable remote collaboration, creating community without
      losing the continuity.  Ultimately, building human connections as
      well as sustainable and productive community through online tools
      is an as yet unsolved problem.  While substantial progress has
      been made, there is still a long way to go.  "Unsanctioned"
      communication channels (that is, utilizing external means not
      managed by the IETF) are increasingly being used by working groups
      and subgroups, and this trend will continue to grow as the
      community seeks better ways to work together towards our common
      goals.  Rather than discouraging this trend, we should seek to
      share the learnings obtained among ourselves so that we can
      leverage each others' experiences and develop new and better ways
      to get our work done.  Building and reinforcing relationships is
      one of the keys to success of any successful organization.

5.  Observations Relating to Internet Technology Development Styles

   Here are some trends relating to how Internet technology is being
   developed:

   o  Open Source

      While open source has always been an important element of various
      Internet developments, in the last few years its importance has
      grown significantly.  A big part of networking development today
      happens in open source projects.  The ability of the IETF to
      usefully engage in this space, and to provide value for open



Arkko, et al.           Expires September 1, 2016              [Page 15]

Internet-Draft        IETF Trends and Observations         February 2016


      source development projects is essential.  Of course, there is no
      need for the IETF to try to replicate or compete with the open
      source efforts; standards will continue to be useful, but the
      standards need to be such that they and their development style
      fits with open source efforts.

   o  Rule of Code

      While running code has always been a key feature at the IETF, in
      today's fast-paced world it is even more important.  It is also
      important from the point of view of verifying that work that gets
      done has some useful connection to actual running systems (a
      necessary but not sufficient condition).

      As a result, being able to integrate more running code into the
      IETF process and into the IETF as a forum (meetings etc.) is
      likely to be useful going forward.  Recent experiences with
      Hackathons, interops, and other events provide good experience in
      this regard.

   o  Software Definition

      Another trend in the last decade has been software defined
      networking (SDN), which tends to mean several things.  For
      instance, SDN can mean:

      *  separation of the control plane from the forwarding plane

      *  centralization of the control plane into a small number of
         devices which interact with a distributed set of forwarding
         devices

      *  providing interfaces through which applications can interact
         with the control plane to guide traffic through an overlay of
         policy.

      The IETF can play a role in this movement by helping to define the
      terms used (providing taxonomies for all of the above), develop
      the right interfaces and models, and also to help mitigate the
      hype cycle in order to produce useful technical solutions while
      maintaining the interoperability of open standards.  Interaction
      with the FOSS movement could help facilitate these roles.

   o  Permissionless Innovation

      More generally, permissionless innovation - the ability to develop
      features without undue need to coordinate with others - has always
      been a key feature of the Internet.  The success of the Web, for



Arkko, et al.           Expires September 1, 2016              [Page 16]

Internet-Draft        IETF Trends and Observations         February 2016


      instance, lies largely in the ability of anyone to develop
      underlying frameworks and provide the content, features or
      applications on top without any coordination with anyone else.
      The Internet technology community works best when it can develop
      these successful frameworks with suitable amount of standards
      underneath, but leaving all the rest to whoever is employing the
      technology.

      Some might argue that this is the end of standards, i.e. being too
      successful with open-ended solutions that need no further
      standardization.  However there is a strong counter-argument that
      permissionless innovation is aided by standardization because it
      defines optional capabilities that can be used for making sure the
      permissionless tools, services, and features etc. have an
      environment in which they can flourish.  And even for wildly
      successful open-ended solutions such as the web, there seems to be
      a continuous need for further evolution of the web protocols, as
      evidenced by recent IETF work, for instance.  The authors believe
      that this is likely in other cases as well.  Success should not be
      feared, it should be embraced.

   o  The IETF as a reflection and enabler of the community's common
      interests

      At its core the IETF is a community that performs standardization
      through collaboration.  It is defined through its participation
      and the quality of the specifications it delivers.  Traditionally
      cross-area review, and interest and participation in other
      people's work, have driven the quality of the output.  It takes a
      serious investment on the part of participants to spend time on
      other technologies that are outside of their direct short term
      interests.  The same applies to the ability to invest in
      leadership activity.  If participation is solely driven around
      getting one's own work done then that might deteriorate the
      quality of the overall output and thereby the relevance of the
      IETF.

6.  Concluding Thoughts

   Any organization as large and diverse as the IETF, and having as
   significant a history and impact, will certainly face challenges as
   it evolves over time.  As the IETF changes, improving its cultural
   diversity and seeing the motivation for participation increasingly
   based on business interests, it remains important that we as an
   organization and a community take steps toward maintaining some key
   cultural values.  At the same time, our evolution will include
   changing others.  While this is to be expected, it can trigger some
   discomfort along the way.



Arkko, et al.           Expires September 1, 2016              [Page 17]

Internet-Draft        IETF Trends and Observations         February 2016


   The authors are of the opinion that the IETF community needs to give
   at least the topics discussed in this document (and those we missed)
   serious consideration, and engage in substantive dialogue as part of
   that process, toward the goal of planning our way forward.  Areas in
   particular that fall into the category of being in urgent need of
   discussion include potential changes in our financing and funding
   structure, renewal of the community, and ways in which we could
   facilitate and encourage more remote attendance.

   This document has addressed some of the trends, issues, and
   challenges that the authors see as having an impact on the IETF and
   the larger environment in which we operate, and which will need to be
   addressed in a meaningful way as the IETF moves ahead.  Some of these
   issues merit further consideration and exploration.  Two were noted
   above as potential topics for future documents:

   o  the use of remote hubs

   o  collaboration considerations

   Another topic that the authors propose as a subject for additional
   exploration is:

   o  what groups beyond the developing world, operators, and the open
      source community should the IETF be reaching out to, when, and in
      what ways?

   This document is offered as the starting point for discussion.

7.  Acknowledgements

   The initial version of this draft was the result of brainstorm and
   discussion among the authors as well several other people in the IETF
   community.  We would like to thank in particular Russ Housley, Andrew
   Sullivan, Michael Richardson, John Klensin, Charles Eckel, Benoit
   Claise, Ted Hardie, Stephen Farrell, and many others.

8.  Informative References

   [RFC3935]  Alvestrand, H., "A Mission Statement for the IETF", BCP
              95, RFC 3935, DOI 10.17487/RFC3935, October 2004,
              <http://www.rfc-editor.org/info/rfc3935>.

   [McCarthy2016]
              McCarthy, K., "Happy 30th birthday, IETF: The engineers
              who made the 'net happen", 2016,
              <http://www.theregister.co.uk/2016/01/16/happy_30th_birthd
              ay_ietf_now_what_you_going_to_do_with_your_life/>.



Arkko, et al.           Expires September 1, 2016              [Page 18]

Internet-Draft        IETF Trends and Observations         February 2016


   [Rumelt2011]
              Rumelt, R., "Good Strategy Bad Strategy: The Difference
              and Why It Matters", ISBN 978-0307886231, 2011.

Authors' Addresses

   Jari Arkko (editor)
   Ericsson

   Email: jari.arkko@piuha.net.com


   Alia Atlas
   Juniper Networks

   Email: akatlas@gmail.com


   Avri Doria
   APC

   Email: avri@apc.org


   Tobias Gondrom
   Huawei

   Email: tobias.gondrom@gondrom.org


   Olaf Kolkman
   Internet Society

   Email: kolkman@isoc.org


   Steve Olshansky (editor)
   Internet Society

   Email: olshansky@isoc.org


   Benson Schliesser
   Brocade Communications

   Email: bensons@queuefull.net





Arkko, et al.           Expires September 1, 2016              [Page 19]

Internet-Draft        IETF Trends and Observations         February 2016


   Robert Sparks
   Oracle

   Email: rjsparks@nostrum.com


   Russ White
   LinkedIn

   Email: russ@riw.us









































Arkko, et al.           Expires September 1, 2016              [Page 20]