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]
