idnits 2.17.1 draft-arkko-arch-dedr-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 (November 04, 2019) is 1628 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group J. Arkko 3 Internet-Draft Ericsson 4 Intended status: Informational T. Hardie 5 Expires: May 7, 2020 Google 6 November 04, 2019 8 Report from the IAB workshop on Design Expectations vs. Deployment 9 Reality in Protocol Development 10 draft-arkko-arch-dedr-report-00 12 Abstract 14 The Design Expectations vs. Deployment Reality in Protocol 15 Development Workshop was convened by the Internet Architecture Board 16 (IAB) in June 2019. This report summarizes its significant points of 17 discussion and identifies topics that may warrant further 18 consideration. 20 Status of This Memo 22 This Internet-Draft is submitted in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF). Note that other groups may also distribute 27 working documents as Internet-Drafts. The list of current Internet- 28 Drafts is at https://datatracker.ietf.org/drafts/current/. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 This Internet-Draft will expire on May 7, 2020. 37 Copyright Notice 39 Copyright (c) 2019 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents 44 (https://trustee.ietf.org/license-info) in effect on the date of 45 publication of this document. Please review these documents 46 carefully, as they describe your rights and restrictions with respect 47 to this document. Code Components extracted from this document must 48 include Simplified BSD License text as described in Section 4.e of 49 the Trust Legal Provisions and are provided without warranty as 50 described in the Simplified BSD License. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 55 2. Workshop Agenda . . . . . . . . . . . . . . . . . . . . . . . 4 56 3. Position Papers . . . . . . . . . . . . . . . . . . . . . . . 4 57 4. Discussions . . . . . . . . . . . . . . . . . . . . . . . . . 6 58 4.1. Past experiences . . . . . . . . . . . . . . . . . . . . 6 59 4.2. Principles . . . . . . . . . . . . . . . . . . . . . . . 6 60 4.3. Centralised deployment models . . . . . . . . . . . . . . 7 61 4.4. Security . . . . . . . . . . . . . . . . . . . . . . . . 8 62 4.5. Future . . . . . . . . . . . . . . . . . . . . . . . . . 8 63 5. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 9 64 5.1. Summary of discussions . . . . . . . . . . . . . . . . . 9 65 5.2. Actions . . . . . . . . . . . . . . . . . . . . . . . . . 10 66 5.2.1. Potential architecture actions and outputs . . . . . 11 67 5.2.2. Potential other actions . . . . . . . . . . . . . . . 11 68 5.3. Other publications . . . . . . . . . . . . . . . . . . . 11 69 5.4. Feedback . . . . . . . . . . . . . . . . . . . . . . . . 11 70 6. Informative References . . . . . . . . . . . . . . . . . . . 11 71 Appendix A. Particant List . . . . . . . . . . . . . . . . . . . 14 72 Appendix B. Acknowledgements . . . . . . . . . . . . . . . . . . 15 73 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16 75 1. Introduction 77 The Design Expectations vs. Deployment Reality in Protocol 78 Development Workshop was convened by the Internet Architecture Board 79 (IAB) in June 2019. This report summarizes its significant points of 80 discussion and identifies topics that may warrant further 81 consideration. 83 Note: While late in being submitted, this report is still an early 84 version. Comments and contributions are appreciated. We expect to 85 call for review of the -01 version. 87 The background for the workshop was that a number of protocols have 88 presumed specific deployment models during the development or early 89 elaboration of the protocol. Actual deployments have, however, often 90 run contrary to these early expectations when economies of scale, 91 DDoS resilience, market consolidation, or other factors have come 92 into play. These factors can result in the deployed reality being 93 highly concentrated. 95 This is a serious issue for the Internet, as concentrated, 96 centralized deployment models present risks to user choice, privacy, 97 and future protocol evolution. 99 On occasion, the differences to expectations were almost immediate, 100 but they also occur after a significant time has passed from the 101 protocol's initial development. 103 Examples include: 105 Email standards, which presumed many providers running in a largely 106 uncoordinated fashion, but which has seen both significant market 107 consolidation and a need for coordination to defend against spam and 108 other attacks. The coordination and centralized defense mechanisms 109 scale better for large entities, which has fueled additional 110 consolidation. 112 The DNS, which presumed deep hierarchies but has often been deployed 113 in large, flat zones, leading to the nameservers for those zones 114 becoming critical infrastructure. Future developments in DNS may see 115 concentration through the use of globally available common resolver 116 services, which evolve rapidly and can offer better security. 117 Paradoxically, concentration of these queries into few services 118 creates new security and privacy concerns. 120 The Web, which is built on a fundamentally decentralized design, but 121 which is now often delivered with the aid of Content Delivery 122 Networks. Their services provide scaling, distribution, and Denial 123 of Service prevention in ways that new entrants and smaller systems 124 operators would find difficult to replicate. While truly small 125 services and truly large ones may operate using only their own 126 infrastructure, many others are left with the only practical choice 127 being the use of a globally available commercial service. 129 Similar developments may happen with future technologies and 130 services. For instance, the growing use of Machine Learning 131 technology presents challenges for distributing effective 132 implementation of a service throughout a pool of many different 133 providers. 135 In [RFC5218] the IAB tackled what made for a successful protocol. In 136 [RFC8170], the IAB described how to handle protocol transitions. 137 This purpose of the workshop was to explore cases where the initial 138 system design assumptions turned out to be wrong, looking for 139 patterns in what caused those assumptions to fail (e.g., 140 concentration due to DDoS resilience) and in how those failures 141 impact the security, privacy, and manageability of the resulting 142 deployments. 144 While the eventual goals might include proposing common remediations 145 for specific cases of confounded protocol expectations. 147 The workshop call for papers invited the submission of position 148 papers which would: 150 o Describe specific cases where systems assumptions during protocol 151 development were confounded by later deployment conditions. 153 o Survey a set of cases to identify common factors in these 154 confounded expectations. 156 o Explore remediations which foster user privacy, security and 157 provider diversity in the face of these changes. 159 A total of 21 position papers were received, listed in Section 3. On 160 site or remote were 30 participants, listed in Appendix A. 162 2. Workshop Agenda 164 After opening and discussion of goals for the workshop, the 165 discussion focused on five main topics: 167 o Past experiences. What have we learned? 169 o Principles. What forces apply to deployment? What principles to 170 take into account in design? 172 o Centralised deployment models. The good and the bad of 173 centralisation. Can centralisation be avoided? How? 175 o Security. Are we addressing the right threats? What should we 176 prepare ourselves for? 178 o Future. What can we do? Should we get better at predicting, or 179 should we do different things? 181 3. Position Papers 183 The following position papers were submitted to the workshop: 185 o Jari Arkko. "Changes in the Internet Threat Model" [Arkko2019] 187 o Vittorio Bertola. "How the Internet Was Won and Where It Got Us" 188 [Bertola2019] 190 o Carsten Bormann. "WiFi authentication: Some deployment 191 observations from eduroam" [Bormann2019] 193 o Stephane Bortzmeyer. "Encouraging better deployments" 194 [Bortzmeyer2019] 196 o Brian Carpenter and Bing Liu. "Limited Domains and Internet 197 Protocols" [Carpenter2019] 199 o Alissa Cooper. "Don't Forget the Access Network" [Cooper2019] 201 o Stephen Farrell. "We're gonna need a bigger threat model" 202 [Farrell2019] 204 o Phillip Hallam-Baker. "The Devil is in the Deployment" 205 [HallamBaker2019] 207 o Ted Hardie. "Instant Messaging and Presence: A Cautionary Tale" 208 [Hardie2019] 210 o Paul Hoffman. "Realities in DNSSEC Depployment" [Hoffman2019] 212 o Christian Huitema. "Concentration is a business model" 213 [Huitema2019] 215 o Geoff Huston. "The Border Gateway Protocol, 25 years on" 216 [Huston2019] 218 o Dirk Kutscher. "Great Expectations: Protocol Design and 219 Socioeconomic Realities" [Kutscher2019] 221 o Julien Maisonneuve. "DNS, side effects and concentration" 222 [Maisonneuve2019] 224 o John Mattsson. "Privacy, Jurisdiction, and the Health of the 225 Internet" [Mattsson2019] 227 o Moritz Muller. "Rolling Forward: An Outlook on Future Root 228 Rollovers" [Muller2019] 230 o Joerg Ott. "Protocol Design Assumptions and PEPs" [Ott2019] 232 o Lucas Pardue. "Some challenges with IP multicast deployment" 233 [Pardue2019] 235 o Jim Reid. "Where/Why has DNS gone wrong?" [Reid2019] 237 o Mohit Sethi and Tuomas Aura. "IoT Security and the role of 238 Manufacturers: A Story of Unrealistic Design Expectations" 239 [Sethi2019] 241 o Andrew Sullivan. "Three kinds of concentration in open protocols" 242 [Sullivan2019] 244 These papers are available from the IAB website [CFP] [POS]. 246 4. Discussions 248 4.1. Past experiences 250 The workshop investigated deployment cases from WebPKI to DNSSEC, 251 from BGP to NATs, from DNS resolvers to CDNs, and from IOT to instant 252 messaging and social media applications. 254 4.2. Principles 256 Several underlying principles can be observed in the example cases 257 that were discussed. Deployment failures tend to be associated with 258 cases where interdependencies make progress difficult and there's no 259 major advantage for early deployment. Despite persistent problems in 260 the currently used technology, it becomes difficult for the ecosystem 261 to switch to better technology. For instance, there are a number of 262 areas where the Internet routing protocol, BGP, is lacking, but 263 success in deploying significant improvements has been lacking, for 264 instance in the area of security. 266 Another principle appears to be first mover advantage. Several 267 equally interesting technologies have fared in very different ways, 268 depending whether there was an earlier system that provided most of 269 the benefits of the new system. Again, despite potential problems in 270 an already deployed technology, it becomes difficult to deploy 271 improvements due to lack of immediate incentives and due to the 272 competing and already deployed alternative that is proceeding forward 273 in the ecosystem. For instance, WebPKI is very widely deployed and 274 used, but DNSSEC is not. Is this because the earlier commercial 275 adoption of WebPKI, and the initially more complex interdependencies 276 between systems that wished to deploy DNSSEC. 278 The workshop also discussed different types of deployment patterns on 279 the Internet: 281 o Delivering functionality over Internet as a web service. The 282 Internet is an open and standardised system, but the service on 283 top may be closed, essentially running two components of the 284 service provider's software against each other over the browser 285 and Internet infrastructure. Several large application systems 286 have grown in the Internet in this manner, encompassing large 287 amounts of functionality and a large fraction of Internet users. 289 o Delivering concentrated network services that offer the standard 290 capabilities of the Internet. Examples in this category include 291 the provisioning of DNS resolution, some mail services, and so on. 293 The second case is more interesting for an Internet architecture 294 discussion. There can, however, be different underlying situations 295 in that case. The service may be simply a concentrated way to 296 provide a commodity service. The market should find a natural 297 equilibrium for such situations. This may be fine, particularly, 298 where the service does not provide any new underlying advantage to 299 whoever is providing it (in the form of user data that can be 300 commercialized, for instance, or as training data for an important 301 machine learning service). 303 Secondly, the service may be an extension beyond standard protocols, 304 leading to some questions about how well standards and user 305 expectations match. But those questions could be addressed by better 306 or newer standards. But the third situation is more troubling: the 307 service are provided in this concentrated manner due to business 308 patterns that make it easier for particular entities to deploy such 309 services. 311 4.3. Centralised deployment models 313 Many of the participants have struggled with these trends and their 314 effect on desirable characteristics of Internet systems, such as 315 distributed, end-to-end architecture or privacy. Yet, there are many 316 business and technical drivers causing the Internet architecture to 317 become further and further centralised. 319 The hopeful side of this issue is that there are some potential 320 answers: 322 o DDOS defenses do not have to come through large entities, as 323 layered defenses and federation also helps similarly. 325 o Surveillance state data capture can be fought with data object 326 encryption, and not storing all of the datal in one place. 328 o Open interface help guard against the bundling of services in one 329 large entity; as long as there are open, well-defined interface to 330 specific functions these functions can also be performed by other 331 parties. 333 o Commercial surveillance does not seem to curbed by current means. 334 But there are still possibilities, such as stronger regulation, 335 data minimisation, or browsers acting on behalf of users. There 336 are hopeful signs that at least some browsers are becoming more 337 aggressive in this regard. But more is needed. 339 One comment made in the workshop that the Internet community needs to 340 move back from regulation to trying to curb the architectural trend 341 of centralization instead. Another comment was that discussing this 342 in the abstract is not as useful as more concrete, practical actions. 343 For instance, one might imagine DOH deployments with larger number of 344 trusted resolvers. 346 4.4. Security 348 This part of the discussed focused on whether in the current state of 349 the Internet we actually need a new threat model. 351 Many of the communications security concerns have been addressed in 352 the past few years, with increasing encryption. However, issues with 353 trusting endpoints on the other side of the communication have not 354 been addressed, and are becoming more urgent with the advent or 355 centralised service architectures. 357 The participants in the workshop agreed that a new threat model is 358 needed, and that non-communications-security issues need to be 359 treated. 361 Other security discussions were focused on IOT systems, algorithm 362 agility issues, and experiences from difficult security upgrades such 363 as the DNSSEC key rollover. 365 The participants cautioned against relying too much on device 366 manufacturers for security, and being clear on security models and 367 assumptions. Security is often poorly understood, and the 368 assumptions about who the system defends against and not are not 369 clear. 371 4.5. Future 373 The workshop turned into a discussion of what actions we can take: 375 o Documenting our experiences? 377 o Providing advice (to IETF, to others) 379 o Waiting for the catastrophe that will make people agree to 380 changes? (hopefully not this) 382 o Work at the IETF? 383 o Technical solutions/choices? 385 The best way for ietf to do things is through standards; convinging 386 people through other requests is difficult. The IETF needs to: 388 o pick pieces that it is responsible for 390 o being reactive for the rest, be available as an expert in other 391 discussions, provide Internet technology clue where needed, etc. 393 One key question is what other parties need to be involved in any 394 discussions. Platform developers (mobile platforms, cloud systems, 395 etc) is one such group. Specific technology or business groups (such 396 as email provider or certificate authority forums) are another. 398 The workshop also discussed specific technology issues, for instance 399 around IOT systems. One observation in those systems is that there 400 is no single model for applications, they vary. There are a lot of 401 different constraints in different systems and different control 402 points. What is needed perhaps most today is user control and 403 transparency (for instance, via MUD descriptions). Another issue is 404 management, particularly for devices that could be operational for 405 decades. Given the diversity of IOT systems, it may also make more 406 sense to build support systems for the broader solutions that 407 specific solutions or specific protocols. 409 There are also many security issues. While some of them are trivial 410 (such as default passwords), one should also look forward and be 411 prepared to have solutions for, say, trust management for long time 412 scales, or be able to provide data minimization to cut down on 413 potential for leakages. And the difficulty of establishing peer-to- 414 peer security strengthens the need for a central point, which may 415 also be harmful from a long-term privacy perspective. 417 5. Conclusions 419 5.1. Summary of discussions 421 The workshop met in sunny Finnish countryside and made the non- 422 suprising observation that technologies sometimes get deployed in 423 surprising ways. But the consequences of deployment choices can have 424 an impact on security, privacy, centralised vs. distributed models, 425 competition, surveillance, and the IETF community cares deeply about 426 these aspects, so it is worthwhile to spend time in analysis of these 427 choices. 429 The prime factor driving deployments is perceived needs; expecting 430 people to recognise obvious virtues and therefore deploy is not 431 likely to work. 433 And the ecosystem is complex, including for instance many parties: 434 different business roles, users, regulators, and so on, and 435 perceptions of needs and ability to act depends highly on what party 436 one talks to. 438 While the workshop discussed actions and advice, there is a critical 439 question of who these are targeted towards. There is need to 440 construct a map of what parties need to perform what actions. 442 The workshop also made some technical observations. One recent trend 443 is that technology is moving up the stack, e.g., in the areas of 444 services, transport protocol functionality, security, naming, and so 445 on. This impacts how easy or hard changes are, and who is able to 446 perform them. 448 It was also noted that interoperability continues to be important, 449 and we need to explore what new interfaces need standardisation -- 450 this will enable different deployment models & competition. Prime 451 factor driving deployments is actual needs; we cannot force anything 452 to others but can provide solutions for those that need them. Needs 453 and actions may fall on different parties. 455 The workshop also considered the balancing of user non-involvement 456 and transparency and choice, relevant threats such as communicating 457 with malicious endpoints, the role and willigness of browsers in 458 increasing the ability to defending the users' privacy, and concerns 459 around centralised control or data storage points 461 The workshop also discussed specific issues around routing, denial- 462 of-service attacks, IOT systems, role of device manufacturers, the 463 DNS, and regulatory reactions and their possible consequences. 465 5.2. Actions 467 The prime conclusion from the workshop was that the topic is not 468 completed in the workshop. Much more work is needed. The best way 469 for ietf to do things is through standards. The IETF should focus on 470 the parts that it is responsible for, and be available as an expert 471 on other discussions. 473 The documents/outputs and actions described in the following were 474 deemed relevant by the participants. 476 5.2.1. Potential architecture actions and outputs 478 o Develop and document a modern threat model 480 o Continue discussion of consolidation/centralisation issues 482 o Document architectural principles, e.g., (re-)application of the 483 end-to-end principle 485 The first receiver of these thoughts is the IETF and protocol 486 community, but combined with some evangelising & validation elsewhere 488 5.2.2. Potential other actions 490 o Pursue specific IETF topics, e.g., work on taking into account 491 reputation systems in IETF work, working to ensuring certificate 492 scoping can be appropriately limited, building end-to-end 493 encryption tools for applications, etc. 495 o General deployment experiences/advice, and documenting deployment 496 assumptions possibly already in WG charters 498 o A report, and a short summary article will be produced from the 499 workshop. 501 5.3. Other publications 503 The workshop results have also been reported at [ISPColumn] by Geoff 504 Huston. 506 5.4. Feedback 508 Feedback regarding the workshop is appreciated, and can be sent to 509 the program committee, the IAB, or the architecture-discuss list. 511 6. Informative References 513 [Arkko2019] 514 Arkko, J., "Changes in the Internet Threat Model", 515 Position paper submitted for the IAB DEDR workshop , June 516 2019. 518 [Bertola2019] 519 Bertola, V., "How the Internet Was Won and Where It Got 520 Us", Position paper submitted for the IAB DEDR workshop , 521 June 2019. 523 [Bormann2019] 524 Bormann, C., "WiFi authentication: Some deployment 525 observations from eduroam", Position paper submitted for 526 the IAB DEDR workshop , June 2019. 528 [Bortzmeyer2019] 529 Bortzmeyer, S., "Encouraging better deployments", Position 530 paper submitted for the IAB DEDR workshop , June 2019. 532 [Carpenter2019] 533 Carpenter, B. and B. Liu, "Limited Domains and Internet 534 Protocols", Position paper submitted for the IAB DEDR 535 workshop , June 2019. 537 [CFP] IAB, ., "Design Expectations vs. Deployment Reality in 538 Protocol Development Workshop 2019", 539 https://www.iab.org/activities/workshops/dedr-workshop/ , 540 April 2019. 542 [Cooper2019] 543 Cooper, A., "Don't Forget the Access Network", Position 544 paper submitted for the IAB DEDR workshop , June 2019. 546 [Farrell2019] 547 Farrell, S., "We're gonna need a bigger threat model", 548 Position paper submitted for the IAB DEDR workshop , June 549 2019. 551 [HallamBaker2019] 552 Hallam-Baker, P., "The Devil is in the Deployment", 553 Position paper submitted for the IAB DEDR workshop , June 554 2019. 556 [Hardie2019] 557 Hardie, T., "Instant Messaging and Presence: A Cautionary 558 Tale", Position paper submitted for the IAB DEDR 559 workshop , June 2019. 561 [Hoffman2019] 562 Hoffman, P., "Realities in DNSSEC Depployment", Position 563 paper submitted for the IAB DEDR workshop , June 2019. 565 [Huitema2019] 566 Huitema, C., "Concentration is a business model", Position 567 paper submitted for the IAB DEDR workshop , June 2019. 569 [Huston2019] 570 Huston, G., "The Border Gateway Protocol, 25 years on", 571 Position paper submitted for the IAB DEDR workshop , June 572 2019. 574 [ISPColumn] 575 Huston, G., "Network Protocols and their Use", 576 https://www.potaroo.net/ispcol/2019-06/dedr.html , June 577 2019. 579 [Kutscher2019] 580 Kutscher, D., "Great Expectations: Protocol Design and 581 Socioeconomic Realities", Position paper submitted for the 582 IAB DEDR workshop , June 2019. 584 [Maisonneuve2019] 585 Maisonneuve, J., "DNS, side effects and concentration", 586 Position paper submitted for the IAB DEDR workshop , June 587 2019. 589 [Mattsson2019] 590 Mattsson, J., "Privacy, Jurisdiction, and the Health of 591 the Internet", Position paper submitted for the IAB DEDR 592 workshop , June 2019. 594 [Muller2019] 595 Muller, M., "Rolling Forward: An Outlook on Future Root 596 Rollovers", Position paper submitted for the IAB DEDR 597 workshop , June 2019. 599 [Ott2019] Ott, J., "Protocol Design Assumptions and PEPs", Position 600 paper submitted for the IAB DEDR workshop , June 2019. 602 [Pardue2019] 603 Pardue, L., "Some challenges with IP multicast 604 deployment", Position paper submitted for the IAB DEDR 605 workshop , June 2019. 607 [POS] IAB, ., "Position Papers: DEDR Workshop", 608 https://www.iab.org/activities/workshops/dedr-workshop/ 609 position-papers/ , June 2019. 611 [Reid2019] 612 Reid, J., "Where/Why has DNS gone wrong?", Position paper 613 submitted for the IAB DEDR workshop , June 2019. 615 [RFC5218] Thaler, D. and B. Aboba, "What Makes for a Successful 616 Protocol?", RFC 5218, DOI 10.17487/RFC5218, July 2008, 617 . 619 [RFC8170] Thaler, D., Ed., "Planning for Protocol Adoption and 620 Subsequent Transitions", RFC 8170, DOI 10.17487/RFC8170, 621 May 2017, . 623 [Sethi2019] 624 Sethi, M. and T. Aura, "IoT Security and the role of 625 Manufacturers: A Story of Unrealistic Design 626 Expectations", Position paper submitted for the IAB DEDR 627 workshop , June 2019. 629 [Sullivan2019] 630 Sullivan, A., "Three kinds of concentration in open 631 protocols", Position paper submitted for the IAB DEDR 632 workshop , June 2019. 634 Appendix A. Particant List 636 The following is a list of participants on site and over a remote 637 connection: 639 o Arkko, Jari 641 o Aura, Tuomas 643 o Bertola, Vittorio 645 o Bormann, Carsten 647 o Bortzmeyer, Stephane 649 o Cooper, Alissa 651 o Farrell, Stephen 653 o Flinck, Hannu 655 o Gahnberg, Carl 657 o Hallam-Baker, Phillip 659 o Hardie, Ted 661 o Hoffman, Paul 662 o Huitema, Christian (remote) 664 o Huston, Geoff 666 o Komaitis, Konstantinos 668 o Kuhlewind, Mirja 670 o Kutscher, Dirk 672 o Li, Zhenbin 674 o Maisonneuve, Julien 676 o Mattson, John 678 o Muller, Moritz 680 o Ott, Joerg 682 o Pardue, Lucas 684 o Reid, Jim 686 o Rieckers, Jan-Frederik 688 o Sethi, Mohit 690 o Shore, Melinda (remote) 692 o Soininen, Jonne 694 o Sullivan, Andrew 696 o Trammell, Brian 698 Appendix B. Acknowledgements 700 The authors would like to thank the workshop participants, the 701 members of the IAB, and the participants in the architecture 702 discussion list for interesting discussions. The workshop organizers 703 would also like to thank Nokia for hosting the workshop in excellent 704 facilities in Kirkkonummi, Finland. 706 Authors' Addresses 708 Jari Arkko 709 Ericsson 711 Email: jari.arkko@piuha.net 713 Ted Hardie 714 Google 716 Email: ted.ietf@gmail.com