idnits 2.17.1 draft-iab-itat-report-01.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 (March 27, 2014) is 3676 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 March 27, 2014 4 Intended status: Informational 5 Expires: September 28, 2014 7 Report from the IAB workshop on Internet Technology Adoption and 8 Transition (ITAT) 9 draft-iab-itat-report-01 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, we note 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 September 28, 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 . . . . 9 84 5.2. Bridge Networking Research and Internet 85 Standardization: Case Study on Mobile Traffic 86 Offloading and IPv6 Transition Technologies . . . . . . . 9 87 5.3. An Internet Architecture for the Challenged . . . . . . . 10 88 6. Other Challenges and Approaches . . . . . . . . . . . . . . . 10 89 6.1. Resilience of the commons: routing security . . . . . . . 10 90 6.2. Getting to the next version of TLS . . . . . . . . . . . 11 91 7. Outcomes . . . . . . . . . . . . . . . . . . . . . . . . . . 11 92 7.1. Work for the IAB and the IETF . . . . . . . . . . . . . . 11 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 . . . . . . . . . . . . . . . . . . . 13 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. We have a number of other key examples to consider, 111 including the next generation of HTTP and WebRTC. The eventual 112 success of many if not all of these protocols will largely depend on 113 our understanding of not only what features and design principles 114 contribute lasting value, but also on how deployment strategies can 115 succeed in unlocking that value to foster protocol adoption. The 116 latter is particularly important in that most if not all Internet 117 protocols exhibit strong externalities that create strong barriers to 118 adoption, especially in the presence of a well-established incumbent. 119 That is, factors beyond the control of the end points (such as 120 middleboxes) can limit deployment, sometimes by design. 122 The Internet Architecture Board (IAB) holds occasional workshops 123 designed to consider long-term issues and strategies for the 124 Internet, and to suggest future directions for the Internet 125 architecture. This long-term planning function of the IAB is 126 complementary to the ongoing engineering efforts performed by working 127 groups of the Internet Engineering Task Force (IETF), under the 128 leadership of the Internet Engineering Steering Group (IESG) and area 129 directorates. 131 Taking into account [RFC5218] on what makes a protocol successful, 132 this workshop sought to explore how the complex interactions of 133 protocols' design and deployment affect their success. One of the 134 workshop's goals was, therefore, to encourage discussions to develop 135 an understanding of what makes protocol designs successful not only 136 in meeting initial design goals but more importantly in their ability 137 to evolve as these goals and the available technology change. 138 Another equally important goal was to develop protocol deployment 139 strategies that ensure that new features can rapidly gain enough of a 140 foothold to ultimately realize broad adoption. Such strategies must 141 be informed by both operational considerations and economic factors. 143 Participants in this workshop consisted of operators, researchers 144 from the fields of computer science and economics, as well as 145 engineers. Contributions were wide ranging. As such, this report 146 makes few recommendations for the IETF to consider, although there 147 are some. 149 1.1. Organization of This Report 151 This report records the participants' discussions. At the end of the 152 workshop we 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? We have 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 application discovery services through DNS 171 (specifically where security properties are part of that discovery). 172 Thus slowdown at the neck of the glass can have an impact closer to 173 the lip. 175 Even when we consider the classic neck of the hourglass to be IP and 176 transport layers, it was suggested that the hourglass might extend as 177 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 We moved on to a review of RFC 5218 which discusses protocol success 204 factors. This work was presented in an IETF 70 plenary, and was the 205 basis for this ongoing work. There were two clear outcomes from the 206 discussion. The first was that the Internet Architecture Boards 207 should review and consider that document in the context of evaluating 208 birds of a feather (BoF) session proposals at the IETF, so that any 209 working group proposal is carefully crafted to address a specific 210 design space and provide positive net value. Another aspect was to 211 continue work on tracking the value specific works in terms of 212 success, wild success, or failure. On that last point, failure 213 remains difficult to judge, particularly at the neck of the 214 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. Bundling of capabilities may provide positive 233 value when individual capabilities on their own do not on their own 234 provide sufficient critical mass to propel further adoption. The 235 work we considered involved two independent technologies. One 236 question was what happens where one technology depends on the other. 237 That is directly tied to "mandatory to implement" discussions within 238 the IETF. That is a matter for follow-on work. IETF participants 239 can provide researchers anecdotal experience to help improve models 240 in this area. 242 3.2. Internet Protocol Adoption: Learning from Bitcoin 244 We considered an examination of protocol success factors in the 245 context of Bitcoin[Bohme13]. Here, there were any number of barriers 246 to success, including adverse press, legal uncertainties, glitches 247 and breaches, previous failed attempts, and speculative attacks, 248 amongst others. Bitcoin has thus far overcome these barriers thanks 249 to several key factors: 251 o First, there is a built-in reward system for early adopters. 252 Participants are monetarily rewarded at an exponentially declining 253 rate. 255 o There exist exchanges or conversion mechanisms to directly convert 256 bitcoin to other currencies. 258 o Finally, there is some store of value in the currency itself. 260 The first two of these factors may be transferrable to other 261 approaches. That is- one key protocol success factor is direct 262 benefit to the participant. Another key protocol success factor is 263 ability to interface with other systems for mutual benefit. In the 264 context of Bitcoin there has to be a way to exchange the coins for 265 other currencies. The Internet Email system had simpler adaption 266 mechanisms to allow interchange with non-Internet email systems, 267 facilitating its success. Another more simply stated approach is "IP 268 over everything". 270 A key message from this presentation is that if a protocol imposes 271 externalities or costs on other systems, find a means to establish 272 incentives for those other players for implementation. As it 273 happened we had a limited example of how to do this that is directly 274 relevant to the IETF. 276 3.3. Long term strategy for a successful deployment of DNSSEC - on all 277 levels 279 We reviewed the approach Sweden's .SE registry has taken to improving 280 deployment of DNSSEC[Lowinder13]. .SE has roughly 1.5 million 281 domains. IIS manages the ccTLD. They made the decision to encourage 282 deployment of DNSSEC within .SE. They began by understanding who 283 their stakeholders were, and examined financial, legal, and technical 284 aspects to deployment. As they began their rollout, they charged 285 extra for DNSSEC. As they put it, this didn't work very well. 287 They went on to fund development of OpenDNSSEC to remove technical 288 barriers to deployment at end sites, noting that tooling was lacking 289 in this area. Even with this development, more tooling is necessary, 290 as they point out a need for APIs between the signing zone and the 291 registrar. 293 To further encourage deployment, the government of Sweden provided 294 financial incentives to communities to see that their domains were 295 signed. .SE further provided an incentive to registrars to see that 296 their domains were signed. In summary, .SE examined all the players 297 and provided incentives for each to participate. 299 The workshop discussed whether or not this model could be applied to 300 other domains. .SE was in a position to effectively subsidize DNS 301 deployment because of their ability to set prices. This may be 302 appropriate for certain other top level domains, but it was pointed 303 out that the margins of other domains do not allow for a cost 304 reduction to be passed on at this point in time. 306 3.4. Framework for analyzing feasibility of Internet protocols 308 One of the goals of the workshop was to provide ways to determine 309 when work in the IETF was likely to lead to adoption. We considered 310 an interactive approach that combines value net analysis, deployment 311 environment analysis, and technical architecture analysis that leads 312 to feasibility and solution analysis[Leva13]. This work provided an 313 alternative to RFC 5218 that had many points in common. The case 314 study examined was that of MPTCP. Various deployment challenges were 315 observed. First and foremost, increasing bandwidth within the 316 network seems to decrease attractiveness of MPTCP. Second, the 317 benefit/cost tradeoff by vendors was not considered attractive. 318 Third, not all parties may agree on the benefits. 320 Solutions analysis suggested five separate approaches to improve 321 deployment, including open source, lobbying of various implementers, 322 proxy deployment, and implementation by parties where they own both 323 ends of a connection. 325 3.5. Best Effort Service as a Deployment Success Factor 327 When given the choice between vanilla and chocolate, why not choose 328 both? We considered an approach that became a recurring theme 329 throughout the workshop, which was to examine when it was necessary 330 to make a choice between technologies, but rather to implement 331 multiple mechanisms to achieve adoption[Welzl13]. The workshop 332 discussed the case of Skype, where it will use the best available 333 transport mechanism to improve communication between clients, rather 334 than to tie fate to any specific transport. The argument goes that 335 such an approach provides a means to introduce new transports such as 336 SCTP. This would be an adaptation of "Happy Eyeballs" [RFC6555]. 338 4. Innovative / Out There Models 340 There were several approaches presented that examined how we look at 341 protocol adoption. 343 4.1. On the Complexity of Designed Systems (and its effect on protocol 344 deployment) 346 We reviewed a comparison between the hourglass model and what systems 347 biologists might call the bowtie model[Meyer13]. The crux of this 348 comparison is that both rely on certain building blocks to accomplish 349 a certain end. In the case of our hourglass model, IP sits notably 350 in the center, whereas in the case of systems biology, adenosine 351 triphosphate (ATP) is the means by which all organisms convert 352 nutrients to usable energy, and thus resides centrally within the 353 biological system. 355 We also examined the notion of "robust yet fragile", which examines 356 the balance between the cost of implementing robust systems versus 357 their value. That is, highly efficient systems can prove fragile in 358 the face of failure, or may prove hard to evolve. 360 The key question asked during this presentation was how we could 361 apply what has been learned in systems biology or what do the 362 findings reduce to for engineers? The answer was that more work is 363 needed. The discussion highlighted the complexity of the Internet in 364 terms of predicting network behavior. As such, one promising area to 365 examine may be that of network management. 367 4.2. Managing Diversity to Manage Technological Transition 369 We considered the difference between planned versus unplanned 370 technology transitions[Kohno13]. They examined several transitions 371 at the link, IP, and application layers in Japan. One key claim in 372 the study is that there is a phase difference in the diversity trend 373 between each layer. The statistics presented show that indeed HTTP 374 is the predominant substrate for other applications. Another point 375 made was that "natural selection" is a strong means to determine 376 technology. 378 Along these lines there were two papers submitted that examined the 379 formation and changes to the hourglass in the context of evolutionary 380 economics. Unfortunately the presenter was unable to attend due to 381 illness. The work was discussed at the workshop, and there were 382 different points of view as to the approach. 384 4.3. On Economic Models of Network Technology Adoption, Design, and 385 Viability 387 We considered how network protocol capabilities enable certain sorts 388 of services that are beneficial to consumers and service providers. 389 This model looks at smart data pricing (SDP) in which some behavior 390 is desired and rewarded through a pricing model.[Sen13] The example 391 given was use of time-dependent pricing (TDP) and demonstrated how a 392 service provider was able to load shift traffic to off-peak periods. 393 Explict Congestion Notification (ECN) and RADIUS were used by the 394 project alongside a simple GUI. This sort of work may prove useful 395 to service providers as caching models evolve over time. The 396 question within the room was how will protocol developers consider 397 these sorts of requirements. 399 5. Making Standards Better 401 There were several papers that focused on how standards are produced. 403 5.1. Standards: A love/hate relationship with patents 405 One of the biggest barriers to deployment is that of the unseen 406 patent by the non-practicing entity (NPE).[Lear13] While this problem 407 is relatively well understood by the industry, the discussion looked 408 at patents as a means to improve interoperability. Those who hold 409 patents have the ability to license them in such a way that a single 410 approach is the result. 412 5.2. Bridge Networking Research and Internet Standardization: Case 413 Study on Mobile Traffic Offloading and IPv6 Transition 414 Technologies 416 Not for the first time, there was a presentation and discussion about 417 the gap between the research community and standards organizations. 418 Two cases were examined: mobile offloading and IPv6 transition 419 technologies.[Ding13] In the case of mobile offloading, a mechanism 420 was examined that required understanding of both 3GPP and IETF 421 standards. Resistance in both organizations was encountered. In the 422 3GPP, the problem was that the organization already had an offloading 423 model in play. In the IETF, the problem was a lack of understanding 424 of the interdisciplinary space. The researchers noted that in the 425 case of the IETF, they may have taken the wrong tact by having jumped 426 into the solution without having fully explained the problem they 427 were trying to solve. In the case of IPv6 transition technologies 428 researchers encountered a crowded field and not much appetite for new 429 transition technologies. 431 The workshop discussed whether the standards arena is the best venue 432 or measurement of success for researchers. The IRTF is meant to 433 bridge academic research and the IETF. As we will discuss below, 434 several avenues for continued dialog are contemplated. 436 5.3. An Internet Architecture for the Challenged 438 We held a very provocative discussion about whether the existing 439 Internet architecture serves the broadest set of needs. Three 440 specific aspects were examined: geographic, technical, and socio- 441 economic. Researchers presented an alternative hourglass or protocol 442 architecture known as Lowest Common Denominator Networking (LCDNet) 443 that re-examines some of the base assumptions of the existing 444 architecture, including its "always on" nature.[Sathiaseelan13] 446 The workshop questioned many of the baseline assumptions of the 447 researchers. In part this may have been due to constrained 448 discussion time on the topic, where a fuller explanation was 449 warranted. 451 6. Other Challenges and Approaches 453 We held a number of other discussions about different approaches to 454 technology adoption. We should highlight that a number of papers 455 were submitted to the workshop on routing security, two of which were 456 not possible to present. 458 6.1. Resilience of the commons: routing security 460 We discussed a presentation on the tragedy of the commons in the 461 context of global inter-domain routing[Robachevsky13]. The "Internet 462 Commons" is a collection of networks that we depend on but do not 463 control. The main threat to the commons in the context of BGP is 464 routing pollution, or unwanted or unnecessary routing entries. The 465 Internet Society has been working with service providers to improve 466 resiliency by driving a common understanding of both problem and 467 solution space, and developing a shared view with regard to risk and 468 benefits, with the idea being that there would be those who would 469 engage in reciprocal cooperation with the hopes that others would do 470 similarly in order to break the tragedy. 472 What was notable in discussion was that there was no magic bullet to 473 addressing the resiliency issue, and that this was a matter of 474 clearly identifying the key players and convincing them that their 475 incentives were aligned. It also involved developing approaches to 476 measure resiliency. 478 6.2. Getting to the next version of TLS 480 Originally the workshop had planned to look at the question of 481 whether we could mandate stronger security. This evolved into a 482 discussion about getting to the next version of Transport Layer 483 Security (TLS), and what challenges lie ahead. It was pointed out 484 that there were still many old versions of TLS in existence today, 485 due to many old implementations. In particular, it was pointed out 486 that a substantial amount of traffic is still encrypted using triple 487 DES. 489 One concern about the next generation is that perfect could become 490 the enemy of good. Another point that was made was that perhaps a 491 testing platform might help interoperability. Finally, there was 492 some discussion about how new versions of TLS get promoted. 494 7. Outcomes 496 This wide ranging workshop discussed many aspects that go to the 497 success or failure of the work of the IETF. While there is no single 498 silver bullet that we can point to for making a protocol successful, 499 the workshop did discuss a number of outcomes and potential next 500 steps. 502 7.1. Work for the IAB and the IETF 504 The IAB's role in working group formation consists of providing 505 guidance to the IESG on which birds of a feather sessions should be 506 held, review of proposed working group charters, and shepherding some 507 work so that it can reach a suitable stage for standardization. In 508 each of these stages the IAB has an opportunity to apply the lessons 509 of RFC 5218, as well as other work such as the notion of bundling 510 choices, when members give advice. 512 In addition to working group creation, the IAB has an opportunity to 513 track and present protocol success stories, either through wikis or 514 through discussion at plenary sessions. For instance, there is much 515 interest at the moment of this report in Bitcoin, its success, and 516 what parallels and lessons can be drawn. Specifically it would be 517 useful to track examples of first mover advantages. 519 Finally, one area that the IETF may wish to consider, relating 520 specifically to DNSSEC, as raised by our speakers was standardization 521 of the provisioning interface of DNSSEC (DS keys) between parent and 522 child zone. Contributions in this area would be welcome. 524 7.2. Potential for the Internet Research Task Force 526 There are at least two possible activities that the IRTF might wish 527 to consider. The first would be a research group that considers 528 protocol alternatives and recommendations that might be useful in 529 areas where environments are constrained, due to bandwidth or other 530 resources. Such a group has already been proposed, in fact. 532 The second possibility is a more general group that focuses on 533 economic considerations relating to Internet protocol design. In 534 particular there were a number of areas that were presented to the 535 working group that deserve further investigation, and could use 536 collaboration between researchers, engineers, and operators. Two 537 examples include work on bundling as well as systems biology. 539 7.3. Opportunities for others 541 Incentive models often involve many different players. As we 542 considered work in the workshop, our partners such as ICANN, and the 543 RIRs can continue to play a role in encouraging deployment of 544 protocols through their policies. Their members can also participate 545 in any activity of the IRTF that is related to this work. 547 Specifically, RIRs have a specific role to play in encouraging 548 security of the routing system, and ICANN has a specific role to play 549 in securing the domain name service. 551 The suggestion was made that the IETF working groups could leverage 552 graduate students in many universities around the world in helping 553 review documents (drafts, RFCs etc.). This would serve as a source 554 of education in real world processes to students, and would engage 555 the research community in IETF processes more thoroughly, as well as 556 providing a scale-out resource for handling the IETF review workload. 557 Several attendees who have such students were prepared to try this 558 out. 560 8. Security Considerations 562 This document does not discuss a protocol. Security for the workshop 563 itself was excellent. 565 9. Acknowledgments 567 The IAB would like to thank the program committee, who consisted of 568 Roch Guerin, Constantine Dovrolis, Hannes Tschofenig, Joel Halpern, 569 Eliot Lear, and Richard Clayton, as well as other reviewers including 570 Bernard Aboba and Dave Thaler. Their earlier work provided a strong 571 basis for this workshop. 573 A special debt of gratitude is owed to our hosts, Ross Anderson and 574 Richard Clayton for arranging an excellent venue for our discussions. 576 10. Attendees 578 The following people attended the ITAT workshop: 580 Aaron Yi Ding, Adrian Farrel, Andrei Robachevzsky, Arjuna 581 Sathiaseelan, Bjoern Zeeb, Dave Meyer, Dave Thaler, Dongting Yu, 582 Eliot Lear, Elwyn Davies, Erik Nordmark, Hannes Tschofenig, Joel 583 Halpern, Jon Crowcroft, Lars Eggert, Martin Stiemerling, Michael 584 Welzl, Michiel Leenaars, Miyo Kohno, Rainer Bohme, Richard Clayton, 585 Roch Guerin, Ross Anderson, Russ Housley, Sam Smith, Sean Turner, 586 Soumya Sen, Spencer Dawkins, Steven Weber, Tapio Levae, Toby 587 Moncaster, Tony Finch 589 11. Informative References 591 [Bohme13] Bohme, R., "Internet Protocol Adoption: Learning from 592 Bitcoin", December 2013. 594 [Ding13] Yi Ding, A., Korhonen, J., Savolainen, T., Kojo, M., 595 Tarkoma, S., and J. Crowcroft, "Bridge Networking Research 596 and Internet Standardization: Case Study on Mobile Traffic 597 Offloading and IPv6 Transition Technologies", December 598 2013. 600 [Kohno13] Kohno, M., Asaba, T., and F. Baker, "Managing Diversity to 601 Manage Technological Transition", December 2013. 603 [Lear13] Lear, E. and D. Mohlenhoff, "Standards: a love/hate 604 relationship with patents", December 2013. 606 [Leva13] Leva, T. and H. Soumi, "Framework for analyzing 607 feasibility of Internet protocols", December 2013. 609 [Lowinder13] 610 Eklund Lowinder, A.M. and P. Wallstrom, "Long term 611 strategy for a successful deployment of DNSSEC - on all 612 levels", December 2013. 614 [Meyer13] Meyer, D. M., "On the Complexity of Engineered Systems 615 (and its effect on protocol deployment)", December 2013. 617 [RFC2480] Freed, N., "Gateways and MIME Security Multiparts", RFC 618 2480, January 1999. 620 [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. 621 Rose, "Resource Records for the DNS Security Extensions", 622 RFC 4034, March 2005. 624 [RFC4960] Stewart, R., "Stream Control Transmission Protocol", RFC 625 4960, September 2007. 627 [RFC5218] Thaler, D. and B. Aboba, "What Makes For a Successful 628 Protocol?", RFC 5218, July 2008. 630 [RFC6555] Wing, D. and A. Yourtchenko, "Happy Eyeballs: Success with 631 Dual-Stack Hosts", RFC 6555, April 2012. 633 [RFC6698] Hoffman, P. and J. Schlyter, "The DNS-Based Authentication 634 of Named Entities (DANE) Transport Layer Security (TLS) 635 Protocol: TLSA", RFC 6698, August 2012. 637 [Robachevsky13] 638 Robachevsky, A., "Resilience of the commons: routing 639 security", December 2013. 641 [Sathiaseelan13] 642 Sathiaseelan, A., Trossen, D., Komnios, I., Ott, J., and 643 J. Crowcroft, "An Internet Architecture for the 644 Challenged", December 2013. 646 [Sen13] Sen, S., "On Economic Models of Network Technology 647 Adoption, Design, and Viability", December 2013. 649 [Weber13] Weber, S., Guerin, R., and J. C. Oliveira, "When can 650 bundling help adoption of network technologies or 651 services?", December 2013. 653 [Welzl13] Welzl, M., "The "best effort" service as a deployment 654 success factor", December 2013. 656 Appendix A. Changes 658 This section to be removed prior to publication. 660 o 00 Initial Revision. 662 Author's Address 664 Eliot Lear (editor) 665 Richtistrasse 7 666 Wallisellen, ZH CH-8304 667 Switzerland 669 Phone: +41 44 878 9200 670 Email: lear@cisco.com