idnits 2.17.1 draft-iab-for-the-users-04.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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (10 March 2020) is 1507 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Obsolete informational reference (is this intentional?): RFC 7230 (Obsoleted by RFC 9110, RFC 9112) Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Architecture Board (IAB) M. Nottingham 3 Internet-Draft 10 March 2020 4 Intended status: Informational 5 Expires: 11 September 2020 7 The Internet is for End Users 8 draft-iab-for-the-users-04 10 Abstract 12 This document explains why the IAB believes that, when there is a 13 conflict between the interests of end users of the Internet and other 14 parties, IETF decisions should favour end users. It also explores 15 how this can more effectively be achieved. 17 Note to Readers 19 The issues list for this draft can be found at 20 https://github.com/intarchboard/for-the-users/issues 21 (https://github.com/intarchboard/for-the-users/issues). 23 The most recent (often, unpublished) draft is at 24 https://intarchboard.github.io/for-the-users/ 25 (https://intarchboard.github.io/for-the-users/). 27 Recent changes are listed at https://github.com/intarchboard/for-the- 28 users/commits/master (https://github.com/intarchboard/for-the- 29 users/commits/master). 31 See also the draft's current status in the IETF datatracker, at 32 https://datatracker.ietf.org/doc/draft-iab-for-the-users/ 33 (https://datatracker.ietf.org/doc/draft-iab-for-the-users/). 35 Status of This Memo 37 This Internet-Draft is submitted in full conformance with the 38 provisions of BCP 78 and BCP 79. 40 Internet-Drafts are working documents of the Internet Engineering 41 Task Force (IETF). Note that other groups may also distribute 42 working documents as Internet-Drafts. The list of current Internet- 43 Drafts is at https://datatracker.ietf.org/drafts/current/. 45 Internet-Drafts are draft documents valid for a maximum of six months 46 and may be updated, replaced, or obsoleted by other documents at any 47 time. It is inappropriate to use Internet-Drafts as reference 48 material or to cite them other than as "work in progress." 49 This Internet-Draft will expire on 11 September 2020. 51 Copyright Notice 53 Copyright (c) 2020 IETF Trust and the persons identified as the 54 document authors. All rights reserved. 56 This document is subject to BCP 78 and the IETF Trust's Legal 57 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 58 license-info) in effect on the date of publication of this document. 59 Please review these documents carefully, as they describe your rights 60 and restrictions with respect to this document. 62 Table of Contents 64 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 65 2. Who Are "End Users"? . . . . . . . . . . . . . . . . . . . . 3 66 3. Why The IETF Should Prioritise End Users . . . . . . . . . . 4 67 4. How The IETF Can Prioritise End Users . . . . . . . . . . . . 5 68 4.1. Engaging the Internet Community . . . . . . . . . . . . . 5 69 4.2. Creating User-Focused Systems . . . . . . . . . . . . . . 7 70 4.3. Identifying Negative End User Impact . . . . . . . . . . 8 71 4.4. Handling Conflicting End User Needs . . . . . . . . . . . 8 72 4.5. Deprioritising Internal Needs . . . . . . . . . . . . . . 9 73 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 74 6. Security Considerations . . . . . . . . . . . . . . . . . . . 9 75 7. Informative References . . . . . . . . . . . . . . . . . . . 9 76 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 10 77 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 11 79 1. Introduction 81 Many who participate in the IETF are most comfortable making what we 82 believe to be purely technical decisions; our process is defined to 83 favor technical merit, through our well-known mantra of "rough 84 consensus and running code." 86 Nevertheless, the running code that results from our process (when 87 things work well) inevitably has an impact beyond technical 88 considerations, because the underlying decisions afford some uses 89 while discouraging others. While we believe we are making only 90 technical decisions, in reality, we are defining (in some degree) 91 what is possible on the Internet itself. 93 This impact has become significant. As the Internet increasingly 94 mediates essential functions in societies, it has unavoidably become 95 profoundly political; it has helped people overthrow governments and 96 revolutionize social orders, swing elections, control populations, 97 collect data about individuals, and reveal secrets. It has created 98 wealth for some individuals and companies while destroying others'. 100 All of this raises the question: For whom do we go through the pain 101 of gathering rough consensus and writing running code? 103 After all, there are a variety of parties that standards can benefit, 104 such as (but not limited to) end users, network operators, schools, 105 equipment vendors, specification authors, specification implementers, 106 content owners, governments, non-governmental organisations, social 107 movements, employers, and parents. 109 Successful specifications will provide some benefit to all of the 110 relevant parties because standards do not represent a zero-sum game. 111 However, there are sometimes situations where there is a conflict 112 between the needs of two (or more) parties. 114 In these situations, when one of those parties is an "end user" of 115 the Internet - for example, a person using a Web browser, mail 116 client, or another agent that connects to the Internet - the Internet 117 Architecture Board argues that the IETF should favor their interests 118 over those of other parties. 120 Section 2 explains what is meant by "end users"; Section 3 outlines 121 why IETF work should prioritise them, and Section 4 describes how we 122 can do that. 124 2. Who Are "End Users"? 126 In this document, "end users," means human users whose activities 127 IETF standards as a whole are designed to support, sometimes 128 indirectly. Thus, the end user of a protocol to manage routers is 129 not a router administrator; it is the people using the network that 130 the router operates within. 132 End users are not necessarily a homogenous group; they might have 133 different views of how the Internet should work, and might occupy 134 several roles, such as a seller, buyer, publisher, reader, service 135 provider and consumer. An end user might be browsing the Web, 136 monitoring remote equipment, playing a game, video conferencing with 137 colleagues, sending messages to friends, or performing an operation 138 in a remote surgery theatre. They might be "at the keyboard", or 139 represented by software indirectly (e.g., as a daemon). 141 Likewise, an individual end user might have many interests (e.g., 142 privacy, security, flexibility, reachability) that are sometimes in 143 tension. 145 A person whose interests we need to consider might not directly be 146 using a specific system connected to the Internet. For example, if a 147 child is using a browser, the interests of that child's parents or 148 guardians may be relevant. A person pictured in a photograph may 149 have an interest in systems that process that photograph; a person 150 entering a room with sensors that send data to the Internet has 151 interests that may be involved in our deliberations about how those 152 sensor readings are handled. 154 While such less-direct interactions between people and the Internet 155 may be harder to evaluate, this document's concept of end-user 156 nonetheless includes such people. 158 3. Why The IETF Should Prioritise End Users 160 Even before the IETF was established, the Internet technical 161 community has focused on user needs since at least [RFC0001], which 162 stated that "One of our goals must be to stimulate the immediate and 163 easy use by a wide class of users." 165 And, while we specialise in technical matters, the IETF is not 166 neutral about the purpose of its work in developing the Internet; in 167 "A Mission Statement for the IETF" [RFC3935], the definitions 168 include: 170 The IETF community wants the Internet to succeed because we 171 believe that the existence of the Internet, and its influence on 172 economics, communication, and education, will help us to build a 173 better human society. 175 Later in Section 2.1, "The Scope of the Internet" it says: 177 The Internet isn't value-neutral, and neither is the IETF. We 178 want the Internet to be useful for communities that share our 179 commitment to openness and fairness. We embrace technical 180 concepts such as decentralized control, edge-user empowerment and 181 sharing of resources, because those concepts resonate with the 182 core values of the IETF community. These concepts have little to 183 do with the technology that's possible, and much to do with the 184 technology that we choose to create. 186 In other words, the IETF is concerned with developing and maintaining 187 the Internet to promote the social good, and the society that the 188 IETF is attempting to enhance is composed of end users, along with 189 groups of them forming businesses, governments, clubs, civil society 190 organizations, and other institutions. 192 Merely advancing the measurable success of the Internet (e.g., 193 deployment size, bandwidth, latency, number of users) is not an 194 adequate goal; doing so ignores how technology is so often used as a 195 lever to assert power over users, rather than empower them. 197 Beyond fulfilling the IETF's mission, prioritising end users can also 198 help to ensure the long-term health of the Internet and the IETF's 199 relevance to it. Perceptions of capture by vendors or other 200 providers harm both; the IETF's work will (deservedly) lose end 201 users' trust if it prioritises (or is perceived to prioritise) 202 others' interests over them. 204 Ultimately, the Internet will succeed or fail based upon the actions 205 of its end users, because they are the driving force behind its 206 growth to date. Not prioritising them jeopardizes the network effect 207 which the Internet relies upon to provide so much value. 209 4. How The IETF Can Prioritise End Users 211 There are a few ways that the IAB believes the IETF community can 212 prioritise end users, based upon our observations. By its nature, 213 this is not a complete list. 215 4.1. Engaging the Internet Community 217 The IETF community does not have any unique insight into what is 218 "good for end users," and it is not uncommon for us to be at a 219 further disadvantage because of our close understanding of some - but 220 not all - aspects of the Internet. 222 At the same time, we do have a culture of considerable deference to a 223 broader "Internet community" - roughly, what this document calls end 224 users - in our decision-making processes. Mere deference, however, 225 is not adequate; even with the best intentions, we cannot assume that 226 our experiences of the Internet are those of all of its end users, or 227 that our decisions have a positive impact upon them. 229 Therefore, we have not only a responsibility to analyse and consider 230 the impacts of the IETF's work, but also a responsibility to consult 231 with that greater Internet community. In particular, we should do so 232 when one of our decisions has potential impact upon end users. 234 The IETF community faces significant hurdles in doing so. Our work 235 is specialised and often esoteric, and processes for developing 236 standards often involve very long timescales. Affected parties are 237 rarely technical experts, and their experience of the Internet is 238 often based upon incomplete (and sometimes inaccurate) models. 239 Often, even when we try to engage a broader audience, their 240 participation is minimal - until a change affects someone in a way 241 they don't like. Surprising the Internet community is rarely a good 242 outcome. 244 Government-sponsored individuals sometimes participate in the IETF 245 community. While this is welcome, it should not be taken as 246 automatically representative of end users elsewhere, or even all end 247 users in the relevant jurisdiction. Furthermore, what is desirable 248 in one jurisdiction (or at least to its administrators) might be 249 detrimental in others (see Section 4.4). 251 While some civil society organisations specialise in technology and 252 Internet policy, they typically do not have the capacity to 253 participate broadly, nor are they necessarily representative of the 254 larger Internet community. Nevertheless, their understanding of end 255 user needs is often profound, and they are in many ways the best 256 informed advocates for end user concerns; they should be considered a 257 primary channel for engaging the broader Internet community. 259 A promising approach to help fill these gaps is to identify and 260 engage with specifically affected communities when making decisions 261 that might affect them; for example, one or more industry 262 associations, user groups, or a set of individuals, though we can't 263 of course formally ensure that they are appropriately representative. 265 In doing so, we should not require them to "come to us"; unless a 266 stakeholder community is already engaged in the IETF process 267 effectively, the IETF community should explore how to meet with them 268 on their terms - taking the initiative to contact them, explain our 269 work, and solicit their feedback. 271 In particular, while IAB workshops, BoFs and Bar BoFs can be an 272 effective mechanism to gather input within our community, they often 273 do not have the visibility in other communities that is required to 274 solicit input, much less effective participation. 276 Instead, an event like a workshop may be more effective if co-located 277 with - and ideally hosted or co-hosted by - a forum that's familiar 278 to that stakeholder community. We should also take the opportunity 279 to raise the visibility of IETF work (or potential IETF work) in such 280 fora through conference talks, panels, newsletter articles, etc. 282 For example, the IAB held the ESCAPE workshop [I-D.iab-escape-report] 283 to solicit input from Internet publishers and advertisers that might 284 be affected by a proposal for new work in the IETF. While the 285 workshop was considered successful, participation might have been 286 improved by identifying an appropriate industry forum and working 287 with them to host the event. 289 When we engage with the Internet community, we should also clearly 290 identify tailored feedback mechanisms (e.g., subscribing to a mailing 291 list may not be appropriate), and assure that they are well-known in 292 those communities. 294 The Internet Society can be an invaluable partner in these efforts; 295 their focus on the Internet community, policy expertise and resources 296 can help to facilitate discussions with the appropriate parties. 298 Finally, we should remember that the RFC series are Requests For 299 Comments; if there are serious implications of our work, we should 300 document them and ask for feedback from the Internet Community. 302 4.2. Creating User-Focused Systems 304 We should pay particular attention to the kinds of architectures we 305 create, and whether they encourage or discourage an Internet that 306 works for end users. 308 For example, one of the most successful Internet applications is the 309 Web, which uses the HTTP application protocol. One of HTTP's key 310 implementation roles is that of the Web browser - called the "user 311 agent" in [RFC7230] and other specifications. 313 User agents act as intermediaries between a service and the end user; 314 rather than downloading an executable program from a service that has 315 arbitrary access into the users' system, the user agent only allows 316 limited access to display content and run code in a sandboxed 317 environment. Of course, end users are diverse and the ability of a 318 limited number of user agents to properly represent individual 319 interests is imperfect, but this arrangement is an improvement over 320 the alternative - the need to completely trust a Web site with all 321 information on your system to browse it. 323 Defining the user agent role in standards also creates a virtuous 324 cycle; it allows multiple implementations, thereby allowing end users 325 to switch between them with relatively low costs (although there are 326 concerns about the complexity of the Web creating barriers to entry 327 for new implementations). This creates an incentive for implementers 328 to carefully consider the users' needs, which often are reflected 329 back into the defining standards. The resulting ecosystem has many 330 remaining problems, but a distinguished user agent role provides an 331 opportunity to improve it. 333 In contrast, the Internet of Things (IoT) has not yet seen the broad 334 adoption of a similar role; many current systems require opaque, 335 vendor-specific software or hardware for the user-facing component. 337 Perhaps as a result of this, that ecosystem and its end users face 338 serious challenges. 340 4.3. Identifying Negative End User Impact 342 At its best, our work will unambiguously build a better human 343 society. In some cases, we will consciously decide to be neutral and 344 open-ended, allowing the "tussle" among stakeholders to produce a 345 range of results (see [TUSSLE] for further discussion). 347 At the very least, however, we must examine our work for negative 348 impact on end users, and take steps to mitigate it where encountered. 349 In particular, when we've identified a conflict between the interests 350 of end users and other stakeholders, we should err on the side of 351 protecting end users. 353 Note that "negative impact on end users" is not defined in this 354 document; that is something that the relevant body (e.g., Working 355 Group) needs to discuss and come to consensus on. Merely asserting 356 that something is harmful is not adequate. The converse is also 357 true, though; it's not good practice to avoid identifying harms, nor 358 is it acceptable to ignore them when brought to our attention. 360 The IAB and IETF have already established a body of guidance for 361 situations where this sort of conflict is common, including (but not 362 limited to) [RFC7754] on filtering, [RFC7258] and [RFC7624] on 363 pervasive surveillance, [RFC7288] on host firewalls, and [RFC6973] 364 regarding privacy considerations. 366 Much of that advice has focused on maintaining the end-to-end 367 properties of a connection [RFC3724]. This does not mean that our 368 responsibility to end users stops there; decisions might affect them 369 in other ways. For example, data collection by various applications 370 even inside otherwise secure connections is a major problem on the 371 Internet today. Also, inappropriate concentration of power on the 372 Internet has become a concerning phenomenon - one that protocol 373 design might have some influence upon. 375 4.4. Handling Conflicting End User Needs 377 When the needs of different end users conflict (for example, two sets 378 of end users both have reasonable desires) we again should try to 379 minimise negative impact. 381 For example, when a decision improves the Internet for end users in 382 one jurisdiction, but at the cost of potential harm to others 383 elsewhere, that is not a good tradeoff. As such, we effectively 384 design the Internet for the pessimal environment; if a user can be 385 harmed, they probably will be, somewhere. 387 There may be cases where genuine technical need requires compromise. 388 However, such tradeoffs are carefully examined and avoided when there 389 are alternate means of achieving the desired goals. If they cannot 390 be, these choices and reasoning ought to be thoroughly documented. 392 4.5. Deprioritising Internal Needs 394 There are a number of needs that are very visible to us as 395 specification authors, but should explicitly not be prioritised over 396 the needs of end users. 398 These include: convenience for document editors, IETF process 399 matters, and "architectural purity" for its own sake. 401 5. IANA Considerations 403 This document does not require action by IANA. 405 6. Security Considerations 407 This document does not have any direct security impact; however, 408 failing to prioritise end users might well affect their security 409 negatively in the long term. 411 7. Informative References 413 [I-D.iab-escape-report] 414 Thomson, M. and M. Nottingham, "Report from the IAB 415 Workshop on Exploring Synergy between Content Aggregation 416 and the Publisher Ecosystem (ESCAPE)", Work in Progress, 417 Internet-Draft, draft-iab-escape-report-00, 18 September 418 2019, . 421 [RFC0001] Crocker, S., "Host Software", RFC 1, DOI 10.17487/RFC0001, 422 April 1969, . 424 [RFC3724] Kempf, J., Ed., Austein, R., Ed., and IAB, "The Rise of 425 the Middle and the Future of End-to-End: Reflections on 426 the Evolution of the Internet Architecture", RFC 3724, 427 DOI 10.17487/RFC3724, March 2004, 428 . 430 [RFC3935] Alvestrand, H., "A Mission Statement for the IETF", 431 BCP 95, RFC 3935, DOI 10.17487/RFC3935, October 2004, 432 . 434 [RFC6973] Cooper, A., Tschofenig, H., Aboba, B., Peterson, J., 435 Morris, J., Hansen, M., and R. Smith, "Privacy 436 Considerations for Internet Protocols", RFC 6973, 437 DOI 10.17487/RFC6973, July 2013, 438 . 440 [RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 441 Protocol (HTTP/1.1): Message Syntax and Routing", 442 RFC 7230, DOI 10.17487/RFC7230, June 2014, 443 . 445 [RFC7258] Farrell, S. and H. Tschofenig, "Pervasive Monitoring Is an 446 Attack", BCP 188, RFC 7258, DOI 10.17487/RFC7258, May 447 2014, . 449 [RFC7288] Thaler, D., "Reflections on Host Firewalls", RFC 7288, 450 DOI 10.17487/RFC7288, June 2014, 451 . 453 [RFC7624] Barnes, R., Schneier, B., Jennings, C., Hardie, T., 454 Trammell, B., Huitema, C., and D. Borkmann, 455 "Confidentiality in the Face of Pervasive Surveillance: A 456 Threat Model and Problem Statement", RFC 7624, 457 DOI 10.17487/RFC7624, August 2015, 458 . 460 [RFC7754] Barnes, R., Cooper, A., Kolkman, O., Thaler, D., and E. 461 Nordmark, "Technical Considerations for Internet Service 462 Blocking and Filtering", RFC 7754, DOI 10.17487/RFC7754, 463 March 2016, . 465 [TUSSLE] Clark, D., Sollins, K., Wroclawski, J., and R. Braden, 466 "Tussle in Cyberspace: Defining Tomorrow's Internet", 467 2002, 468 . 471 Acknowledgements 473 This document was influenced by many discussions, both inside and 474 outside of the IETF and IAB. In particular, Edward Snowden's 475 comments regarding the priority of end users at IETF 93 and the HTML5 476 Priority of Constituencies were both influential. 478 Many people gave feedback and input, including Harald Alvestrand, 479 Mohamed Boucadair, Stephen Farrell, Joe Hildebrand, Lee Howard, Russ 480 Housley, Niels ten Oever, Mando Rachovitsa, Martin Thomson, Brian 481 Trammell, John Klensin, Eliot Lear, Ted Hardie, and Jari Arkko. 483 Author's Address 485 Mark Nottingham 487 Email: mnot@mnot.net 488 URI: https://www.mnot.net/