idnits 2.17.1 draft-lazanski-consolidation-01.txt: -(259): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding 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: ---------------------------------------------------------------------------- == There is 1 instance of lines with non-ascii characters in the document. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There is 1 instance of too long lines in the document, the longest one being 86 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (February 22, 2021) is 1152 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: '15' is defined on line 628, but no explicit reference was found in the text == Outdated reference: A later version (-18) exists of draft-ietf-tls-esni-07 Summary: 1 error (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Independent Submission D. Lazanski 2 Internet Draft Last Press Label 3 M. McFadden 4 Internet policy advisors, ltd 5 E. Lear 6 Cisco Systems 7 Intended status: Informational February 22, 2021 8 Expires: August 22, 2021 10 Protocol and Engineering Effects of Consolidation 11 draft-lazanski-consolidation-01.txt 13 Status of this Memo 15 This Internet-Draft is submitted in full conformance with the 16 provisions of BCP 78 and BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six 24 months and may be updated, replaced, or obsoleted by other documents 25 at any time. It is inappropriate to use Internet-Drafts as 26 reference material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html 34 This Internet-Draft will expire on May 2, 2021. 36 Copyright Notice 38 Copyright (c) 2020 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents 43 (http://trustee.ietf.org/license-info) in effect on the date of 44 publication of this document. Please review these documents 45 carefully, as they describe your rights and restrictions with 46 respect to this document. Code Components extracted from this 47 document must include Simplified BSD License text as described in 48 Section 4.e of the Trust Legal Provisions and are provided without 49 warranty as described in the Simplified BSD License. 51 Abstract 53 This document contributes to the ongoing discussion surrounding 54 Internet consolidation. Though there has been much interest in the 55 topic, the conversation has waned. This document aims to discuss 56 recent areas of Internet consolidation that are technical, economic 57 and engineering focused and provide some suggestions for advancing 58 the discussion. 60 Table of Contents 62 1. Introduction...................................................2 63 2. Background to Consolidation Issues.............................3 64 3. Overarching Issues Related to Consolidation....................5 65 3.1. Technical.................................................5 66 3.2. Economic..................................................6 67 3.3. Security..................................................7 68 4. Implications of Consolidation on Internet Architecture.........8 69 4.1. The Changing Architecture of the Internet.................8 70 4.2. The End-to-End Principle Redux............................9 71 5. Implications of Consolidation on Protocol Design..............10 72 5.1. Does Protocol Design Really Affect Consolidation?........10 73 5.2. Case Studies in Consolidation and Protocol Design........10 74 5.2.1. DNS over HTTPS (DOH)................................10 75 5.2.2. Encrypted Server Name Indication (eSNI).............11 76 5.2.3. Privacy Pass........................................11 77 6. Actions for the IETF..........................................12 78 7. Security Considerations.......................................12 79 8. IANA Considerations...........................................13 80 9. Conclusions...................................................13 81 10. References...................................................13 82 10.1. Informative References..................................13 83 11. Acknowledgments..............................................15 85 1. Introduction 87 Internet consolidation has been under discussion for the last 88 several years. The 2019 Internet Society's "Global Internet Report: 89 Consolidation and the Internet Economy" highlighted issues in this 90 topic and kicked started a series of discussions and publications 91 around consolidation. Furthermore, a draft for the Internet 92 Architecture Board (IAB) discussed issues of economic and technical 93 consolidation. [1] Despite community interest, the draft expired 94 without additional work or publication. 96 Further discussions on this issue have stalled in recent months as 97 we have been faced with the Covid-19 pandemic and all of the 98 challenges that this brings to working and living. This draft aims 99 to reengage with the issues of Internet consolidation and bring 100 together current discussions and trends. 102 2. Background to Consolidation Issues and the Role of Standards 104 Internet consolidation is "the process of increasing control over 105 internet infrastructure and services by a small set of 106 organizations." [2] Let us consider two general categories of 107 concentration: "player" and "layer". By player concentration, we 108 mean the aggregating of a market to a small number of providers for 109 a particular service. Layer concentration means the combining of 110 functions within a given layer. An example of "player" concentration 111 would be a relatively small number of email service providers who 112 offer billions of users email service. Or the number of web search 113 providers or even web browser offerings. [3] 115 The Internet is being consolidated from the application layer to the 116 network layer. Large companies, like Facebook and Google, account 117 for a significant amount of the content and applications that are 118 used online today. However, several of these large companies are 119 dominating the development of protocols which fundamentally changes 120 the way in which the Internet works and, ultimately, drives the 121 traffic - and data - into the hands of a few companies. For example, 122 Google has 81% of all searches online and 94% of all mobile searches 123 as of 2020. [4] 125 Market consolidation is not limited to the Internet. It happens 126 when economies of scale provide highly aggregated firms an 127 advantage. For the last three decades, we have witnessed 128 concentration occurring not only in telecommunications, but in the 129 financial sector as well, just to name one other example.[5] The 130 acceleration of consolidation has been assisted by "cloud" 131 technologies, such as occurred with email. In the case of email, 132 the service providers make use of SMTP to exchange messages, IMAP to 133 provide those messages to a user interface, and HTTP, HTML, and 134 JavaScript to present those messages directly to a user's browser. 136 In other cases, fewer Internet standards are in play. In the case 137 of home assistant tools such as the Amazon Echo or Google Home 138 Assistant, communication from these devices to their respective 139 clouds is largely proprietary in nature. In particular, the 140 information models and schemas they use are not exposed to the 141 outside world. This is because the bulk of the service is performed 142 by the cloud, with relatively little processing occurring in the 143 home. This two-sided model eliminates the lengthy standards 144 development process, thereby permitting faster service improvements. 146 On the Internet over previous decades, numerous Internet Service 147 Provider (ISP) markets were subject to deregulation, disaggregation 148 of customers by regulatory requirement, consolidation, and to some 149 extent, re-regulation. 151 Standards have been viewed as a means to prevent barriers to entry. 152 During the 1980s, AT&T was required to abide by standards as part of 153 the consent decree that resolved antitrust litigation, leading to 154 the ability of anyone to connect a telephone to its network. By 155 1994 standards were recognized as a means to prevent technical 156 barriers to trade (TBT) during the Uruguay Round of the World Trade 157 Organization. 159 As mentioned, both the Internet Society and participants of the IETF 160 have recently published on the subject of consolidation. At the 161 IAB's Design Expectations vs. Deployment Reality in Protocol 162 Development Workshop 2019 a handful of the participants discussed 163 concentration and consolidation. [4] Andrew Sullivan looked at three 164 types of concentration in open protocols; web services, network 165 services and standardisation. Both Christian Huitema and Julien 166 Maisonneuve noted concentration, which leads to consolidation, as an 167 effect of economies of scale and network effects in business models 168 in the implementation of business practices. Jari Arkko discussed 169 the impacts of consolidation on the Internet infrastructure in a 170 document for the IETF[6], with the document identifying issues 171 including loss of resilience and increased risk of surveillance. It 172 goes on to note that "it seems prudent to recommend that whenever it 173 comes to Internet infrastructure services, centralised designs 174 should be avoided where possible".[7] From networks to applications, 175 the overarching theme was that consolidation is taking place from 176 one end of the Internet to the other. Additionally, the Journal of 177 Cyber Policy published a special edition on Consolidation of the 178 Internet. Topics in this special issue included market concentration 179 and security, DNS consolidation, supply chains, interoperability and 180 Internet architecture. However, much is still yet to be discussed on 181 consolidation at most layers of the Internet stack. [8] 183 Recently, the US has scrutinized Internet platform services. The 184 release of report Investigation of Competition in Digital Markets in 185 October 2020 [9] showed that both concentration and consolidation in 186 the online marketplace has left consumers with little choice, again 187 at the application layer. Additionally, the US Justice Department 188 announced it is suing Google for Antitrust violations on 20 October 189 2020.[10] Both the report and the lawsuit show that concentration of 190 power of Internet platform services has alarmed the House of 191 Representatives and the Department of Justice to the point of 192 investigation and possible criminal charges. None of this would have 193 happed without consolidation of the application layer. The EU has 194 been investigating the 'gatekeeper' status of big tech. [11] Recent 195 reports reveal that the EU is considering ex ante solutions to the 196 issue of the dominance of certain, large platforms. Such remedies, 197 being discussed in the European Commission to date, include 198 mandatory data sharing and/or mandatory interoperability 199 requirements.[12] Such remedies seek to address the dominant market 200 share of application layer services by American tech companies in 201 Europe. 203 The rhetoric and discussion of consolidation primarily focuses on 204 Internet services and data. However, it is important to draw 205 attention to the issues and risks of consolidation at other layers 206 of the Internet beyond just the application layer. The application 207 layer is directly user facing and, as a result, is what users 208 experience. But the underlying infrastructure and protocols are also 209 going through consolidation as they develop. The complete end to end 210 encryption model forces data into endpoints which consolidates data 211 into several companies. Furthermore, protocol standards are 212 facilitating this consolidation. 214 The QUIC protocol is an example of the consolidation between layers 215 of the Internet - and not at the application layer. Designed and 216 deployed as a transport layer protocol, it effectively replaces TCP 217 at the network layer while also adding improved security. The result 218 is the merging or consolidation of three layers. QUIC should improve 219 efficiency and delivery of applications, but also forces all data to 220 be managed at the endpoint, which in this case is a browser, making 221 it more difficult to manage traffic at the network layer. 223 3. Overarching Issues Related to Consolidation 225 3.1. Technical 227 Consolidation has led to the development of a few, large Internet 228 companies which consumers are using, as mentioned above. But 229 consolidation also has led to the development of a protocols which 230 are developed and used by these few, large Internet companies to 231 control traffic flow and data capture as well. 233 Overarching technical issues related to consolidation include an 234 over-reliance on one or two entities and a handful of protocols. 235 Large stakeholders who have developed and implemented these 236 protocols control the rollout of upgraded versions without 237 competition of even knowledge of it due to the lack of diversity in 238 the market. 240 For example, over 80% of the web browser market is held by two 241 browsers: Chrome and Safari. Chrome alone accounts for 65% of the 242 market overall [13] The makers of Chrome and Safari, Google and 243 Mozilla, have dominated the development of protocols recently and 244 the development QUIC, DoH and TLS. 246 "Did the IETF create a better internet when it approved DoH? There's 247 a lot of disagreement about that, but what has upset many is that 248 DoH was a surprise - the IETF standardised it without consulting 249 some who it was likely to affect," it says in RFC 8890 [14] However, 250 there was little multistakeholder consultation and discussion prior 251 to the adoption of DoH. This was more of a rapid development and 252 deployment process, without the market driving the use cases and 253 uptake. 255 3.2. Economic 257 According to the Internet Society's 2019 report Consolidation In the 258 Internet Economy the Internet economy is broadly defined as, 259 "àeconomic activities that either support the Internet or are fundamentally dependent on the Internet's existence."[15] Internet 260 applications, service infrastructure and access provision are the 261 primary three areas of economic activities on the Internet. 263 One focus of consolidation is around the concentration of power - 264 consumer, technical and financial - into a handful of large Internet 265 companies. The first point of engagement with any of these 266 companies, including Facebook and Google, is through consumer 267 applications. The ability to easily understand consolidation at an 268 application layer, because of the widespread and common use of 269 Facebook and Google, has caused the focus of consolidation and anti- 270 competitive issues from policy makers and politicians to be at the 271 application layer. 273 However, consolidation doesn't always have its downsides. 274 Consolidation allows for economies of scale, investment in 275 infrastructure and the ability for small and medium enterprises to 276 buy and use services, like cloud storage, content distribution 277 networks and security technology, without having to build them from 278 the ground up every time. However, the lack of market diversity 279 means a lack of competition which, in turn means a lack of 280 innovation and a lack of consumer choice. 282 Amazon offers affordable cloud services and Cloudflare is one of 283 only a handful of companies that are content delivery networks at a 284 large scale. So large, in fact, that a substantial amount of 285 Internet traffic transits through Cloudflare's servers, though there 286 are many thousands of small CDNs. Rather than each and every 287 Internet application company create their own storage and content 288 delivery network, it is easier and more affordable to outsource both 289 to other companies. Because of the cost of CDNs at scale, few 290 companies offer these services. 292 The market should be a regulating factor in consolidation. However, 293 new entrants and competition in a market creates options for 294 consumers that potentially pulls them away from popular websites and 295 applications. When this is no longer viable, regulation and anti- 296 trust measures can intervene to remedy a consolidated market which 297 is tending towards or has achieved monopoly status. Legal and 298 regulatory intervention, however, tends to create its own set of 299 issues as seen through several decades of EU intervention in big 300 tech starting with Microsoft in 2004. Unintended consequences with 301 regulatory or legal intervention may skew the market even further. 303 3.3. Security 305 Consolidation of protocol development which has facilitated the 306 secure, end to end encryption of information going over networks in 307 recent years. New technologies such as DNS-over-HTTPS (DoH) and DNS- 308 over-TLS (DoT) standardised through the IETF process allows for 309 confidential look up of DNS queries. However, it has forced updates 310 onto many DNS servers and operating systems. This change in the look 311 up process is forcing the technology to develop in a linear way 312 which has narrowed the ability for companies and small industries to 313 do DNS look ups without updating out of date hardware and software, 314 thereby disenfranchising developing countries and smaller companies 315 without big budgets. This is a form or market consolidation based on 316 development choices by several large companies. 318 The development of these protocols, while providing increased 319 privacy and addressing issues concerning government surveillance, 320 have forced other unintended consequences which is promoting 321 consolidation. 323 4. Implications of Consolidation on Internet Architecture 325 4.1. The Changing Architecture of the Internet 327 The phenomenon of consolidation may be in the eyes of the beholder. 328 A government may see market failure or a need for regulation. [16] A 329 civil society advocate may see it from the point of view of privacy 330 or free speech. For the purposes of this draft we view it from the 331 perspective of the underlying architecture of the public Internet. 333 Consolidation in the Internet's architecture is not a new 334 development. The approach of providing intermediaries to deliver 335 service or content rather than the more traditional end-to-end 336 approach has been in place for more than a decade. However, it is 337 possible to argue that the architecture of the Internet has changed 338 dramatically in the last decade. 340 The architecture of the Internet is always changing. New services, 341 applications and content mean that the market creates new ways to 342 deliver them. Consolidation clearly has economic, social and policy 343 issues, but it is important to understand how consolidation affects 344 the underlying architecture of the Internet. The impact of 345 intermediaries on architecture is often not obvious. 347 The use of intermediaries in the Internet's architecture may include 348 the use of third parties to provide services, applications or 349 content. In the early days of the Web, this was evident when 350 rendering a web page that included content from multiple sources. In 351 today's Internet the intermediaries are not so obvious. 352 Authentication servers, content distribution networks, certificate 353 authorities, malicious content protection and DNS resolution 354 services are all examples of tools provided to the Internet by 355 intermediaries - often without the knowledge or approval of both 356 endpoints. 358 Having intermediaries embedded in the architecture is a different 359 effect from having them embedded in the service structure. The 360 domination by a few companies of the content and application layer 361 is largely an economic effect of scale. On the other hand, there is 362 a prevalent belief that the Internet puts intelligence at the edge. 363 While that may have been true in the past, it is hard to argue that 364 this is a feature of the contemporary Internet. 366 There is a suggestion that the network simply provides for the 367 transport of data. There are almost no network connections like that 368 in today's Internet. A consumer's view of the Internet is limited 369 by unseen intermediaries of many types - some delivering positive 370 services, others not. In either case, a consumer on the Internet 371 seldom makes choices about those intermediaries: they are simply 372 part of the fabric that makes up the Internet. 374 It is into just consolidation from the perspective of a consumer. 375 Almost all important parts of the architecture have been affected by 376 consolidation: DNS resolution, access service, transit provision, 377 content distribution and authorization. Consolidation in these areas 378 has a direct effect on engineering and protocol design. 380 4.2. The End-to-End Principle Redux 382 The end-to-end principle is the idea that reliability and 383 trustworthiness reside at the end nodes of networks rather than in 384 the network itself. In other words, the idea was that the network 385 itself was dumb and intelligence was at the edge or end. However, 386 Internet architecture is evolving in such a way that this principle 387 is changing. 389 Networks and the devices on the networks are acting as access 390 consolidators. For example, 5G will allow for different services, 391 systems and use cases at a very specific level. Network slicing in 392 5G will concentrate services like video on demand into concentrated 393 - and consolidation - areas on a network. [17] 395 Another change is how the layers of the Internet, as discussed in 396 the QUIC example, is consolidating. Differentiation among layers is 397 fading fast with the development of applications which require 398 network access and control. 400 Rapidly, the end-to-end principle is becoming the edge-to-edge 401 principle. But the important part of this is the network is not 402 dumb. Data processing, storage and highly evolved services 403 (including custom data and metadata processing at the edge) means 404 that the 'dumb' network is no longer dumb. 406 If the number of organizations that provide those "network services" 407 that we rely upon is small, our dependence is higher. In extreme 408 cases of engineering, we put ourselves at risk of engineering a 409 single point of failure. But also if organisations can't and won't 410 enter the market, the market is left with very few options and 411 choices. If the number of organizations that provide those "network 412 services" that we rely upon is small, our dependence is higher. In 413 extreme cases of engineering, we put ourselves at risk of 414 engineering a single point of failure. 416 The trend toward highly specific and concentrated processing, as 417 well as the drive for highly customised applications and services 418 will drive the Internet away from an end-to-end principle. This will 419 create not a network of networks, but a mesh. If the mesh is 420 dependent on a small number of very large providers through 421 consolidation, we will have engineered a single source of failure 422 into the Internet. 424 5. Implications of Consolidation on Protocol Design 426 5.1. Does Protocol Design Really Affect Consolidation? 428 There is an idealized view of collaborative, multistakeholder 429 approaches to Internet protocol development that it is democratic 430 with all parties thinking about the greater good, like in the IETF. 431 In reality, protocol development and standards are subject to vested 432 interests, personal approaches and commercial realities.[18] 433 Developing protocols, and standards more generally, takes time, much 434 discussion and a bottom up approach. However, commercial 435 organisations have different goals in the process of trying to 436 standardize protocols. Larger organisations have more resources 437 dedicated to protocol and standards development. Larger 438 organisations with colleagues specifically dedicated to standards 439 tend to have the ability to push for their proposals and their 440 protocols. There is no coincidence that these companies are the ones 441 that have facilitate consolidation on a commercial level and are 442 facilitating consolidation on a protocol level. 444 5.2. Case Studies in Consolidation and Protocol Design 446 5.2.1. DNS over HTTPS (DOH) 448 The development of encrypted DNS, specifically DNS-over-HTTPS (DoH), 449 has been driven by a desire to show full end-to-end encryption of 450 network connections. The protocol was completed and the DoH working groupwound up in March 2020 despite the absence of both resolver 451 discovery and selection mechanisms. This may be addressed in the 452 future.[19] 453 Client software is developing with interim discovery solutions which 454 almost always favouring the large, cloud-based resolver operators. 455 This is leading to a situation where users are being presented with 456 a very small number of pre-configured resolver options irrespective 457 of their location - in some client software as few as three or four 458 options may be presented. [20] Currently, there are many thousands 459 of servers operating without DoH. 461 It is likely that most of the DNS traffic will be consolidated onto 462 a handful of global operators, if multiple options for discovery 463 mechanisms are not developed. The impact that such a loss of 464 diversity of providers may have on the long-term resilience of DNS 465 should not be underestimated. [21] Nor should the attractiveness of 466 these potential network chokepoints to attack be overlooked either 467 to access consolidated data or launch an attack. 468 By routing the DNS over HTTPS, it becomes much easier to track user 469 activity through the use of cookies. Therefore a protocol that was 470 developed to enhance user privacy and security could actually 471 undermine both: privacy through the use of cookies and security by 472 consolidating DNS traffic onto far fewer resolver operators that are 473 far more attractive targets for malicious actors of various types. 474 5.2.2. Encrypted Server Name Indication (eSNI) 476 Options to encrypt the Server Name Indication (SNI) have been 477 explored in the TLS working group but to date it has not been 478 possible to develop a solution without shortcomings. This flaw in 479 the encrypted SNI (eSNI) options under evaluation required a rethink 480 in the approach being taken. 481 The solution now proposed, Encrypted Client Hello (ECH, previously 482 called ECHO) assumes that private origins will co-locate with or 483 hide behind a provider (CDN, application server etc.) which can 484 protect SNIs for all of the domains that it hosts.[22] Whilst there 485 is logic in this approach, the consequence is that the would-be 486 standard encourages further consolidation of data to aid privacy. 487 What it does not appear to consider is the attractiveness of this 488 larger data pool to an attacker, compared with more dispersed 489 solutions. 490 5.2.3. Privacy Pass 492 The Privacy Pass protocol provides a set of cross-domain 493 authorization tokens that protect the client's anonymity in message 494 exchanges with a server. This allows clients to communicate an 495 attestation of a previously authenticated server action, without 496 having to reauthenticate manually. The tokens retain anonymity in 497 the sense that the act of revealing them cannot be linked back to 498 the session where they were initially issued. 500 For Privacy Pass to succeed clients must be able to acquire tokens 501 that they can later redeem with greater privacy and anonymity. This 502 document does not discuss the goals of privacy or anonymity. 503 Instead, it identifies a problem related to the upper bound in 504 number of servers that affects the Privacy Pass ecosystem. 506 "Server centralization" is the strict limit or upper bound in the 507 number of servers available from which a client can acquire a token 508 for later redemption. 510 The architecture draft for Privacy Pass specifies an upper limit of 511 four for this upper bound. 513 An upper bound to available Privacy Pass servers creates 514 architectural, engineering and practical problems for the deployment 515 of the protocol. Any successful deployment of Privacy Pass must find 516 mitigations for these problems. 518 6. Actions for the IETF 520 This document proposes a set of concrete actions: 522 1] using MAPRG in the IRTF to attempt to establish metrics for 523 consolidation. The goal would be to attempt to gain consensus on 524 measurements for consolidation and a mechanism for gathering those 525 metrics over time to answer the question of how much and how quickly 526 the Internet is consolidating. 528 2] encouraging the consideration of consolidation in protocol design 529 either through the requirement of a new section in RFCs that 530 addresses consolidation or thorough guidance to area director 531 reviews of documents in IETF Last Call. 533 3] a new IAB workshop on the Implications of Consolidation on 534 Protocol Design with the goal of encouraging position papers from a 535 variety of stakeholders in the protocol design and implementation 536 process. 538 4] potentially expanding the human rights review process for 539 protocols to include examination of individual protocol design on 540 markets, enterprises and society. 542 7. Security Considerations 544 While this document does not describe a specific protocol, it does 545 discuss the evolving architecture of the Internet. Changes to the 546 Internet's architecture have direct and indirect implications for 547 the Internet's threat model. In another draft [23], we discuss how 548 the evolution of the Internet has changed the threat model. 549 Specifically, the changes to the end-to-end model (see section 4.2 550 above) have inserted new interfaces which must be reflected in 551 security considerations for new protocols. 553 8. IANA Considerations 555 This memo contains no instructions or requests for IANA. The authors 556 continue to appreciate the efforts of IANA staff in support of the 557 IETF. 559 9. Conclusions 561 This document seeks to rekindle and restart the discussion on 562 consolidation. As argued above, Internet consolidation is happening 563 at different places and different layers of the Internet. Though 564 there has been interest in the Internet consolidation in the past, 565 now is the time to start the discussions again. 567 10. References 569 10.1. Informative References 571 [1] Considerations on Internet Consolidation and the Internet 572 Architecture [draft-arkko-iab-internet-consolidation-02]. 574 [2] IBID 576 [3] Google has over at least 80% worldwide market share. 577 https://www.statista.com/statistics/216573/worldwide-market- 578 share-of-search-engines/ 580 [4] Investigation of Competition in Digital Markets, Subcommittee 581 on Antitrust, Commercial and Administrative Law of the 582 Committee on the Judiciary, United States House of 583 Representatives, 6 October 2020. 585 [5] Following An Unexpected Rebound In M&A, Businesses Are Banking 586 On A New Kind Of Dealmaking For Growth In A Post-Covid World 587 https://www.prnewswire.com/news-releases/following-an- 588 unexpected-rebound-in-ma-businesses-are-banking-on-a-new-kind- 589 of-dealmaking-for-growth-in-a-post-covid-world-301228786.html 591 [6] Design Expectations vs. Deployment Reality in Protocol 592 Development Workshop 2019, Intern Architecture Board 593 https://www.iab.org/activities/workshops/dedr- 594 workshop/position-papers/ 596 [7] Centralised Architecture in Internet Infrastructure [draft- 597 arkko-arch-infrastructure-centralisation-00]. 599 [8] IBID page 5. 601 [9] Journal of Cyber Policy, Volume 5, Issue 1 (2020) Special 602 Issue: Consolidation of the Internet 603 (https://www.tandfonline.com/toc/rcyb20/5/1) 605 [10] Investigation of Competition in Digital Markets, Subcommittee 606 on Antitrust, Commercial and Administrative Law of the 607 Committee on the Judiciary, United States House of 608 Representatives, 6 October 2020. 610 [11] Statement of the Attorney General on the Announcement Of Civil 611 Antitrust Lawsuit Filed Against Google, United States 612 Department of Justice, 20 October 2020. 613 https://www.justice.gov/opa/pr/statement-attorney-general- 614 announcement-civil-antitrust-lawsuit-filed-against-google 616 [12] Digital Services Act package, European Commission, ongoing 617 https://ec.europa.eu/info/law/better-regulation/have-your- 618 say/initiatives/12418-Digital-Services-Act-package-ex-ante- 619 regulatory-instrument-of-very-large-online-platforms-acting- 620 as-gatekeepers 622 [13] Browser & Platform Market Share January 2021 623 https://www.w3counter.com/globalstats.php 625 [14] RFC 8890, The Internet is for End Users. Nottingham, Mark. 626 August 2020. https://www.rfc-editor.org/info/rfc8890 628 [15] Consolidation In the Internet Economy, Internet Society, 2019. 629 https://future.internetsociety.org/2019/consolidation-in-the- 630 internet-economy 632 [16] See Google, antitrust and how to best regulate big tech, The 633 Economist, 7 October 2020 634 https://www.economist.com/business/2020/10/07/google- 635 antitrust-and-how-best-to-regulate-big-tech 637 [17] What is Network Slicing? https://5g.co.uk/guides/what-is- 638 network-slicing/ 640 [18] Dominique Lazanski, Governance in international technical 641 standards-making: a tripartite model, Journal of Cyber 642 Policy, 4:3, 362-379, 2019. 643 https://www.tandfonline.com/doi/full/10.1080/23738871.2019.169 644 6851 646 [19] DNS over HTTPS (doh) 647 https://datatracker.ietf.org/group/doh/about/ 649 [20] At the time of writing, the Firefox browser presents a list of 650 three pre-configured resolver options to North American users: 651 Cloudflare, NextDNS and Comcast. 653 [21] Cloudflare DNS goes down taking a large piece of the Internet 654 with it, 17 July 2020. 655 https://techcrunch.com/2020/07/17/cloudflare-dns-goes-down- 656 taking-a-large-piece-of-the-internet-with-it/ 658 [22] TLS Encrypted Client Hello draft-ietf-tls-esni-07 659 https://tools.ietf.org/html/draft-ietf-tls-esni-07 661 [23] An Internet for Users Again draft-lazanski-smart-users- 662 internet-00 https://tools.ietf.org/html/draft-lazanski-smart- 663 users-internet-00 665 11. Acknowledgments 667 Many thanks to all who discussed this with us. 669 This document was prepared using 2-Word-v2.0.template.dot. 671 Authors' Addresses 673 Dominique Lazanski 674 Last Press Label 675 London, UK 677 Email: dml@lastpresslabel.com 679 Mark McFadden 680 Internet policy advisors ltd 681 Chepstow, Wales, UK 683 Email: mark@internetpolicyadvisors.com 685 Eliot Lear 686 Cisco Systems (Switzerland) GmbH 687 Richtistrasse 7 688 CH-8304 Wallisellen 689 Switzerland 691 Email: lear@cisco.com