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