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, . [McCarthy2016] McCarthy, K., "Happy 30th birthday, IETF: The engineers who made the 'net happen", 2016, . 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]