idnits 2.17.1 draft-arkko-ietf-trends-and-observations-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (February 29, 2016) is 2950 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 2 errors (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group J. Arkko, Ed. 3 Internet-Draft Ericsson 4 Intended status: Informational A. Atlas 5 Expires: September 1, 2016 Juniper Networks 6 A. Doria 7 APC 8 T. Gondrom 9 Huawei 10 O. Kolkman 11 S. Olshansky, Ed. 12 Internet Society 13 B. Schliesser 14 Brocade Communications 15 R. Sparks 16 Oracle 17 R. White 18 LinkedIn 19 February 29, 2016 21 IETF Trends and Observations 22 draft-arkko-ietf-trends-and-observations-00 24 Abstract 26 While most of the work in the IETF is technical, the IETF should and 27 does regularly examine itself, including its processes and goals, to 28 determine if the technical community is truly serving the larger 29 network engineering community effectively. Changes in this area tend 30 to be incremental, as is fitting for an organization with decades of 31 experience and history in developing and managing the process of 32 building technical specifications. 34 The rapid and ongoing changes in the world have recently caused a 35 number of IETF participants to examine the current processes and 36 operation of the IETF, particularly in the context of the culture of 37 the IETF. This memo discusses some cultural and global trends in 38 relation to the IETF's operating environment, how these trends might 39 affect the operation of the IETF, and notes some topics for further 40 exploration. 42 Writing this memo has been inspired by involvement in various 43 decisions that the IETF leadership has to take part in, often wishing 44 to be able to draw more on understanding trends and their impact on 45 the IETF. 47 This memo is also input for discussion that the IETF community should 48 have. 50 The memo has no particular official standing, nor does it claim to 51 represent more than the authors' thinking at the time of writing. 52 There is no intent on the part of the authors for this to be 53 published as a RFC. Please direct discussion about this topic to the 54 ietf@ietf.org mailing list. 56 Status of This Memo 58 This Internet-Draft is submitted in full conformance with the 59 provisions of BCP 78 and BCP 79. 61 Internet-Drafts are working documents of the Internet Engineering 62 Task Force (IETF). Note that other groups may also distribute 63 working documents as Internet-Drafts. The list of current Internet- 64 Drafts is at http://datatracker.ietf.org/drafts/current/. 66 Internet-Drafts are draft documents valid for a maximum of six months 67 and may be updated, replaced, or obsoleted by other documents at any 68 time. It is inappropriate to use Internet-Drafts as reference 69 material or to cite them other than as "work in progress." 71 This Internet-Draft will expire on September 1, 2016. 73 Copyright Notice 75 Copyright (c) 2016 IETF Trust and the persons identified as the 76 document authors. All rights reserved. 78 This document is subject to BCP 78 and the IETF Trust's Legal 79 Provisions Relating to IETF Documents 80 (http://trustee.ietf.org/license-info) in effect on the date of 81 publication of this document. Please review these documents 82 carefully, as they describe your rights and restrictions with respect 83 to this document. Code Components extracted from this document must 84 include Simplified BSD License text as described in Section 4.e of 85 the Trust Legal Provisions and are provided without warranty as 86 described in the Simplified BSD License. 88 Table of Contents 90 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 91 2. Goals of the IETF . . . . . . . . . . . . . . . . . . . . . . 4 92 3. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 5 93 4. Observations Relating to Participation . . . . . . . . . . . 8 94 5. Observations Relating to Internet Technology Development 95 Styles . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 96 6. Concluding Thoughts . . . . . . . . . . . . . . . . . . . . . 17 97 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 18 98 8. Informative References . . . . . . . . . . . . . . . . . . . 18 99 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19 101 1. Introduction 103 While most of the work in the IETF is technical, as represented by 104 the charters and daily work of the various working groups, the IETF 105 should and does examine itself on a regular basis, looking at its 106 processes and goals to determine if the technical community is truly 107 serving the larger network engineering community effectively. 108 Changes in this area tend to be incremental, as is fitting for an 109 organization with the decades of experience and history in developing 110 and managing the process of building technical specifications. 112 Examples of recent non-technical topics include adjusting the IETF 113 areas to be more suitable for the current work topics, discussion of 114 IANA stewardship transition, adjustment of NomCom rules, and 115 increasing diversity. 117 The current rapid changes, both in the social and technical 118 environments in which the IETF operates, have led a number of 119 participants to spend time examining the IETF's operating 120 environment. This memo makes some observations about developments in 121 the larger world, placing them in the context of larger ongoing 122 changes, and discusses how these changes might impact the operation 123 of the IETF. After considering these things, this memo presents some 124 avenues of thought about what "good" might look like within those 125 trends - which might be helpful in considering incremental changes in 126 the structure or operational procedures of the IETF. 128 This memo is NOT focused on technical trends in the technology that 129 the IETF is developing - while that discussion would be interesting, 130 the focus of this memo is on things that affect the IETF as an 131 organization. 133 Will the IETF become a valuable repository of the past and a largely 134 academic institution focused on the evolution of the Internet? Or 135 will it become the go-to place for companies to resolve their 136 competing standards and protocols, relying on the wisdom of those 137 that went before to devise a solution? Or will it be reinvigorated 138 by a new generation, finding their places due to the exit of the old 139 guard and bringing new perspectives and approaches. 141 Along these lines, the 30th IETF anniversary article in The Register 142 [McCarthy2016] posed some interesting and relevant questions, noted 143 here for reference. 145 In some cases, this memo also tries to provide some insight about 146 what actions might be considered useful for the IETF to take within 147 those trends. The authors intend this document to be part of a set 148 of ongoing discussions. It discusses change, but is not trying to 149 make any changes itself, particularly to standing documents like 150 RFC3935. 152 If the IETF better understood what its environment was doing and how 153 it wants to evolve, it would be far easier to understand how to react 154 to various new ideas or challenges that arise. 156 This would also be helpful in the numerous concrete decisions that 157 the IETF is facing. For instance, the IETF website is undergoing 158 redesign, and the Internet Society (ISOC) continues to make decisions 159 regarding how it helps IETF reach sponsors or how outreach such as 160 the fellows program is run. Many of these decisions are tactical 161 ones, but they would benefit from understanding the overall direction 162 of the world around the IETF. 164 Writing this memo has been inspired by involvement in various 165 decisions that the IETF leadership has to take part in, often wishing 166 to be able to draw more on understanding trends and their impact on 167 the IETF. Right now the leadership is taking some decisions in a 168 fairly ad hoc manner, without as much written guidance as they would 169 like. This memo is also input for discussion that the IETF community 170 should have, and as a foundation for discussing what the community 171 might ask of the Internet Society ongoing in terms of support. 173 The memo has no particular official standing, nor does it claim to 174 represent more than the authors' thinking at the time of writing. 175 Some of the memo may be useful background for the IETF leadership 176 when they think about new ideas or change proposals. There is no 177 intent on the part of the authors for this to be published as a RFC. 179 Please direct discussion about this topic to the ietf@ietf.org 180 mailing list. 182 2. Goals of the IETF 184 The starting point of our work is that the IETF does not exist for 185 the sake of itself. It exists because (and only if) it can improve 186 Internet technology, as noted in [RFC3935]: 188 The goal of the IETF is to make the Internet work better. 190 The broad purpose of the IETF is therefore Internet technology 191 improvements. Historically, the organization has developed the core 192 Internet technology, focusing on widely used and usable technologies 193 rather than on more specific technologies. 195 These technology improvements and extensions are of course only 196 useful for the Internet, when the IETF can "... produce high quality, 197 relevant technical and engineering documents that influence the way 198 people design, use, and manage the Internet ..." [RFC3935]. 200 An often quoted key goal for the IETF work is that it should be 201 relevant and timely. 203 o Horizontals and Verticals 205 The IETF typically organizes its work around providing standardized 206 building blocks for specific engineering challenges - "horizontals." 207 It does not define or adapt "vertical" frameworks like "Smart 208 Cities," "Internet of Things," or "5G networks." It is implicitly 209 assumed that the participants will apply the building blocks within 210 the verticals. As a result, organizations that work on technologies 211 within those frameworks may not know, without understanding and 212 following the technical scope of the various working groups, that 213 they can contribute. Conversely, it may in some cases be hard to 214 recognize the applicability of certain IETF standards as building 215 blocks within those verticals. 217 3. Problem Statement 219 Currently the various IETF topics are approached from, at best, an 220 implicit acknowledgment of the changes in the landscape that the IETF 221 operates in. Since "A good strategy honestly acknowledges the 222 challenges being faced and provides an approach to overcoming them" 223 [Rumelt2011], a good understanding and analysis of the environments 224 leads to a more coherent approach of the various issues. 226 A more explicit understanding of the challenges is needed to help 227 IETF leadership make better decisions, and so the community can 228 decide what our general stance is towards various broader changes. 230 Some examples may help illustrate where this more explicit 231 understanding may be applied. 233 One particular trend is the growing importance of the Free and Open 234 Source Software (FOSS) movement. The authors believe there is strong 235 agreement within the IETF that we as a community need to be a part of 236 the change by helping FOSS and open standards work together, 237 combining their respective strengths in a way that creates value for 238 the entire network engineering community. Open source and open 239 standards have a natural and symbiotic relationship, and 240 instantiation of open standards in open source projects strengthens 241 the standards and the community at large. 243 The IETF Hackathons are a second example. How do they fit with our 244 overall goals? What are they expected to achieve, and what are the 245 metrics for success? Who should recruited to participate? Should 246 they aim for engagement with the broader technical community? Should 247 they focus primarily on implementing IETF technologies, or should 248 they also have an explicit goal of promoting the adoption of those 249 technologies in the broader technical community? The question also 250 arises as to whether hackathons should be considered outside of IETF 251 meetings (as has been suggested). 253 A third example is funding. The IETF needs to understand what 254 evolution its funding and sponsorship model will see in the coming 255 years, amidst changing meeting participation style (such as remote 256 participation, discussed next) or our increasing use of 257 professionally run (outsourced) services. While meeting attendance 258 numbers have been relatively stable, costs are rising. 260 A fourth example is the increase in remote participation, which 261 drives several changes, including: 263 o decreased on-site meeting registration revenue 265 o significant changes under way in how working groups conduct their 266 business at the main IETF meetings as well as at interim meetings 268 o fragmentation of the core community, resulting from less 269 opportunities for all participants to engage in in-person 270 interactions and ad hoc "hallway conversations" which are often 271 among the most valuable aspects of the meetings for many 272 participants, and which are the source of many serendipitous 273 connections among attendees. 275 Being able to understand potential changes is not just important for 276 us. With the long lead-times involved in implementing changes in an 277 organization like the IETF, it is important that the community and 278 leadership look ahead and make plans accordingly, to the extent 279 practical. It is also important for communicating with the sponsors 280 and other funding sources. It is a fortunate situation that there is 281 substantial willingness to fund the IETF from all of these sources. 282 But the IETF still needs to set the format and terms of this funding 283 and make the right requests, in a long-term fashion. 285 Some of these changes and trends may be obvious, and some not so 286 obvious, but even for the obvious ones we have found that writing 287 down the commonly agreed truths is useful in increasing our focus on 288 dealing with those truths. And some of the topics mentioned above 289 probably eventually deserve their own, in-depth treatment in threads 290 or documents of their own. But as the first step, we would like to 291 get to the point of at least identifying the trends that we as a 292 community need to talk about. 294 Are there certain things that are or should be off limits for 295 changing? For example, the WG ID/RFC process? The IETF mission is 296 well understood and agreed, but the processes beneath it could use 297 some work to refine and improve. Interoperability is and will remain 298 a key element in the work we do. 300 A software release or document publication is a valuable rallying 301 point. How might we more effectively utilize these opportunities to 302 increase our visibility and effectiveness? 304 Can the IETF processes keep up with open source software development 305 "in the wild," which is very rapid? What changes could we consider 306 which would serve to make us more agile and able to accommodate 307 rapidly moving environments? One possibility to consider would be to 308 move to a standards release process that more closely resembles a 309 software release process. The bis process, and the inability to 310 delete parts of specifications which have been overtaken by events or 311 which no longer make sense without long and difficult arguments, or 312 to delete things that just aren't being used at all, makes it harder 313 to really understand and process the output of the IETF for those who 314 are new or not very familiar with it. 316 A key question to consider is what would motivate someone to bring 317 new work into the IETF, instead of other potential alternatives? 318 These alternatives typically include a combination of other Standards 319 Developing Organizations (SDOs), open source efforts, and proprietary 320 solutions. What kinds of new work make sense to try to attract, and 321 how do we make those decisions? What could we do better to attract 322 the sorts of new work that are appropriate for us? 324 It has been observed that some vendors have been bringing 325 technologies they have developed to the IETF seeking endorsement as a 326 standard, and that this has been the case for a long time (i.e. this 327 is not a new trend). While some measures have been taken in the past 328 to address this, e.g. some of the rules about document streams, 329 should should other steps be taken? If so, what? 331 How can we encourage people to bring their problem sets to the IETF 332 earlier in the process? On the other side of that question, how can 333 we as an organization avoid ideas being brought in that seem to be 334 not fully thought out, and with little or no likelihood of community 335 adoption. In many cases it seems that the people promoting these 336 ideas are seeking use cases and problem statements, but not really 337 going anywhere that we as a community would consider productive. 338 This can be a major frustration, particularly when an area of work 339 develops its own internal vocabulary that isn't (apparently) related 340 to the rest of the world, or the complexity jumps to points where few 341 people can read and understand the work because of specific corner 342 cases. Does the current working group process adequately address 343 this, and if not, how might it be changed to better do so? How could 344 we better avoid trying to solve all problems and every corner case? 346 In contrast to the early days of the Internet, which had the luxury 347 of being able to work in a relatively smaller and more constrained 348 and trusted environment, The Internet of Things (IoT) and its 349 associated market forces are stepping up the pressure to move 350 rapidly, while adding significant complexity and heterogeneity. Does 351 the IETF have a seat at this table, and should it? If so, how might 352 our processes evolve to enable us to be better equipped in this 353 arena? 355 4. Observations Relating to Participation 357 Here are some trends and observations relating to participation in 358 professional organizations such as the IETF: 360 o Over-the-net participation 362 The ability to work together without being in the same place 363 continues to improve; effective global communities can be built 364 based on - at least to large extent - over-the-net collaboration. 365 As engineers working on real-time communication among other 366 things, this trend should be apparent to IETF participants. This 367 is not to say that in-person meetings will cease to be useful. 369 There is usually an advantage to in-person meetings, and core 370 participants of any significant organization will find ways to 371 arrange such meetings. IETF meetings will continue to run. 372 However, it is just as likely that there will be some participants 373 who would prefer to engage entirely over-the-net. Or, to put it 374 in another way: over-the-net participation significantly enlarges 375 the pool of potential participants. 377 Some of the implications of this trend relate to the growth and 378 renewal of the IETF participant base, process rules related to 379 meeting participation (such as nomcom eligibility), and financing 380 models based primarily on meeting fees and meeting sponsorship. 382 The IETF might consider evolving its participation models to 383 ensure that growth in over-the-net participation is technically 384 possible, is an equally attractive alternative for the 385 participants, and can be made an integral part of participant and 386 sponsorship funding arrangements. 388 An ideal situation might be meetings with a roughly equal number 389 of participants as the IETF meetings have today, but a larger 390 number of participants that attend only remotely, or only engage 391 outside meetings. There are a number of challenges facing current 392 and potential participants, including restricted travel budgets, 393 difficulty in obtaining visas, inability to leave work commitments 394 for the necessary time, and difficulty in understanding and 395 communicating in spoken English. 397 o Culture 399 The culture of the IETF is evolving. We have a joint set of 400 values and traditions, some of which will stay but some of which 401 will also change, with resulting benefits for IETF as an 402 organization as well as for individual participants. 404 o Ecosystem 406 The environment we are working in has become much larger and more 407 complex over time, much of which is the result of more connected 408 devices and services and the number of SDOs which are working on 409 various pieces of the bigger picture. If more of this work goes 410 elsewhere (to other SDOs), there is the real risk that the overall 411 community will see additional costs and other challenges in 412 coordination. 414 With this expansion comes a substantial increase in complexity, 415 and along with that comes the risks of fragmentation. This can be 416 seen in different standards being developed on different parts of 417 the ecosystem (Apple vs. Android, for instance) vs. more and 418 possibly useful modularization of the ecosystem itself (e.g. 419 IETF, IEEE, and 3GPP addressing different facets of the problem 420 space). 422 While the IETF has a history of liaising with other SDOs such as 423 W3C and IEEE, more work on defining the IETF liaison role and 424 activities would seem to be in our collective interest. 426 The IETF brand is core Internet technology, and improving the 427 Internet, not specifically new things. The fundamental strength 428 of the internet is that it is at the base of so much of our world, 429 and the IETF keeps the internet running. 431 o Outreach 432 It is becoming clear that outreach will be an increasingly 433 important component as the IETF moves ahead. This could take many 434 forms: 436 * outreach aimed at reaching new sets of people who deal with 437 Internet technology, such as those working on open source 439 * outreach as in going out of our way to "market" our brand, for 440 instance by underlining IETF's role as a key SDO in Internet 441 technology matters 443 * outreach as in doing more to encourage and enable the use of 444 remote hubs, and making them a key element of our participatory 445 culture 447 * outreach as in paying for people from developing regions to 448 participate, such as funding travel to IETF meetings or 449 regional hubs 451 It will be important for the IETF as a community to understand and 452 come to consensus on where on this continuum we want to be. In 453 any case, outreach only makes sense in terms of reaching people 454 who have a reasonable chance of becoming contributors in Internet 455 technology standard matters. 457 o Marketing 459 This includes being clear about what the IETF is doing, how, and 460 why we do it the way that we do. It is to our benefit to 461 strengthen the IETF brand and to make the IETF and IETF results 462 visible, and to make the IETF the preferred forum in which to 463 start relevant new work. 465 o Political perception 467 Politics and technology are becoming ever more intertwined, 468 including things like the need to justify why standards-based 469 systems are "acceptable" to various government entities with 470 differing ideological and cultural norms. We need to make sure 471 that the adoption of and support for open, global standards are 472 perceived as desirable. Political acceptance of, and respect for, 473 the IETF is important in this context. 475 We note that awareness of the bigger ecosystem and political 476 issues has been and remains a problem for the IETF community. 477 Should we consider taking steps to inform and educate people more 478 about these matters, for example by holding informational sessions 479 at relevant events? This might be something that the IAB/ISOC/ 480 IETF liaisons should be prepared to do more often, on topics not 481 just related to the specific organization/event but also other 482 ongoing world developments. Pervasive monitoring, IANA 483 transition, and the current furor over encryption are examples of 484 the types of opportunities in which the IETF could play a valuable 485 role by providing reliable and credible information to counter 486 misinformation and misunderstanding among policymakers and the 487 press. 489 There appears to be a perception among some that the IETF is, at 490 least sometimes, beholden to vendors. Working more effectively 491 with the open source community, and working to expand 492 participation among actual users (not just developers), might help 493 this problem and the one described above. 495 Finally, and related to the observation of variety of 496 participation modes in the previous section, the Southern 497 hemisphere is underrepresented in the IETF community. This may, 498 in the long term, impact the acceptance of the IETF output in 499 those situations where policy support for its implementation is 500 needed. What should or could we as a community do to encourage 501 broader participation? 503 o Internal Communication 505 Along these same lines, internal communication among the community 506 does and should also happen in ways other than in-person meetings. 507 This is something that needs to be explored in more depth. 508 Similarly, there is benefit to supporting communication channels 509 outside of working groups, for example non-working group mailing 510 lists. Some of these may later become working groups, and some by 511 their very nature are solely for discussion of topics that do not 512 fit anywhere else. A recent example of this is the "ietf-and- 513 github" mailing list, and another is the "rtg-yang-coord" mailing 514 list to allow cross-WG and cross-area coordination of YANG models 515 related to the Routing Area; this has existed for over a year and 516 seen significant use. 518 o Renewal and Diversity 520 Many organizations, IETF included, go through a rapid initial 521 growth phase, followed by more stable long-term existence. It is, 522 however, essential that organizations renew themselves, both in 523 terms of how they work and their participation. In particular, 524 the inclusion of new generations of Internet technologists is 525 essential to the long-term viability of an Internet standards 526 organization. 528 But the renewal can obviously be thought of along different 529 dimensions. An important topic that has generated a lot of 530 discussion at the IETF is the topic of diversity. This is 531 important in two ways. First, creating an environment that is 532 good for diverse participants is the right thing to do. It brings 533 substantial benefits to the IETF by enabling diverse teams to work 534 together more effectively. 536 Secondly, trends in deployment of the Internet in the developing 537 world, for instance, may seem foreign to current participants. 538 Being able to include participants that understand different 539 business and cultural environments, different economic conditions, 540 different branches of industry ("verticals"), and so on, is 541 essential to developing technology that matches needs in those 542 areas. 544 The IETF works well due to the continued participation of many 545 people with a broad range of expertise. New people are attracted 546 to work within the IETF when that expertise adds value to what 547 they are working to achieve (see the geojson working group for a 548 recent example). We have a relatively simple set of processes, 549 even if it sometimes feels heavy. We have a framework for dealing 550 with IPR issues that enables quick and open progress and 551 resolution. 553 In the IETF, as in many organizations with a long history, there 554 can be a tendency of the "old guard" to become set in their ways, 555 and to resist changes. This sort of climate can be counter- 556 productive, in that it can discourage participants from even 557 suggesting substantive changes, and is something that we need to 558 be able to recognize and address proactively when we see it. As 559 our environment evolves, such as the move toward the use of FOSS 560 development methods, or the growing use of Github and other tools 561 and services as collaboration and development platforms, we must 562 be aware of how these changes are and will be affecting us, and be 563 prepared to adapt. 565 o Modes of Participation 567 Importantly, the IETF community is relatively quick to adapt to 568 new styles of working together. We expect groups to self-organize 569 and choose ways of completing their work that fit the group best. 570 The xmpp related groups sometimes met, often with very little 571 meeting structure, over instant messaging. The httpbis working 572 group is making effective use of Github to track discussions and 573 develop documents. Groups are working with open source 574 communities to build implementations and specification together, 575 with quick feedback informing and improving each of those tasks. 577 As we evolve, we should find ways to make adopting new working 578 techniques even easier. 580 As the IETF grows, and people from more diverse parts of the world 581 get involved, it might be useful to look at making greater use of 582 remote participation to involve greater numbers of people and get 583 work done. 585 * Working Group efforts 587 Sometimes, periodic meetings drive work being done. People 588 naturally work to deadlines, and while the IETF meeting 3 times a 589 year does serve as a forcing function for work to be completed, 590 these meetings are far apart. On the other hand meeting every two 591 weeks or even monthly can help to drive a more uniform and 592 continuous cycle - with more frequent milestones. 594 * Meetings - remote participation 596 While some remote participation is used at meetings, it is still 597 awkward. Remote contributions, as opposed to just remote 598 listening, often needs to be setup in advance. While it is still 599 possible to type something in a chat that is read by a jabber 600 scribe, this does not really qualify as remote participation. The 601 software exists to do at least bi-directional voice, even if there 602 are bandwidth limitation in some remote areas. It should be 603 largely an effort in implementation and education for chairs and 604 others in the use of remote participation. 606 * Meeting - locations 608 There has been discussion among some about the perceived benefits 609 of settling on a few cities that we return to repeatedly, rather 610 than moving around as we do. A lot of this has to do with the 611 availability of suitable meeting venues/hotels, and ease of 612 travel. There are valid arguments on both sides of this issue, 613 and this will not be resolved easily or soon (given the long lead 614 times required for meeting planning) but it is noted here as a 615 topic needing further consideration. 617 * Use of hubs 619 One way to do augment remote participation and increase diversity 620 is to create hubs. These hubs can participate in the sessions of 621 the main meeting, but can also holds sessions in their local time 622 zone on protocols or other relevant issues that have particular 623 local or regional significance. 625 Hubs can augment existing IETF meetings and bring some of the 626 benefits of face-to-face interactions to those who cannot travel 627 consistently to IETF. They may also be able to help crystallize 628 geographically close communities of contributors to do technical 629 collaboration. 631 While it is possible to participate in the IETF on mailing lists, 632 building personal relationships and understanding of the 633 personalities of active participants helps greatly in 634 interactions. Traveling to IETF meetings involves significant 635 amounts of time and money, and can require justifications of the 636 usefulness and benefits to an employer - which are hard to 637 articulate without having been there. It is important that the 638 IETF support and encourage not merely highly active "standards 639 people" but also less standards-active people - such as 640 developers. 642 The IETF has some experience with Remote Hubs from the Internet 643 Society's work encouraging them to prepare for the Buenos Aires 644 IETF. There are several factors that would collectively 645 contribute to the success of remote hubs, which will be addressed 646 in a separate document. One factor that bears mentioning here is 647 that for a hub to be effective, some of the "core" participants 648 should participate in each hub. This in turn involves travel 649 expenses, as well as expenses for the venues if they do not have a 650 local sponsor. 652 Hubs however are not without challenges, and thus need to be 653 managed carefully. For example, there will be tendency for hub 654 participants to look to each other even when they need to engage 655 with the larger community. Similarly, there may well be a 656 tendency for the larger community to discount or misunderstand the 657 participation at the hubs. 659 * Use of hackathons in the hubs 661 There are many developers, especially of FOSS code, around the 662 world in location that would never be able to travel to the major 663 IETF meetings. Not only would funding and time away from work be 664 difficult, but visas might be very difficult or impossible to 665 obtain. This developer community, if sufficiently motivated, 666 might be able to improve the tools we are using for remote 667 participation and collaboration. 669 o Collaboration Considerations 671 Deploying new collaboration tools and methods to established 672 communities such as the IETF requires care and planning to ensure 673 success. Leveraging the enthusiasm of influential early adopters 674 can be a very effective strategy. In SDOs like the IETF, 675 participants might be broadly generalized as those engaged because 676 they want to actively contribute and participate and influence the 677 direction of the standards and technology, and those who are 678 monitoring activity to stay informed about trends and directions 679 that they can incorporate into their work as early adopters. The 680 tools and methods that are most effective and acceptable for these 681 two types of participants will vary somewhat, and will be 682 addressed in a separate document. 684 An example of use of a collaboration platform that grew from 685 community interest is Github. As more of our participants become 686 comfortable in its use and utilize it for their work, it has come 687 to be used for document and code development in our context as 688 well. 690 As noted above, it has been widely observed that hallway meetings 691 are often as, if not more, important than formal working group 692 sessions, and this is one of the key motivators for many 693 attendees. A growing challenge is utilizing the available online 694 tools to enable remote collaboration, creating community without 695 losing the continuity. Ultimately, building human connections as 696 well as sustainable and productive community through online tools 697 is an as yet unsolved problem. While substantial progress has 698 been made, there is still a long way to go. "Unsanctioned" 699 communication channels (that is, utilizing external means not 700 managed by the IETF) are increasingly being used by working groups 701 and subgroups, and this trend will continue to grow as the 702 community seeks better ways to work together towards our common 703 goals. Rather than discouraging this trend, we should seek to 704 share the learnings obtained among ourselves so that we can 705 leverage each others' experiences and develop new and better ways 706 to get our work done. Building and reinforcing relationships is 707 one of the keys to success of any successful organization. 709 5. Observations Relating to Internet Technology Development Styles 711 Here are some trends relating to how Internet technology is being 712 developed: 714 o Open Source 716 While open source has always been an important element of various 717 Internet developments, in the last few years its importance has 718 grown significantly. A big part of networking development today 719 happens in open source projects. The ability of the IETF to 720 usefully engage in this space, and to provide value for open 721 source development projects is essential. Of course, there is no 722 need for the IETF to try to replicate or compete with the open 723 source efforts; standards will continue to be useful, but the 724 standards need to be such that they and their development style 725 fits with open source efforts. 727 o Rule of Code 729 While running code has always been a key feature at the IETF, in 730 today's fast-paced world it is even more important. It is also 731 important from the point of view of verifying that work that gets 732 done has some useful connection to actual running systems (a 733 necessary but not sufficient condition). 735 As a result, being able to integrate more running code into the 736 IETF process and into the IETF as a forum (meetings etc.) is 737 likely to be useful going forward. Recent experiences with 738 Hackathons, interops, and other events provide good experience in 739 this regard. 741 o Software Definition 743 Another trend in the last decade has been software defined 744 networking (SDN), which tends to mean several things. For 745 instance, SDN can mean: 747 * separation of the control plane from the forwarding plane 749 * centralization of the control plane into a small number of 750 devices which interact with a distributed set of forwarding 751 devices 753 * providing interfaces through which applications can interact 754 with the control plane to guide traffic through an overlay of 755 policy. 757 The IETF can play a role in this movement by helping to define the 758 terms used (providing taxonomies for all of the above), develop 759 the right interfaces and models, and also to help mitigate the 760 hype cycle in order to produce useful technical solutions while 761 maintaining the interoperability of open standards. Interaction 762 with the FOSS movement could help facilitate these roles. 764 o Permissionless Innovation 766 More generally, permissionless innovation - the ability to develop 767 features without undue need to coordinate with others - has always 768 been a key feature of the Internet. The success of the Web, for 769 instance, lies largely in the ability of anyone to develop 770 underlying frameworks and provide the content, features or 771 applications on top without any coordination with anyone else. 772 The Internet technology community works best when it can develop 773 these successful frameworks with suitable amount of standards 774 underneath, but leaving all the rest to whoever is employing the 775 technology. 777 Some might argue that this is the end of standards, i.e. being too 778 successful with open-ended solutions that need no further 779 standardization. However there is a strong counter-argument that 780 permissionless innovation is aided by standardization because it 781 defines optional capabilities that can be used for making sure the 782 permissionless tools, services, and features etc. have an 783 environment in which they can flourish. And even for wildly 784 successful open-ended solutions such as the web, there seems to be 785 a continuous need for further evolution of the web protocols, as 786 evidenced by recent IETF work, for instance. The authors believe 787 that this is likely in other cases as well. Success should not be 788 feared, it should be embraced. 790 o The IETF as a reflection and enabler of the community's common 791 interests 793 At its core the IETF is a community that performs standardization 794 through collaboration. It is defined through its participation 795 and the quality of the specifications it delivers. Traditionally 796 cross-area review, and interest and participation in other 797 people's work, have driven the quality of the output. It takes a 798 serious investment on the part of participants to spend time on 799 other technologies that are outside of their direct short term 800 interests. The same applies to the ability to invest in 801 leadership activity. If participation is solely driven around 802 getting one's own work done then that might deteriorate the 803 quality of the overall output and thereby the relevance of the 804 IETF. 806 6. Concluding Thoughts 808 Any organization as large and diverse as the IETF, and having as 809 significant a history and impact, will certainly face challenges as 810 it evolves over time. As the IETF changes, improving its cultural 811 diversity and seeing the motivation for participation increasingly 812 based on business interests, it remains important that we as an 813 organization and a community take steps toward maintaining some key 814 cultural values. At the same time, our evolution will include 815 changing others. While this is to be expected, it can trigger some 816 discomfort along the way. 818 The authors are of the opinion that the IETF community needs to give 819 at least the topics discussed in this document (and those we missed) 820 serious consideration, and engage in substantive dialogue as part of 821 that process, toward the goal of planning our way forward. Areas in 822 particular that fall into the category of being in urgent need of 823 discussion include potential changes in our financing and funding 824 structure, renewal of the community, and ways in which we could 825 facilitate and encourage more remote attendance. 827 This document has addressed some of the trends, issues, and 828 challenges that the authors see as having an impact on the IETF and 829 the larger environment in which we operate, and which will need to be 830 addressed in a meaningful way as the IETF moves ahead. Some of these 831 issues merit further consideration and exploration. Two were noted 832 above as potential topics for future documents: 834 o the use of remote hubs 836 o collaboration considerations 838 Another topic that the authors propose as a subject for additional 839 exploration is: 841 o what groups beyond the developing world, operators, and the open 842 source community should the IETF be reaching out to, when, and in 843 what ways? 845 This document is offered as the starting point for discussion. 847 7. Acknowledgements 849 The initial version of this draft was the result of brainstorm and 850 discussion among the authors as well several other people in the IETF 851 community. We would like to thank in particular Russ Housley, Andrew 852 Sullivan, Michael Richardson, John Klensin, Charles Eckel, Benoit 853 Claise, Ted Hardie, Stephen Farrell, and many others. 855 8. Informative References 857 [RFC3935] Alvestrand, H., "A Mission Statement for the IETF", BCP 858 95, RFC 3935, DOI 10.17487/RFC3935, October 2004, 859 . 861 [McCarthy2016] 862 McCarthy, K., "Happy 30th birthday, IETF: The engineers 863 who made the 'net happen", 2016, 864 . 867 [Rumelt2011] 868 Rumelt, R., "Good Strategy Bad Strategy: The Difference 869 and Why It Matters", ISBN 978-0307886231, 2011. 871 Authors' Addresses 873 Jari Arkko (editor) 874 Ericsson 876 Email: jari.arkko@piuha.net.com 878 Alia Atlas 879 Juniper Networks 881 Email: akatlas@gmail.com 883 Avri Doria 884 APC 886 Email: avri@apc.org 888 Tobias Gondrom 889 Huawei 891 Email: tobias.gondrom@gondrom.org 893 Olaf Kolkman 894 Internet Society 896 Email: kolkman@isoc.org 898 Steve Olshansky (editor) 899 Internet Society 901 Email: olshansky@isoc.org 903 Benson Schliesser 904 Brocade Communications 906 Email: bensons@queuefull.net 907 Robert Sparks 908 Oracle 910 Email: rjsparks@nostrum.com 912 Russ White 913 LinkedIn 915 Email: russ@riw.us