idnits 2.17.1 draft-iab-itat-report-02.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 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 (April 17, 2014) is 3655 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Obsolete informational reference (is this intentional?): RFC 4960 (Obsoleted by RFC 9260) -- Obsolete informational reference (is this intentional?): RFC 6555 (Obsoleted by RFC 8305) Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group E. Lear, Ed. 3 Internet-Draft April 17, 2014 4 Intended status: Informational 5 Expires: October 19, 2014 7 Report from the IAB workshop on Internet Technology Adoption and 8 Transition (ITAT) 9 draft-iab-itat-report-02 11 Abstract 13 This document provides an overview of a workshop held by the Internet 14 Architecture Board (IAB) on Internet Technology Adoption and 15 Transition (ITAT). The workshop was hosted by the University of 16 Cambridge in Cambridge on December 4th and 5th of 2013. The goal of 17 the workshop was to facilitate adoption of Internet protocols, 18 through examination of a variety of economic models, with particular 19 emphasis at the waist of the hourglass. This report summarizes 20 contributions and discussions. As the topics were wide ranging, 21 there is no single set of recommendations for IETF participants to 22 pursue at this time. Instead, in the classic sense of early 23 research, the workshop noted areas that deserve further exploration. 25 Note that this document is a report on the proceedings of the 26 workshop. The views and positions documented in this report are 27 those of the workshop participants and do not necessarily reflect IAB 28 views and positions. 30 Status of This Memo 32 This Internet-Draft is submitted in full conformance with the 33 provisions of BCP 78 and BCP 79. 35 Internet-Drafts are working documents of the Internet Engineering 36 Task Force (IETF). Note that other groups may also distribute 37 working documents as Internet-Drafts. The list of current Internet- 38 Drafts is at http://datatracker.ietf.org/drafts/current/. 40 Internet-Drafts are draft documents valid for a maximum of six months 41 and may be updated, replaced, or obsoleted by other documents at any 42 time. It is inappropriate to use Internet-Drafts as reference 43 material or to cite them other than as "work in progress." 45 This Internet-Draft will expire on October 19, 2014. 47 Copyright Notice 48 Copyright (c) 2014 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents 53 (http://trustee.ietf.org/license-info) in effect on the date of 54 publication of this document. Please review these documents 55 carefully, as they describe your rights and restrictions with respect 56 to this document. Code Components extracted from this document must 57 include Simplified BSD License text as described in Section 4.e of 58 the Trust Legal Provisions and are provided without warranty as 59 described in the Simplified BSD License. 61 Table of Contents 63 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 64 1.1. Organization of This Report . . . . . . . . . . . . . . . 4 65 2. Motivations and Review of Existing Work . . . . . . . . . . . 4 66 3. Economics of Protocol Adoption . . . . . . . . . . . . . . . 5 67 3.1. When can bundling help adoption of network 68 technologies or services? . . . . . . . . . . . . . . . . 5 69 3.2. Internet Protocol Adoption: Learning from Bitcoin . . . . 6 70 3.3. Long term strategy for a successful deployment of 71 DNSSEC - on all levels . . . . . . . . . . . . . . . . . 7 72 3.4. Framework for analyzing feasibility of Internet 73 protocols . . . . . . . . . . . . . . . . . . . . . . . . 7 74 3.5. Best Effort Service as a Deployment Success Factor . . . 8 75 4. Innovative / Out There Models . . . . . . . . . . . . . . . . 8 76 4.1. On the Complexity of Designed Systems (and its effect 77 on protocol deployment) . . . . . . . . . . . . . . . . . 8 78 4.2. Managing Diversity to Manage Technological 79 Transition . . . . . . . . . . . . . . . . . . . . . . . 9 80 4.3. On Economic Models of Network Technology Adoption, 81 Design, and Viability . . . . . . . . . . . . . . . . . . 9 82 5. Making Standards Better . . . . . . . . . . . . . . . . . . . 9 83 5.1. Standards: A love/hate relationship with patents . . . . 10 84 5.2. Bridge Networking Research and Internet 85 Standardization: Case Study on Mobile Traffic 86 Offloading and IPv6 Transition Technologies . . . . . . . 10 87 5.3. An Internet Architecture for the Challenged . . . . . . . 10 88 6. Other Challenges and Approaches . . . . . . . . . . . . . . . 11 89 6.1. Resilience of the commons: routing security . . . . . . . 11 90 6.2. Getting to the next version of TLS . . . . . . . . . . . 11 91 7. Outcomes . . . . . . . . . . . . . . . . . . . . . . . . . . 12 92 7.1. Work for the IAB and the IETF . . . . . . . . . . . . . . 12 93 7.2. Potential for the Internet Research Task Force . . . . . 12 94 7.3. Opportunities for others . . . . . . . . . . . . . . . . 12 95 8. Security Considerations . . . . . . . . . . . . . . . . . . . 13 96 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 13 97 10. Attendees . . . . . . . . . . . . . . . . . . . . . . . . . . 13 98 11. Informative References . . . . . . . . . . . . . . . . . . . 14 99 Appendix A. Changes . . . . . . . . . . . . . . . . . . . . . . 15 100 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 15 102 1. Introduction 104 The Internet is a complex ecosystem that encompasses all aspects of 105 society. At its heart is a protocol stack with an hourglass shape, 106 and IP at its center. Recent research points to possible 107 explanations for the success of such a design and for the significant 108 challenges that arise when trying to evolve or change its middle 109 section, e.g., as partially evident in the difficulties encountered 110 by IPv6. The workshop had a number of other key examples to 111 consider, including the next generation of HTTP and real time web- 112 browser communications (WebRTC). The eventual success of many if not 113 all of these protocols will largely depend on our understanding of 114 not only what features and design principles contribute lasting 115 value, but also on how deployment strategies can succeed in unlocking 116 that value to foster protocol adoption. The latter is particularly 117 important in that most if not all Internet protocols exhibit strong 118 externalities that create strong barriers to adoption, especially in 119 the presence of a well-established incumbent. That is, factors 120 beyond the control of the end points (such as middleboxes) can limit 121 deployment, sometimes by design. 123 The Internet Architecture Board (IAB) holds occasional workshops 124 designed to consider long-term issues and strategies for the 125 Internet, and to suggest future directions for the Internet 126 architecture. This long-term planning function of the IAB is 127 complementary to the ongoing engineering efforts performed by working 128 groups of the Internet Engineering Task Force (IETF), under the 129 leadership of the Internet Engineering Steering Group (IESG) and area 130 directorates. 132 Taking into account [RFC5218] on what makes a protocol successful, 133 this workshop sought to explore how the complex interactions of 134 protocols' design and deployment affect their success. One of the 135 workshop's goals was, therefore, to encourage discussions to develop 136 an understanding of what makes protocol designs successful not only 137 in meeting initial design goals but more importantly in their ability 138 to evolve as these goals and the available technology change. 139 Another equally important goal was to develop protocol deployment 140 strategies that ensure that new features can rapidly gain enough of a 141 foothold to ultimately realize broad adoption. Such strategies must 142 be informed by both operational considerations and economic factors. 144 Participants in this workshop consisted of operators, researchers 145 from the fields of computer science and economics, as well as 146 engineers. Contributions were wide ranging. As such, this report 147 makes few recommendations for the IETF to consider. 149 1.1. Organization of This Report 151 This report records the participants' discussions. At the end of the 152 workshop reviewed potential follow-up items. These will be 153 highlighted at each point during the report, and a summary is given 154 at the end. 156 Section 2 discusses the economics of protocol adoption. Section 3 157 delves into an examination of recent operational challenges and some 158 success stories. Section 4 examines different views of success 159 factors. Finally section 5 summarizes views of the participants, and 160 identifies a few key insights. 162 2. Motivations and Review of Existing Work 164 Our workshop began with an introduction that asks the question: is 165 the neck of the Internet hourglass closed for business? There are 166 numerous instances where progress has been slow, the three biggest 167 that come to mind being IPv6 [RFC2480], SCTP [RFC4960], and DNSSEC 168 [RFC4034]. The impact of DNSSEC is of particular interest, because 169 it is relied upon for the delivery of other services, such as DANE 170 [RFC6698] and it could be used for application discovery services 171 through DNS (specifically where security properties are part of that 172 discovery). Thus slowdown at the neck of the glass can have an 173 impact closer to the lip. 175 Even when one considers the classic neck of the hourglass to be IP 176 and transport layers, it was suggested that the hourglass might 177 extend as high as the application layer. 179 ______________________ 180 \ / 181 \ Applications / 182 \ / 183 \ / 184 \ / 185 \__________/ 186 | HTTP(s)| 187 |________| 188 / \ 189 / TCP/IP \ 190 /______________\ 191 / MPLS/ \ 192 / Framing \ 193 /____________________\ 194 / Physical \ 195 /________________________\ 197 HTTP(s) as the new neck? 199 This idea was rebutted by the argument that protocols do continue to 200 evolve, that protocols like SMTP and IMAP in the applications space 201 have continued to evolve, as has the transport layer. 203 The workshop moved on to a review of RFC 5218 which discusses 204 protocol success factors. This work was presented in the IETF 70 205 plenary, and was the basis for this ongoing work. There were two 206 clear outcomes from the discussion. The first was that the Internet 207 Architecture Board should review and consider that document in the 208 context of evaluating birds of a feather (BoF) session proposals at 209 the IETF, so that any working group proposal is carefully crafted to 210 address a specific design space and provide positive net value. 211 Another aspect was to continue work on tracking the value-specific 212 works in terms of success, wild success, or failure. On that last 213 point, failure remains difficult to judge, particularly at the neck 214 of the hourglass. 216 3. Economics of Protocol Adoption 218 Several papers were presented that looked at economic aspects of 219 protocol adoption. 221 3.1. When can bundling help adoption of network technologies or 222 services? 224 Economics of bundling is a long studied field, but not as applied to 225 protocols. It is relevant to the IETF and inherent to two key 226 notions: layering and "mandatory to implement". Two current examples 227 include DANE atop DNSSEC and WebRTC atop SCTP. The workshop reviewed 228 a model [Weber13] that examines the concept that bundling of 229 technologies can lead to several possible outcomes, which includes 230 more or less adoption of both. This will depend on a number of 231 factors, including the costs, benefits, and externalities associated 232 with adopting each. (Simply put, an externality is an effect or use 233 decision by one set of parties that has either a positive or negative 234 impact on others who did not have a choice or whose interests were 235 not taken into account). Bundling of capabilities may provide 236 positive value when individual capabilities on their own do not on 237 their own provide sufficient critical mass to propel further 238 adoption. The workshop considered involved two independent 239 technologies, and presents and analyze four quandrants of 240 possibilities in terms of whether the bundling of two technologies 241 would propel, retard, or not change the adoption rate of both. One 242 question was what happens where one technology depends on the other. 243 That is directly tied to "mandatory to implement" discussions within 244 the IETF. That is a matter for follow-on work. IETF participants 245 can provide researchers anecdotal experience to help improve models 246 in this area. 248 3.2. Internet Protocol Adoption: Learning from Bitcoin 250 The workshop considered an examination of protocol success factors in 251 the context of Bitcoin[Bohme13]. Here, there were any number of 252 barriers to success, including adverse press, legal uncertainties, 253 glitches and breaches, previous failed attempts, and speculative 254 attacks, amongst others. Bitcoin has thus far overcome these 255 barriers thanks to several key factors: 257 o First, there is a built-in reward system for early adopters. 258 Participants are monetarily rewarded at an exponentially declining 259 rate. 261 o There exist exchanges or conversion mechanisms to directly convert 262 bitcoin to other currencies. 264 o Finally, there is some store of value in the currency itself, e.g, 265 people find intrinsic value in it. 267 The first two of these factors may be transferrable to other 268 approaches. One key protocol success factor is direct benefit to the 269 participant. Another key protocol success factor is ability to 270 interface with other systems for mutual benefit. In the context of 271 Bitcoin there has to be a way to exchange the coins for other 272 currencies. The Internet Email system had simpler adaption 273 mechanisms to allow interchange with non-Internet email systems, 274 facilitating its success. Another more simply stated approach is "IP 275 over everything". 277 A key message from this presentation is that if a protocol imposes 278 externalities or costs on other systems, find a means to establish 279 incentives for those other players for implementation. As it happens 280 there is a limited example of how to do this that is directly 281 relevant to the IETF. 283 3.3. Long term strategy for a successful deployment of DNSSEC - on all 284 levels 286 The workshop reviewed the approach Sweden's .SE registry has taken to 287 improving deployment of DNSSEC[Lowinder13]. .SE has roughly 1.5 288 million domains. IIS manages the ccTLD. They made the decision to 289 encourage deployment of DNSSEC within .SE. They began by 290 understanding who their stakeholders were, and examined financial, 291 legal, and technical aspects to deployment. As they began their 292 rollout, they charged extra for DNSSEC. As they put it, this didn't 293 work very well. 295 They went on to fund development of OpenDNSSEC to remove technical 296 barriers to deployment at end sites, noting that tooling was lacking 297 in this area. Even with this development, more tooling is necessary, 298 as they point out a need for APIs between the signing zone and the 299 registrar. 301 To further encourage deployment, the government of Sweden provided 302 financial incentives to communities to see that their domains were 303 signed. .SE further provided an incentive to registrars to see that 304 their domains were signed. In summary, .SE examined all the players 305 and provided incentives for each to participate. 307 The workshop discussed whether or not this model could be applied to 308 other domains. .SE was in a position to effectively subsidize DNS 309 deployment because of their ability to set prices. This may be 310 appropriate for certain other top level domains, but it was pointed 311 out that the margins of other domains do not allow for a cost 312 reduction to be passed on at this point in time. 314 3.4. Framework for analyzing feasibility of Internet protocols 316 One of the goals of the workshop was to provide ways to determine 317 when work in the IETF was likely to lead to adoption. The workshop 318 considered an interactive approach that combines value net analysis, 319 deployment environment analysis, and technical architecture analysis 320 that leads to feasibility and solution analysis[Leva13]. This work 321 provided an alternative to RFC 5218 that had many points in common. 322 The case study examined was that of MPTCP. Various deployment 323 challenges were observed. First and foremost, increasing bandwidth 324 within the network seems to decrease attractiveness of MPTCP. 325 Second, the benefit/cost tradeoff by vendors was not considered 326 attractive. Third, not all parties may agree on the benefits. 328 Solutions analysis suggested several approaches to improve 329 deployment, including open source, lobbying of various implementers, 330 proxy deployment, and implementation by parties where they own both 331 ends of a connection. 333 3.5. Best Effort Service as a Deployment Success Factor 335 When given the choice between vanilla and chocolate, why not choose 336 both? The workshop considered an approach that became a recurring 337 theme throughout the workshop, which was to examine when it was 338 necessary to make a choice between technologies, but rather to 339 implement multiple mechanisms to achieve adoption[Welzl13]. The 340 workshop discussed the case of Skype, where it will use the best 341 available transport mechanism to improve communication between 342 clients, rather than to tie fate to any specific transport. The 343 argument goes that such an approach provides a means to introduce new 344 transports such as SCTP. This would be an adaptation of "Happy 345 Eyeballs" [RFC6555]. 347 4. Innovative / Out There Models 349 There were several approaches presented that examined how we look at 350 protocol adoption. 352 4.1. On the Complexity of Designed Systems (and its effect on protocol 353 deployment) 355 The workshop reviewed a comparison between the hourglass model and 356 what systems biologists might call the bowtie model[Meyer13]. The 357 crux of this comparison is that both rely on certain building blocks 358 to accomplish a certain end. In the case of our hourglass model, IP 359 sits notably in the center, whereas in the case of systems biology, 360 adenosine triphosphate (ATP) is the means by which all organisms 361 convert nutrients to usable energy, and thus resides centrally within 362 the biological system. 364 The workshop also examined the notion of "robust yet fragile", which 365 examines the balance between the cost of implementing robust systems 366 versus their value. That is, highly efficient systems can prove 367 fragile in the face of failure, or may prove hard to evolve. 369 The key question asked during this presentation was how we could 370 apply what has been learned in systems biology or what do the 371 findings reduce to for engineers? The answer was that more work is 372 needed. The discussion highlighted the complexity of the Internet in 373 terms of predicting network behavior. As such, one promising area to 374 examine may be that of network management. 376 4.2. Managing Diversity to Manage Technological Transition 378 The workshop considered the difference between planned versus 379 unplanned technology transitions[Kohno13]. They examined several 380 transitions at the link, IP, and application layers in Japan. One 381 key claim in the study is that there is a phase difference in the 382 diversity trend between each layer. The statistics presented show 383 that indeed HTTP is the predominant substrate for other applications. 384 Another point made was that "natural selection" is a strong means to 385 determine technology. 387 Along these lines there were two papers submitted that examined the 388 formation and changes to the hourglass in the context of evolutionary 389 economics. Unfortunately the presenter was unable to attend due to 390 illness. The work was discussed at the workshop, and there were 391 different points of view as to the approach. 393 4.3. On Economic Models of Network Technology Adoption, Design, and 394 Viability 396 The workshop considered how network protocol capabilities enable 397 certain sorts of services that are beneficial to consumers and 398 service providers. This model looks at smart data pricing (SDP) in 399 which some behavior is desired and rewarded through a pricing 400 model.[Sen13] The example given was use of time-dependent pricing 401 (TDP) and demonstrated how a service provider was able to load shift 402 traffic to off-peak periods. Explict Congestion Notification (ECN) 403 and RADIUS were used by the project alongside a simple GUI. This 404 sort of work may prove useful to service providers as caching models 405 evolve over time. The question within the room was how will protocol 406 developers consider these sorts of requirements. 408 5. Making Standards Better 410 There were several papers that focused on how standards are produced. 412 5.1. Standards: A love/hate relationship with patents 414 One of the biggest barriers to deployment is that of the unseen 415 patent by the non-practicing entity (NPE).[Lear13] While this problem 416 is relatively well understood by the industry, the discussion looked 417 at patents as a means to improve interoperability. Those who hold 418 patents have the ability to license them in such a way that a single 419 approach towards standardization is the result (e.g, they get to 420 decide the venue for their work). 422 5.2. Bridge Networking Research and Internet Standardization: Case 423 Study on Mobile Traffic Offloading and IPv6 Transition 424 Technologies 426 There was a presentation and discussion about the gap between the 427 research community and standards organizations. Two cases were 428 examined: mobile offloading and IPv6 transition technologies.[Ding13] 429 In the case of mobile offloading, a mechanism was examined that 430 required understanding of both 3GPP and IETF standards. Resistance 431 in both organizations was encountered. In the 3GPP, the problem was 432 that the organization already had an offloading model in play. In 433 the IETF, the problem was a lack of understanding of the 434 interdisciplinary space. The researchers noted that in the case of 435 the IETF, they may have taken the wrong tack by having jumped into 436 the solution without having fully explained the problem they were 437 trying to solve. In the case of IPv6 transition technologies 438 researchers encountered a crowded field and not much appetite for new 439 transition technologies. 441 The workshop discussed whether the standards arena is the best venue 442 or measurement of success for researchers. The IRTF is meant to 443 bridge academic research and the IETF. As we will discuss below, 444 several avenues for continued dialog are contemplated. 446 5.3. An Internet Architecture for the Challenged 448 The workshop engaged in a very provocative discussion about whether 449 the existing Internet architecture serves the broadest set of needs. 450 Three specific aspects were examined: geographic, technical, and 451 socio-economic. Researchers presented an alternative hourglass or 452 protocol architecture known as Lowest Common Denominator Networking 453 (LCDNet) that re-examines some of the base assumptions of the 454 existing architecture, including its "always on" 455 nature.[Sathiaseelan13] 456 The workshop questioned many of the baseline assumptions of the 457 researchers. In part this may have been due to constrained 458 discussion time on the topic, where a fuller explanation was 459 warranted. 461 6. Other Challenges and Approaches 463 The workshop held a number of other discussions about different 464 approaches to technology adoption. We should highlight that a number 465 of papers were submitted to the workshop on routing security, two of 466 which were not possible to present. 468 6.1. Resilience of the commons: routing security 470 The workshop discussed a presentation on the tragedy of the commons 471 in the context of global inter-domain routing[Robachevsky13]. The 472 "Internet Commons" is a collection of networks that we depend on but 473 do not control. The main threat to the commons in the context of BGP 474 is routing pollution, or unwanted or unnecessary routing entries. 475 The Internet Society has been working with service providers to 476 improve resiliency by driving a common understanding of both problem 477 and solution space, and developing a shared view with regard to risk 478 and benefits, with the idea being that there would be those who would 479 engage in reciprocal cooperation with the hopes that others would do 480 similarly in order to break the tragedy. 482 What was notable in discussion was that there was no magic bullet to 483 addressing the resiliency issue, and that this was a matter of 484 clearly identifying the key players and convincing them that their 485 incentives were aligned. It also involved developing approaches to 486 measure resiliency. 488 6.2. Getting to the next version of TLS 490 Originally the workshop had planned to look at the question of 491 whether we could mandate stronger security. This evolved into a 492 discussion about getting to the next version of Transport Layer 493 Security (TLS), and what challenges lie ahead. It was pointed out 494 that there were still many old versions of TLS in existence today, 495 due to many old implementations. In particular, it was pointed out 496 that a substantial amount of traffic is still encrypted using triple 497 DES. 499 One concern about the next generation is that perfect could become 500 the enemy of good. Another point that was made was that perhaps a 501 testing platform might help interoperability. Finally, there was 502 some discussion about how new versions of TLS get promoted. 504 7. Outcomes 506 This wide ranging workshop discussed many aspects that go to the 507 success or failure of the work of the IETF. While there is no single 508 silver bullet that we can point to for making a protocol successful, 509 the workshop did discuss a number of outcomes and potential next 510 steps. 512 7.1. Work for the IAB and the IETF 514 The IAB's role in working group formation consists of providing 515 guidance to the IESG on which birds of a feather sessions should be 516 held, review of proposed working group charters, and shepherding some 517 work so that it can reach a suitable stage for standardization. In 518 each of these stages the IAB has an opportunity to apply the lessons 519 of RFC 5218, as well as other work such as the notion of bundling 520 choices, when members give advice. 522 In addition to working group creation, the IAB has an opportunity to 523 track and present protocol success stories, either through wikis or 524 through discussion at plenary sessions. For instance, there is much 525 interest at the moment of this report in Bitcoin, its success, and 526 what parallels and lessons can be drawn. Specifically it would be 527 useful to track examples of first mover advantages. 529 Finally, one area that the IETF may wish to consider, relating 530 specifically to DNSSEC, as raised by our speakers was standardization 531 of the provisioning interface of DNSSEC (DS keys) between parent and 532 child zone. Contributions in this area would be welcome. 534 7.2. Potential for the Internet Research Task Force 536 There are at least two possible activities that the IRTF might wish 537 to consider. The first would be a research group that considers 538 protocol alternatives and recommendations that might be useful in 539 areas where environments are constrained, due to bandwidth or other 540 resources. Such a group has already been proposed, in fact. 542 The second possibility is a more general group that focuses on 543 economic considerations relating to Internet protocol design. In 544 particular there were a number of areas that were presented to the 545 working group that deserve further investigation, and could use 546 collaboration between researchers, engineers, and operators. Two 547 examples include work on bundling as well as systems biology. 549 7.3. Opportunities for others 550 Incentive models often involve many different players. As we 551 considered work in the workshop, our partners such as ICANN and the 552 RIRs can continue to play a role in encouraging deployment of 553 protocols through their policies. Their members can also participate 554 in any activity of the IRTF that is related to this work. 556 Specifically, RIRs have a specific role to play in encouraging 557 security of the routing system, and ICANN has a specific role to play 558 in securing the domain name service. 560 The suggestion was made that the IETF working groups could leverage 561 graduate students in many universities around the world in helping 562 review documents (drafts, RFCs etc.). This would serve as a source 563 of education in real world processes to students, and would engage 564 the research community in IETF processes more thoroughly, as well as 565 providing a scale-out resource for handling the IETF review workload. 566 Several attendees who have such students were prepared to try this 567 out. 569 8. Security Considerations 571 This document does not discuss a protocol. Security for the workshop 572 itself was excellent. 574 9. Acknowledgments 576 The IAB would like to thank the program committee, who consisted of 577 Roch Guerin, Constantine Dovrolis, Hannes Tschofenig, Joel Halpern, 578 Eliot Lear, and Richard Clayton, as well as Bernard Aboba and Dave 579 Thaler. Their earlier work provided a strong basis for this 580 workshop. 582 A special debt of gratitude is owed to our hosts, Ross Anderson and 583 Richard Clayton for arranging an excellent venue for our discussions. 585 10. Attendees 587 The following people attended the ITAT workshop: 589 Aaron Yi Ding, Adrian Farrel, Andrei Robachevzsky, Andrew Sullivan 590 Arjuna Sathiaseelan, Bjoern Zeeb, Dave Meyer, Dave Thaler, Dongting 591 Yu, Eliot Lear, Elwyn Davies, Erik Nordmark, Hannes Tschofenig, Joel 592 Halpern, Jon Crowcroft, Lars Eggert, Martin Stiemerling, Michael 593 Welzl, Michiel Leenaars, Miyo Kohno, Rainer Bohme, Richard Clayton, 594 Roch Guerin, Ross Anderson, Russ Housley, Sam Smith, Sean Turner, 595 Soumya Sen, Spencer Dawkins, Steven Weber, Tapio Levae, Toby 596 Moncaster, Tony Finch 598 11. Informative References 600 [Bohme13] Bohme, R., "Internet Protocol Adoption: Learning from 601 Bitcoin", December 2013. 603 [Ding13] Yi Ding, A., Korhonen, J., Savolainen, T., Kojo, M., 604 Tarkoma, S., and J. Crowcroft, "Bridge Networking Research 605 and Internet Standardization: Case Study on Mobile Traffic 606 Offloading and IPv6 Transition Technologies", December 607 2013. 609 [Kohno13] Kohno, M., Asaba, T., and F. Baker, "Managing Diversity to 610 Manage Technological Transition", December 2013. 612 [Lear13] Lear, E. and D. Mohlenhoff, "Standards: a love/hate 613 relationship with patents", December 2013. 615 [Leva13] Leva, T. and H. Soumi, "Framework for analyzing 616 feasibility of Internet protocols", December 2013. 618 [Lowinder13] 619 Eklund Lowinder, A.M. and P. Wallstrom, "Long term 620 strategy for a successful deployment of DNSSEC - on all 621 levels", December 2013. 623 [Meyer13] Meyer, D. M., "On the Complexity of Engineered Systems 624 (and its effect on protocol deployment)", December 2013. 626 [RFC2480] Freed, N., "Gateways and MIME Security Multiparts", RFC 627 2480, January 1999. 629 [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. 630 Rose, "Resource Records for the DNS Security Extensions", 631 RFC 4034, March 2005. 633 [RFC4960] Stewart, R., "Stream Control Transmission Protocol", RFC 634 4960, September 2007. 636 [RFC5218] Thaler, D. and B. Aboba, "What Makes For a Successful 637 Protocol?", RFC 5218, July 2008. 639 [RFC6555] Wing, D. and A. Yourtchenko, "Happy Eyeballs: Success with 640 Dual-Stack Hosts", RFC 6555, April 2012. 642 [RFC6698] Hoffman, P. and J. Schlyter, "The DNS-Based Authentication 643 of Named Entities (DANE) Transport Layer Security (TLS) 644 Protocol: TLSA", RFC 6698, August 2012. 646 [Robachevsky13] 647 Robachevsky, A., "Resilience of the commons: routing 648 security", December 2013. 650 [Sathiaseelan13] 651 Sathiaseelan, A., Trossen, D., Komnios, I., Ott, J., and 652 J. Crowcroft, "An Internet Architecture for the 653 Challenged", December 2013. 655 [Sen13] Sen, S., "On Economic Models of Network Technology 656 Adoption, Design, and Viability", December 2013. 658 [Weber13] Weber, S., Guerin, R., and J. C. Oliveira, "When can 659 bundling help adoption of network technologies or 660 services?", December 2013. 662 [Welzl13] Welzl, M., "The "best effort" service as a deployment 663 success factor", December 2013. 665 Appendix A. Changes 667 This section to be removed prior to publication. 669 o 00 Initial Revision. 671 Author's Address 673 Eliot Lear (editor) 674 Richtistrasse 7 675 Wallisellen, ZH CH-8304 676 Switzerland 678 Phone: +41 44 878 9200 679 Email: lear@cisco.com