idnits 2.17.1 draft-opsawg-operators-ietf-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. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (October 28, 2014) is 3467 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group C. Grundemann 3 Internet-Draft J. Zorz 4 Intended status: Informational Internet Society 5 Expires: May 1, 2015 October 28, 2014 7 Operators and the IETF 8 draft-opsawg-operators-ietf-00 10 Abstract 12 Internet Society has launched a new project to address the perceived 13 gap between Operators and the IETF. The objective of this project is 14 ultimately to facilitate communications between the operator 15 community and the IETF to help ensure that operational realities 16 inform the development of key standards. The first phase of this 17 project was a survey of the operator community that was conducted 18 over the first half of 2014. This I-D aims to synthesize the initial 19 survey results, along with information we collected directly from 20 operators during the survey window. The primary purpose of doing 21 this is to start a conversation which we hope will lead to increases 22 in the level of operational input and feedback to the IETF standards 23 making process. 25 Requirements Language 27 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 28 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 29 document are to be interpreted as described in RFC 2119 [RFC2119]. 31 Status of this Memo 33 This Internet-Draft is submitted in full conformance with the 34 provisions of BCP 78 and BCP 79. 36 Internet-Drafts are working documents of the Internet Engineering 37 Task Force (IETF). Note that other groups may also distribute 38 working documents as Internet-Drafts. The list of current Internet- 39 Drafts is at http://datatracker.ietf.org/drafts/current/. 41 Internet-Drafts are draft documents valid for a maximum of six months 42 and may be updated, replaced, or obsoleted by other documents at any 43 time. It is inappropriate to use Internet-Drafts as reference 44 material or to cite them other than as "work in progress." 46 This Internet-Draft will expire on May 1, 2015. 48 Copyright Notice 49 Copyright (c) 2014 IETF Trust and the persons identified as the 50 document authors. All rights reserved. 52 This document is subject to BCP 78 and the IETF Trust's Legal 53 Provisions Relating to IETF Documents 54 (http://trustee.ietf.org/license-info) in effect on the date of 55 publication of this document. Please review these documents 56 carefully, as they describe your rights and restrictions with respect 57 to this document. Code Components extracted from this document must 58 include Simplified BSD License text as described in Section 4.e of 59 the Trust Legal Provisions and are provided without warranty as 60 described in the Simplified BSD License. 62 Table of Contents 64 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 65 2. Survey respondents . . . . . . . . . . . . . . . . . . . . . . 4 66 2.1. Job type . . . . . . . . . . . . . . . . . . . . . . . . . 4 67 2.2. IETF Involvement . . . . . . . . . . . . . . . . . . . . . 5 68 2.2.1. Do not currently participate in the IETF . . . . . . . 5 69 2.2.2. Do not currently participate on IETF mailing lists . . 6 70 2.2.3. Do not currently participate in IETF meetings . . . . 8 71 3. Potential Challenges . . . . . . . . . . . . . . . . . . . . . 9 72 3.1. Time . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 73 3.2. Culture . . . . . . . . . . . . . . . . . . . . . . . . . 10 74 3.3. Money . . . . . . . . . . . . . . . . . . . . . . . . . . 12 75 3.4. Awareness . . . . . . . . . . . . . . . . . . . . . . . . 12 76 3.5. Other . . . . . . . . . . . . . . . . . . . . . . . . . . 13 77 4. Possible solutions . . . . . . . . . . . . . . . . . . . . . . 13 78 4.1. Communication . . . . . . . . . . . . . . . . . . . . . . 14 79 4.1.1. Mailing List Digests . . . . . . . . . . . . . . . . . 14 80 4.1.2. Alternative Communication Mediums . . . . . . . . . . 15 81 4.2. Outreach . . . . . . . . . . . . . . . . . . . . . . . . . 16 82 4.3. Inclusion . . . . . . . . . . . . . . . . . . . . . . . . 19 83 5. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 22 84 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22 85 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 23 86 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 23 87 8.1. Normative References . . . . . . . . . . . . . . . . . . . 23 88 8.2. Informative References . . . . . . . . . . . . . . . . . . 23 89 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 23 91 1. Introduction 93 The Internet Engineering Task Force (IETF) is an open standards 94 organization concerned primarily with developing and promoting open 95 Internet standards, with the goal of making the Internet better. 96 Their goal, mission statement, and cardinal principles are documented 97 in [RFC3935], section 1. 99 In a perfect world, the IETF would create standards for protocols 100 that meet all relevant network operator requirements, sync with 101 operational realities, and are relatively easy to deploy and 102 troubleshoot. In this perfect world, deployment and 103 operationalization concerns are consistently addressed and the level 104 of operator engagement always makes sense. Operators always know 105 when their input is needed and always provide that needed input. In 106 reality, though, many operators are not engaged enough in the IETF to 107 create that perfect world. It's widely understood that a significant 108 portion of operators (particularly small- to mid-size) don't join 109 IETF mailing lists or attend IETF meetings, effectively writing 110 themselves out of the process. This leaves vendors, academics, and 111 some large organizations to rule many decision-making processes 112 within the IETF. The operators expected to deploy these technologies 113 often don't even know that the standards are being developed. In 114 other words, critical new technologies are currently being developed 115 without sufficient direct operator input. 117 This disparity is not new, nor has it gone unnoticed. Nine years ago 118 this month an essay by Randy Bush was published in ACM SIGCOMM 119 Computer Communication Review. It's titled "Into the Future with the 120 Internet Vendor Task Force: A Very Curmudgeonly View - or - Testing 121 Spaghetti - A Wall's Point of View" and it calls out this very issue 122 of "the devaluation of operational realities." 124 However, with the advent of OpenFlow, Software Defined Networks 125 (SDN), Network Function Virtualization (NFV), and an overall trend 126 toward open source, particularly open application programming 127 interfaces (APIs), in the network space, this disparity may now be 128 seen as related to a larger and growing problem. If open APIs become 129 the de-facto definition of interoperability requirements, the role of 130 the standardization bodies, and the opportunity for operators to 131 influence specifications, diminishes. As a result the functional 132 interoperability (and interchangeability) of vendors and devices will 133 decrease, potentially leading to a more proprietary and less open and 134 global nature of the Internet. 136 In response, the Internet Society has launched a new project to 137 address the perceived gap between Operators and the IETF. The 138 objective of this project is ultimately to facilitate communications 139 between the operator community and the IETF to help ensure that 140 operational realities inform the development of key standards. We 141 want to foster a larger and more engaged operator community around 142 the IETF and protocol development work. To ensure that we take the 143 most effective action, we focused initially on talking to operators 144 around the world, gathering information and defining the problem 145 statement(s). The first phase of this project was a survey of the 146 operator community that was conducted over the first half of 2014. 147 The survey closed on 1 July with over 350 responses. 149 This I-D begins the next phase, which we hope will lead to productive 150 improvements to the level of operational input into the IETF 151 processes. The primary purpose of this paper is to synthesize the 152 survey results, along with information we collected directly from 153 operators during the survey window. 155 In the next section we take a quick look at the survey respondents, 156 including their roles and their relationships to the IETF. Then, 157 under the following section, Potential Challenges, we delve into the 158 reasons respondents gave for not participating in the IETF. What are 159 their personal challenges to injecting more operational reality? We 160 then move on to discussing ideas for overcoming these obstacles in 161 the next section, Possible Solutions. In all cases, we are primarily 162 reporting on the results of the Operators and the IETF survey, open 163 from January through June 2014 and the text may not necessarily 164 reflect the views of the Internet Society. 166 2. Survey respondents 168 Before diving into what the survey respondents said, and what that 169 might mean, let's first take a look at who these respondents were. 171 2.1. Job type 173 The first set of questions dealt with the respondents' role. We 174 wanted to ensure that we reached our target audience - technical 175 network operators. A note on our use of the term "operator:" In the 176 survey, in this paper, and throughout this Operators and the IETF 177 project, we use the term operator to mean anyone who operates an IP 178 network. This includes Internet service providers (ISPs) but also 179 content providers, data centers, enterprises, wireless networks, 180 campus networks, and everything in between. 182 o I'm an Operator - 44% strongly agree and 34% agree, 12% disagree 183 and 10% strongly disagree. 185 o My role is primarily technical - 63% strongly agree and 29% agree, 186 9% disagree and 2% strongly disagree. 188 The respondents were overwhelmingly technical and the vast majority 189 were operators. We also drilled into specific roles of respondents: 191 o I'm an Engineer - 60% strongly agree and 32% agree, 5% disagree 192 and 3% strongly disagree. 194 o I'm an Architect - 42% strongly agree and 38% agree, 14% disagree 195 and 6% strongly disagree. 197 o I'm an Developer - 9% strongly agree and 29% agree, 39% disagree 198 and 23% strongly disagree. 200 o I'm an Manager - 24% strongly agree and 26% agree, 27% disagree 201 and 23% strongly disagree. 203 92% of respondents self-identified as engineers and 80% as 204 architects, while only 38% said they were developers and about half 205 said they were managers. 207 2.2. IETF Involvement 209 The next set of questions dove into the respondents' current level of 210 participation in, and awareness of, the IETF. 212 Exactly half of the respondents reported that they did NOT currently 213 participate in the IETF at all. Almost one third said they 214 participate in the IETF via mailing lists only. Only about 18% 215 reported that they were active in the IETF via both mailing lists and 216 in-person meetings. This is about the mix we were expecting. 218 Since we are looking primarily for challenges and obstacles to 219 participation, we wanted to hear from the people who do not 220 participate. Mixing in some people with more experience on how the 221 IETF works today helps provide useful context, though. We then asked 222 each group of respondents more detailed questions about their level 223 of awareness, based on their participation level in the IETF. 225 2.2.1. Do not currently participate in the IETF 227 Among those who do not currently participate in the IETF at all, a 228 wide majority know that the IETF exists, know what it does, find IETF 229 documents relevant to their jobs, and feel that they need to 230 participate. 232 So why aren't they showing up? Other responses within this set of 233 questions provide clues: Over half of this group reported that they 234 do not know how to participate, and almost half said that they do not 235 feel welcome. 237 Detailed results: 239 o I never heard of IETF: 82% strongly disagree, 14% disagree, 1% 240 agree, 3% strongly agree In short - 4% report not having heard of 241 the IETF before the survey 243 o I don't know what IETF does: 57% strongly disagree, 35% disagree, 244 8% agree, 0% strongly agree In short - 8% don't participate 245 because they don't know what the IETF does 247 o I don't know how to participate: 21% strongly disagree, 21% 248 disagree, 44% agree, 14% strongly agree In short - 58% of those 249 who do not participate in the IETF do not know how 251 o I don't believe IETF documents are relevant to my job: 53% 252 strongly disagree, 33% disagree, 11% agree, 3% strongly agree In 253 short - 86% believe that IETF documents are relevant to their work 255 o I don't feel my operator input is welcomed: 14% strongly disagree, 256 42% disagree, 33% agree, 11% strongly agree In short - 44% do not 257 participate because they feel unwelcome 259 o I rely on my vendors to represent me: 27% strongly disagree, 37% 260 disagree, 30% agree, 6% strongly agree In short - 36% rely on 261 their vendors to represent them at the IETF 263 o I don't need to participate, I just need the output: 24% strongly 264 disagree, 49% disagree, 23% agree, 4% strongly agree In short - 265 27% choose not to participate because they are only concerned with 266 the output of the IETF (RFCs) 268 2.2.2. Do not currently participate on IETF mailing lists 270 Among respondents who do not currently participate in IETF mailing 271 lists, over two thirds believe that it does, in fact, fall within 272 their job to do so. While most respondents had at least heard of 273 IETF mailing lists, about half reported not knowing what happens on 274 those lists and 40% said they don't know how to join. Also, about a 275 third of respondents do not participate on IETF mailing lists because 276 "list noise" (off-topic and unhelpful content) is too high. 278 Almost three quarters report staying off the lists because they don't 279 think they have enough time. Almost half of those who are not on an 280 IETF mailing list thought they had to show up to meetings to 281 participate and were unaware that most IETF work actually takes place 282 on the mailing lists. 284 Detailed results: 286 o I've never heard of IETF mailing lists: 44% strongly disagree, 25% 287 disagree, 25% agree, 6% strongly In short - 31% had never heard of 288 IETF mailing lists before this survey 290 o I don't know what happens on IETF mailing lists: 23% strongly 291 disagree, 23% disagree, 44% agree, 10% strongly agree, In short - 292 54% don't know what happens on an IETF mailing list 294 o I don't know how to join an IETF mailing list: 35% strongly 295 disagree, 25% disagree, 34% agree, 6% strongly agree In short - 296 40% aren't on an IETF mailing list because they don't know how to 297 join 299 o I'm not interested: 29% strongly disagree, 55% disagree, 14% 300 agree, 2% strongly agree In short - 16% of respondents don't 301 participate due to lack of interest 303 o I find the content too technical or abstract: 27% strongly 304 disagree, 47% disagree, 25% agree, 1% strongly agree In short - 305 26% find IETF mailing list content too technical or too abstract 307 o I don't have enough time: 8% strongly disagree, 20% disagree, 41% 308 agree, 31% strongly agree In short - 72% say they don't 309 participate because they don't have time 311 o I don't find the content relevant: 25% strongly disagree, 58% 312 disagree, 16% agree, 1% strongly agree In short - 83% find IETF 313 mailing list content relevant 315 o It's not my job: 22% strongly disagree, 48% disagree, 25% agree, 316 5% strongly agree In short - 70% think that following IETF mailing 317 lists falls within their job duties, even though they don't 318 currently do it 320 o There's too much noise on the lists (off-topic discussions, 321 etc...): 15% strongly disagree, 51% disagree, 27% agree, 7% 322 strongly agree In short - 34% replied that "list noise" is an 323 issue for them 325 Before taking this survey: 327 o 54% I was aware that most of the work in the IETF happens on 328 mailing lists between meetings 330 o 46% I thought I had to show up at IETF meetings to participate 332 2.2.3. Do not currently participate in IETF meetings 334 While most respondents had at least heard of IETF meetings, nearly 335 half of those who do not currently attend IETF meetings reported not 336 knowing what happens at a meeting and slightly more said they don't 337 know how to participate. Two thirds of respondents told us they 338 don't attend IETF meetings because they don't have the time and over 339 three quarters because they don't have the travel budget to attend a 340 meeting. Just less than one third feel it's not their job to 341 participate at IETF meetings. Almost exactly half of the respondents 342 who do not attend IETF meetings were unaware that remote 343 participation is available. 345 Detailed results: 347 o I've never heard of IETF meetings: 60% strongly disagree, 25% 348 disagree, 10% agree, 5% strongly agree In short - 15% don't come 349 to IETF meetings because they hadn't heard of them before 351 o I don't know what happens at IETF meetings: 31% strongly disagree, 352 24% disagree, 35% agree, 10% strongly agree In short - 45% don't 353 show up because they don't understand what goes on at an IETF 354 meeting 356 o I don't know how to participate in an IETF meeting: 30% strongly 357 disagree, 21% disagree, 35% agree, 14% strongly agree In short - 358 49% don't participate in meetings because they don't know how to 360 o I'm not interested: 39% strongly disagree, 48% disagree, 10% 361 agree, 3% strongly agree In short - 13% avoid IETF meetings due to 362 a lack of interest 364 o I find the content too technical or abstract: 33% strongly 365 disagree, 48% disagree, 17% agree, 2% strongly agree In short - 366 19% don't participate in IETF meetings because the content is too 367 technical or too abstract 369 o I don't have enough time: 15% strongly disagree, 21% disagree, 36% 370 agree, 28% strongly agree In short - 64% don't come because they 371 don't have enough time to participate 373 o I don't have the travel budget: 7% strongly disagree, 11% 374 disagree, 37% agree, 45% strongly agree In short - 82% don't 375 attend IETF meetings because they lack the travel budget 377 o I don't find the content relevant: 30% strongly disagree, 56% 378 disagree, 10% agree, 4% strongly agree In short - 14% don't come 379 to meetings because they content is not relevant to them 381 o It's not my job: 26% strongly disagree, 44% disagree, 23% agree, 382 7% strongly agree In short - 30% don't attend IETF meetings 383 because it doesn't fit their job duties 385 Before taking this survey: 387 o 50% I was aware that most of the IETF meeting sessions are 388 available to remote participants 390 o 50% I thought I had to show up at IETF meetings to participate 392 3. Potential Challenges 394 In addition to the multiple choice options on the Operators and the 395 IETF survey, we included several opportunities for respondents to 396 enter freeform text. We asked questions such as "Tell us about why 397 you do not currently participate in the IETF in your own words" and 398 "Why do you think other operators do not participate in the IETF?" 399 When these responses are evaluated in combination with the numbers 400 above, some themes emerge. 402 There appear to be four major perceived obstacles to IETF 403 participation: 405 o Time 407 o Culture 409 o Money 411 o Awareness 413 These one-word captions are, of course, simplifications. The 414 following sections dig into each of these themes to explore the 415 potential and perceived challenges a bit more. 417 3.1. Time 419 One of the top complaints from both survey respondents and operators 420 we have spoken with in person is how much time is required to 421 participate meaningfully in the IETF. As Mr. Bush pointed out in his 422 2005 paper: 424 "The IETF has grown so large and so enamored of complexity and 425 featuritis that it is a full-time job to participate." 427 We can see this perception confirmed in the numbers above: 429 o 72% of respondents who do not participate in IETF mailing lists 430 say they don't participate because they don't have enough time 432 o 64% of respondents who don't attend IETF meetings report that they 433 don't come because they don't have enough time to participate 435 Additionally, the most common response to both "Tell us about why you 436 do not currently participate in the IETF in your own words" and "Tell 437 us about why you are not currently a member of any IETF mailing lists 438 in your own words" were some variation of "not enough time." This 439 was the second most common response to the "Tell us about why you do 440 not currently attend IETF meetings in your own words" question as 441 well. While many of those responses were very terse, some took the 442 time to explain their challenges a bit more: 444 "Time restriction is an issue. Keeping up with my "day job" 445 responsibilities is challenging. There's difficulty in sorting out 446 where the different BoFs and working groups are in the process - very 447 hard to step into the middle of an ongoing conversation, translate it 448 to my world, and engage in the discussion. Makes it hard to do more 449 than lurk." 451 When we dig into the details of some of these comments, it appears 452 that time constraints may be tied in some ways to what we're calling 453 cultural challenges here. 455 "I don't have the time to sift through the entrenched autistic and 456 esoteric arguments. There are very obviously people who are paid to 457 participate in the IETF by vendors (and other orgs) for whom it's 458 their full time job, or one of the primary purposes of their job, and 459 they don't have other significant responsibilities. It therefore 460 makes debating with these people very difficult if your involvement 461 in IETF is a secondary (or tertiary) function of your role." 463 3.2. Culture 465 Another common challenge we heard about while conducting this survey 466 is one of culture. While the IETF is open to participation by 467 anyone, some feel that they are not welcome or that they will be 468 ignored or treated badly by other participants. 470 We saw above that almost half (44%) of the respondents who do not 471 currently participate in the IETF at all avoid it because they don't 472 feel their operator input is welcomed. 474 This is echoed in some detail in many of the comments left by 475 respondents: 477 o IETF are just concern about the old members and don't think of how 478 to get new members onboard 480 o "I do not feel that the IETF is responsive to the needs and 481 requirements of those delivering services. The responses to the 482 IPv6 DHCP enterprise requirements are an example of the 483 disconnection in the IETF. Many times I have read or participated 484 in discussions on different mailing lists about many of the topics 485 and the final item pushed out by people in the IETF has been 486 "you're stupid and an idiot and we're going to do it my way". I 487 can get that at home with my teenager." 489 o "Conversations are heavily dominated by academics with little or 490 no practical experience (but deep theoretical knowledge and 491 skills), and vendor professionals who are so senior and 492 experienced. Both folks cast long shadows that are intimidating 493 to others who can't devote the time to keeping up with what are 494 often detailed and nuanced discussions." 496 o "Despite wanting claims that operators were welcome, as I switched 497 from protocol engineer to operator, I saw growing irrelevance. 498 The IETF is maintaining an "ivory tower" vision of how the 499 Internet is used, whereas the world economy has a different view 500 of how to make use of the medium. The IETF hasn't been welcome to 501 new sets of requirements. In DNS, the IETF has been effectively 502 replaced by DNS-OARC." 504 o "[I don't participate in the IETF] Because its become a political 505 fight between vendors. Vendors push their individual agendas 506 without caring about user opinions. A contentious issue will 507 bring out half the opposition companies employees to bash and kill 508 it regardless of whether there is a true customer that may benefit 509 from it." 511 o "I perceive it to be full of pompous, self-serving, out-of-touch 512 with reality, technology actors." 514 o "The IETF is not really focused towards operations and, 515 historically, operator input has not been well received." 517 Another aspect of culture is being more open to participation from 518 around the world: 520 "Most studies have been conducted in English, which makes it 521 difficult for those who have not mastered the language." 523 3.3. Money 525 The most common free-form response to "Tell us about why you do not 526 currently attend IETF meetings in your own words" as well as the 527 fourth most common response to "Tell us about why you do not 528 currently participate in the IETF in your own words" was money, and 529 general support from the respondents' organization. Some of the 530 nuances here are pointed out in the responses: 532 o "It is too expensive to attend regularly. It is not my primary 533 job to attend IETF meetings, so is secondary to other things." 535 o "I don't have enough budget to attend the conference. Based up in 536 India, my travel budget + accommodation + Food + Visa will come 537 around 2000 USD (for Conferences in US) at the minimum, this is my 538 2 months salary." 540 o "I'm a self-employed contractor. I can't afford to pay for it 541 myself, and my clients wouldn't pay to send me there because it's 542 not what gets their business needs met. And every hour I spend at 543 conferences and the like is an hour I don't get paid." 545 Additionally, a full 82% of respondents who don't attend IETF 546 meetings reported that it was because they lack the needed travel 547 budget. 549 3.4. Awareness 551 Throughout the survey, respondents told us that their ignorance of 552 the IETF, what it does, how it operates, and how individuals can get 553 involved, is a barrier to their participation. Overall, 58% of those 554 who do not participate in the IETF at all reported that they do not 555 know how to. 557 Among respondents who don't follow any IETF mailing lists, almost a 558 third had never heard of the mailing lists, over half said they don't 559 know what happens on IETF mailing lists, and 40% reported not knowing 560 how to join a list. 562 Likewise, among those who do not attend IETF meetings, 45% told us 563 they don't show up because they don't understand what goes on at an 564 IETF meeting and nearly half (49%) said they don't participate in 565 meetings because they don't know how to. 567 As with the other themes, this was echoed in the comments: 569 o "No awareness of how I can help, what I can do, and where my goals 570 would align with the IETF." 572 o "I do not know how can I participate in IETF. I would love to 573 know how can I participate. not just by subscribing to mailing 574 list but by doing some work in my part time." 576 o "I have no idea how to even begin participating" 578 3.5. Other 580 There are also other reasons that came up in the freeform answers 581 that we feel are very important but that don't fit into one of the 582 themes above. They include: 584 o Too technical: "Too broad", "Discussions are on an abstract, 585 technical level above my expertise" 587 o Not operational enough: "Not enough operational lists", 588 "Operations guys stay home doing operations" 590 o Ignorance: "I never felt the need, it never occurred to me to try" 592 o Management support: "Lack of Management Support" 594 o Out of scope: "Out of scope of my job", "I really don't care", 595 "Not relevant to my job" 597 o Format: "The meetings are all about status of a particular draft 598 which really isn't that interesting." 600 o Reliance on vendors: "Operators mainly rely on system integrators 601 and rarely believe that their voices are heard" 603 o Not relevant to operators: "Not relevant to the short/mid-term 604 needs of most operators", "The lead time from idea to RFC to 605 vendor support to using in a design is years for me. I will tend 606 to use a technology once it reaches maturity." 608 4. Possible solutions 610 The ultimate purpose of collecting this information and identifying 611 the perceived challenges to operator participation in the IETF is, of 612 course, to help us find ways to bring more operational input into the 613 IETF. In other words, we want to determine how we may be able to 614 solve these potential challenges. 616 The possible solutions listed here are based on the survey results 617 and on numerous conversations with operators around the world. This 618 is not expected to be an exhaustive list but rather a starting point 619 for further exploration. Note that this paper is simply documenting 620 potential solutions and is not, at this time, making any 621 recommendations. The next step of this process is to widen the 622 discussion and explore all of our options for making the IETF even 623 better than it is today. 625 The remainder of this section is dedicated to individual ideas; some 626 are suggestions for change at the IETF, others point to activities 627 that operators or operator groups could do to help, and some are 628 clues to what the Internet Society may be able to do. These ideas 629 for possible solutions are grouped into three larger buckets or 630 themes. The themes that the solutions fall into are: 632 o Communication 634 o Outreach 636 o Inclusion 638 At this time, this is a very raw collection of direct quotes from the 639 Operators and the IETF survey, and others we spoke with anonymously. 640 In later versions of this Internet-Draft we intend to update this 641 section based on conversations both inside and outside of the IETF. 643 4.1. Communication 645 The first theme that we saw emerge among possible solutions is one of 646 communication. Most of these ideas focus on alternative methods of 647 communication between the IETF and its constituents and specifically 648 on new ways to provide condensed information to IETF participants and 649 potential participants. 651 4.1.1. Mailing List Digests 653 o "Quarterly summaries for those that are not able to attend." 655 o "Provide a curation service that takes key developments in a 656 working group and shares them from time to time - save operators 657 from having to make sense out of nuanced arguments so that they 658 can jump into conversations with reasonable confidence they know 659 what's happened so far and therefore won't embarrass themselves." 661 o "There's probably no silver bullet, but one thing that I would 662 find most useful would be a single daily/weekly/monthly digest 663 mailing list. Just headlines and updates from each of the working 664 groups. (Along with links to where to find more information for 665 each.)" 667 o "Make it dead simple for folks to see the specific topics being 668 discussed and worked on. If I had some idea what the topics were, 669 I would be more likely to participate if there was a topic that I 670 had some expertise in and more importantly an opinion about how to 671 address the issue." 673 o "a blog with some updates of things would be nice. reading a huge 674 amount of emails is not that fast and with a blog post you can 675 join the discussion when there is something important ongoing" 677 o "At least provide weekly summaries what's currently in discussion 678 and which new drafts or RFCs were published." 680 o "Invest in reducing perceived entropy and lower the time 681 commitment to do so - both requires energy inputs. Action: 682 Introduce and invest support staff that write accessible summaries 683 (like the former Cisco IPJ) - licensed under CC so that they can 684 be freely translated to other languages without breaking the bank: 685 Note - I'm associated with IPJ and am biased." 687 o "Highlight specifically which groups' efforts are looking for 688 operator input. Or color-code agendas by "how close" different 689 efforts are to needing operator input. Have those folks write an 690 operator's abstract. Package the background homework to make it 691 easy for us to catch up and easy to see if the effort is relevant 692 to us. Give ways for us to input to the process that is separated 693 from the "players" usual modes (eg mailing list)." 695 4.1.2. Alternative Communication Mediums 697 o "Offer communications options other than e-mail." 699 o "Surveys like this are a good start. Ask about the vendors we 700 have relationships with, what technologies we currently use, what 701 we're deploying now, and what we'd like to deploy in future." 703 o "Audio-only podcasts are a really great medium for busy people, 704 IMO. They convey the personality of the people who are presenting 705 them whilst still allowing us to do things like drive to work, 706 cook, vacuum, or jog." 708 o "RSS feeds that help busy people keep track of the really 709 important happenings would be good (maybe they exist already)." 711 o "Could RFCs be made more friendly in the following fronts: * 712 Readability: have an "human" English version and/or summary. * 713 Viewability: it seems the format followed is from the 80s. Make 714 changes to the font, format, etc. to make reading them more 715 appealing." 717 o "Make it easier and less time consuming, like having a simple 718 system for feedback on drafts and decisions." 720 o "Determine the questions to ask of Operators, and then start 721 distributing those questions/forms via social media and reddit." 723 o "Transition from ASCII Text RFCs to documents that support 724 figures. There was a time when text-only made sense, but that was 725 long ago. Figures made out of ASCII characters are difficult to 726 read and are not able to convey as much information." 728 o "Create polls for various important matters where operators vote. 729 Give the chance to operators to propose their ideas in simple 730 texts and then have an IETF expert help them translate this simple 731 text into an IETF doc. Ask the operators for various issues 732 regarding the current RFCs and get their proposals about them." 734 o "We need tools which makes IETF-related work more effective. For 735 example, my main problem is I can not see any way of easily track/ 736 find all discussions related to a particular drafts. Let's say I 737 see that a very interesting draft has been published. Most likely 738 there will be a lot of different email threads going on so it is 739 really hard to track all discussions/comments." 741 4.2. Outreach 743 The next theme we heard is one of outreach to the operators, 744 primarily through existing network operator groups and forums but 745 also through more traditional marketing and publicity techniques: 747 o "More liaisons between the IETF and Operator forums" 749 o "Possibly smaller events like ARIN road show events for the 750 general IT community" 752 o "Participation in I.E.T.F needs to be demystified. Internet 753 Society needs to reach out to the operators and the local 754 technical community in every country to create awareness that 755 I.E.T.F is open for participation, it does have a membership 756 system, and that anyone who participates can equally contribute to 757 discussions on the same level as more qualified or frequent 758 participants. And that funding opportunities are open. And that 759 it is important for operators to take part." 761 o "I'd recommend signing up to popular mailing lists like NANOG or 762 CISCO and JUNIPER NSP and promote the ongoing IETF topics/agenda, 763 current meetings to encourage operators to take part in what they 764 find interesting" 766 o "The IETF could do a better job of making themselves known to 767 newbie networkers. Ask anyone who's been in the field for less 768 than two years and you're unlikely to get anything more detailed 769 than "Oh, uh, I think they write RFCs."" 771 o "Give more information about IETF no local engineers in local 772 languages with simple example of advantages of participation." 774 o "Post in relevant worldwide networking mailing lists when you have 775 information that wouldn't be spam like. For example, when you 776 post meetings, are also at an event related to the mailing list, 777 etc etc." 779 o "co-located sessions in Network Operators meetings" 781 o "Road shows at other well attended operator events (ie: NANOG, 782 MAAWG, etc)." 784 o "Promote IETF events and involvement through regional tech events 785 & meetups (in the Seattle area: NorthWest Tech Alliance / 786 SeattleTechForum) and industry related trade-shows and events 787 (NANOG / ARIN / PTC / SuperComputing / etc.). As well, providing 788 a brief summary of how to support / become involved with the IETF 789 which is promoted within the IETF pages and/or search results." 791 o "Try outreach programs to EDU operators. EDUs are the testbeds of 792 the past, present, and future. Engage us!" 794 o "1. IETF members presence on different conferences. 2. IETF must 795 publish examples of stories or good practices in e-zines or 796 participate at national events. 3. IETF must invest in promotion 797 and presence in various technical media, university curriculums, 798 national events." 800 o "Collocating (interim) IETF Meetings with RIPE/NANOG/etc meeting - 801 I attended an interim IETF meeting after a RIPE meeting - at least 802 for the ops groups." 804 o "Promote the IETF impact and role of standards to large operators 805 (education)." 807 o "Also setting up a IETF operators conference that is design to 808 bring the long term to the short term relevance and present it 809 ways that is significant to operators and not just RFCs that 810 vendors and operators have to figure how to make into products. 811 This should include the vendors that are creating products based 812 on new standards to present what they are doing with it. Would 813 provide real world ties to the work IETF is doing rather than RFCs 814 that get lost in code and are generally ignored by future 815 companies. You would be surprised how many new product vendors do 816 not have a clue about some of the older RFCs that are still HUGELY 817 significant when developing a device. Things like new vendor mini 818 conference that goes over operationally significant RFCs that they 819 should be building into their devices." 821 o "As for the Internet Society, probably modifying the mentorship 822 programs to be announced more on local mailing lists and also 823 require winners to spend some time on mailing lists before 824 attending events." 826 o "We are here in ISOC India Chennai Setting up a Remote Engagement 827 Hub (India) we will be requesting all Stake holders which includes 828 ISP/Telcos." (Also see LAC-IETF) 830 o "initially be possible to create regional forums that are 831 preparatory style operators to approach, understand the benefits 832 and challenges for both regional and continental as 833 implementations of the ietf can create a kind of good practice for 834 operators as Lationamerica less scale and the Caribbean." 836 o "Provide briefings to operator community on technologies that may 837 be relevant, and how to get up-to-speed on them. Actively seek 838 operator feedback on those technologies (this has been tried in 839 the past, but on a very one-off ad-hoc basis)." 841 o "Increase interaction and outreach between IETF and operator 842 forums, probably by identifying a subset of IETF drafts and areas 843 that could most benefit from additional operator input such that 844 we can focus the help that we're asking for - simply trying to 845 convince people to participate generically isn't likely to be 846 successful, while asking for specific feedback on specific items 847 will be seen as a better use of time. It may even be useful to 848 try to coordinate one meeting per year or every two years with an 849 operator forum to encourage cross-pollination." 851 o "It's a tough question... You need a "hot RFC" and turn it into a 852 media-backed frenzy. Something focus interest of a large number 853 of technical folks. You may also want to just elevate a few 854 select 'products'. Keep a few key items "up front". For 855 instance, take a look at Mozilla and Mozilla Labs. Even Google 856 and (now defunct) Google Labs. Push a few key "products" (of the 857 IETF's 7136 RFC's) and put them everywhere, showcase a few more. 858 Focus and push the technologies forward and you may get more 859 participation." 861 o "ensure that meaningful RFC's and other publications get more 862 press than TCP over Avian Carrier." 864 o "Strategic Plan of publicity about IETF and its main activities. 865 This strategic plan should be in several languages to reach 866 everyone." 868 o "I would love to see a list of reasons why operator participation 869 is needed and what the pay-off is for the operator, as well as the 870 community as a whole." 872 4.3. Inclusion 874 The final theme we found amongst the offered possible solutions is 875 one of inclusion. How can the IETF be more welcoming, in order to 876 bring participants in and keep them engaged? Survey respondents had 877 several ideas: 879 o "Welcoming our participation would be helpful." 881 o "make the operators feel more welcome" 883 o "Education." 885 o "Travel subsidy?" 887 o "Make remote participation easier." 889 o "Asking vendors to bring operators to the meetings. Planning a 890 few IETF meetings right before or after a big operator meeting 891 (e.g. RIPE, NANOG)" 893 o "Encourage non-technical participation, cultural/educational 894 program, beginner training." 896 o "Introduce works in multi language." 897 o "Well you see... [respondent wrote in Chinese characters here, 898 which we can not include in Internet-Draft formatting]" 900 o "Probably topical meetings (only for some area of IETF work) might 901 lessen the burden on the main meetings." 903 o "Provide some training opportunity during meetings to help justify 904 participation." 906 o "Provide scholarship and/or sponsorship to students, small 907 operators." 909 o "Provide more sponsorships" 911 o "Facilitate joining committees." 913 o "better discovery of projects. this may seem strange but perhaps a 914 match making site to better express interests and goals if 915 individuals and projects." (constituencies) 917 o "Smaller focused sessions" 919 o "It's hard for people in an operations-led post to make a 920 justification for a portion of their time and budget to be 921 invested in participating in the IETF. There's also the challenge 922 that as an operations person does manage to spend some more time 923 involved in the IETF and the standards process they end up doing 924 less operations and more standardisation work, and therefore their 925 input becomes less operationally relevant. There needs to be a 926 greater acceptance among the IETF attendees of the fact that 927 operationally focused people will dip in and out of the IETF as 928 their work requires." 930 o "Add more operational content." 932 o "Require standards to get the buy-in of a variety of operators." 934 o "if operator input was required in a "peer-review" fashion -- and 935 operators were represented from very large to very small" 937 o "Create a Service Provider input channel that is taken seriously. 938 The SPAC (Service Provider Action Committee) is an example that 939 exists within the Broadband Forum." 941 o "Having dedicated listeners might help. As in: someone who 942 actually listens to what operators say, tries to understand 943 whether "reality" looks different than the perfect theoretical 944 network design, and ensures that this is not drowned in other 945 discussions." 947 o "New ways of gathering people reducing the cost (remote 948 participations from multiple locations?)." 950 o "48 hour days :-) Back-to-back WG meetings with other relevant 951 conferences (ICANN or RIPE for DNS related topics would be the 952 obvious choices) to reduce travel time/budget." 954 o "Publish agendas early, lower the price of meetings and hotel 955 accommodations, have more operator relevant side meetings, gather 956 relevant working group meetings on the same day. Some interesting 957 side meetings would be, Internet Exchange meetings like Euro-IX, 958 joint NOG meetings, Peering forums, capacity update meetings, 959 etc." 961 o "Perhaps consider consolidating time by interest areas so that the 962 travel time demands were not as great." 964 o "I guess, having a BCOP (best current operational practices; like 965 http://bcop.nanog.org/ and http://www.ipbcop.org/) would attract 966 more operators." "Acknowledge operators. Provide them ways to 967 make a difference. For example, define a class of documents that 968 require the participation of at least two operators. That can be 969 against the usual convention of "individual" participation, but 970 anyway we know that it no longer holds..." 972 o "Suggest that the IETF working groups, especially the ones dealing 973 with topics that operators would have a significant interest in, 974 start to accept that operator requests may be valid even if they 975 are not in agreement with existing opinions." 977 o "I would restructure IETF to be more agile and remove the 978 political hierarchy of IETF that prevents wider participation. 979 The use of operators as working group Operator Councils rather 980 than just having Co-Chairs to determine what topics are good and 981 not good for that working group. ... The #1 thing is to remove 982 the politics of IETF so people with ideas and good suggestions are 983 not stifled by the IETF machine and the fulltime IETF 984 politicians." 986 o "While I know it can't be (and shouldn't be done), reduce the 987 voice of the people who seem to have nothing else to do than reply 988 to emails whole day. IETF should be about different views not 989 destroying everyone who don't agree with you." 991 o "Do some IETF meetings in our region, especially where there is 992 dense penetration of internet users as well as a strong technical 993 community (such as Southern and Eastern Africa)." 995 o "Try and group more operationally-relevant sessions together so 996 that it doesn't require a full week to participate." 998 o "It needs more open leadership. The top of the IETF is like merry 999 go round. The same folks make sure their colleagues all get jobs, 1000 same names, same people, no change" 1002 o "Operators don't care how the things are fixed, we do care if the 1003 requirements are addressed. Create a WG for operators to 1004 establish business needs, and customer needs - let them create 1005 "requirement's documents" in the form of conceptual abstraction 1006 meta models that can be put out in the body. Treat this as an 1007 Open Framework a bit more, and lower the tribal culture a bit 1008 less." 1010 o "One day ticket is good idea. And place is important for us." 1012 o "Better stewardship/shepherding of drafts and stopping the brain 1013 damaged drafts from wasting WG time. Not everything requires IETF 1014 work, nor needs to be written in a standard." 1016 o "Internet society should do more educations in operators 1017 management level. I notice that my company seems fonder on ATIS 1018 and Cablelabs. I guess because the white papers published that 1019 usually not require most technical people to understand. Thus, 1020 management level can know what actually go on in industrial. On 1021 the other hand, RFC is very technical. Management doesn't know 1022 how that applies to them. So, some user-friendly introduction of 1023 WG and how they can help operators may be good to present to 1024 managements." 1026 5. Conclusions 1028 This section will be completed after WG discussion. 1030 6. IANA Considerations 1032 This document makes no request of IANA. 1034 Note to RFC Editor: this section may be removed on publication as an 1035 RFC. 1037 7. Acknowledgments 1039 Because the survey and many of our conversations were conducted 1040 anonymously, we have left this section blank at this time. We have 1041 however received lots of help from many members of the IETF and 1042 operator communities. If you feel that you made a significant 1043 contribution and would like your name to appear here, please let us 1044 know and send us cookies :) 1046 8. References 1048 8.1. Normative References 1050 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1051 Requirement Levels", BCP 14, RFC 2119, March 1997. 1053 8.2. Informative References 1055 [RFC3935] Alvestrand, H., "A Mission Statement for the IETF", 1056 BCP 95, RFC 3935, October 2004. 1058 Authors' Addresses 1060 Chris Grundemann 1061 Internet Society 1062 150 West 9th Ave. 1063 Denver, Colorado 80204 1064 US 1066 Phone: +1 303 351 1539 1067 Email: grundemann@isoc.org 1069 Jan Zorz 1070 Internet Society 1071 Frankovo naselje 165 1072 Skofja Loka 4220 1073 Slovenia 1075 Phone: +38659042000 1076 Email: zorz@isoc.org