idnits 2.17.1 draft-iab-for-the-users-02.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 (22 January 2020) is 1556 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 22 January 2020 4 Intended status: Informational 5 Expires: 25 July 2020 7 The Internet is for End Users 8 draft-iab-for-the-users-02 10 Abstract 12 This document explains why the IAB believes the IETF should consider 13 end users as its highest priority concern, and how that can be done. 15 Note to Readers 17 The issues list for this draft can be found at 18 https://github.com/intarchboard/for-the-users/issues 19 (https://github.com/intarchboard/for-the-users/issues). 21 The most recent (often, unpublished) draft is at 22 https://intarchboard.github.io/for-the-users/ 23 (https://intarchboard.github.io/for-the-users/). 25 Recent changes are listed at https://github.com/intarchboard/for-the- 26 users/commits/master (https://github.com/intarchboard/for-the- 27 users/commits/master). 29 See also the draft's current status in the IETF datatracker, at 30 https://datatracker.ietf.org/doc/draft-iab-for-the-users/ 31 (https://datatracker.ietf.org/doc/draft-iab-for-the-users/). 33 Status of This Memo 35 This Internet-Draft is submitted in full conformance with the 36 provisions of BCP 78 and BCP 79. 38 Internet-Drafts are working documents of the Internet Engineering 39 Task Force (IETF). Note that other groups may also distribute 40 working documents as Internet-Drafts. The list of current Internet- 41 Drafts is at https://datatracker.ietf.org/drafts/current/. 43 Internet-Drafts are draft documents valid for a maximum of six months 44 and may be updated, replaced, or obsoleted by other documents at any 45 time. It is inappropriate to use Internet-Drafts as reference 46 material or to cite them other than as "work in progress." 48 This Internet-Draft will expire on 25 July 2020. 50 Copyright Notice 52 Copyright (c) 2020 IETF Trust and the persons identified as the 53 document authors. All rights reserved. 55 This document is subject to BCP 78 and the IETF Trust's Legal 56 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 57 license-info) in effect on the date of publication of this document. 58 Please review these documents carefully, as they describe your rights 59 and restrictions with respect to this document. 61 Table of Contents 63 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 64 2. What Are "End Users"? . . . . . . . . . . . . . . . . . . . . 3 65 3. Why The IETF Should Prioritise End Users . . . . . . . . . . 4 66 4. How The IETF Can Prioritise End Users . . . . . . . . . . . . 5 67 4.1. Engaging the Internet Community . . . . . . . . . . . . . 5 68 4.2. Creating User-Focused Systems . . . . . . . . . . . . . . 7 69 4.3. Identifying Negative End User Impact . . . . . . . . . . 7 70 4.4. Handling Conflicting End User Needs . . . . . . . . . . . 8 71 4.5. Deprioritising Internal Needs . . . . . . . . . . . . . . 8 72 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 73 6. Security Considerations . . . . . . . . . . . . . . . . . . . 8 74 7. Informative References . . . . . . . . . . . . . . . . . . . 9 75 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 10 76 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 10 78 1. Introduction 80 Many who participate in the IETF are most comfortable making what we 81 believe to be purely technical decisions; our process is defined to 82 favor technical merit, through our well-known mantra of "rough 83 consensus and running code." 85 Nevertheless, the running code that results from our process (when 86 things work well) inevitably has an impact beyond technical 87 considerations, because the underlying decisions afford some uses 88 while discouraging others. While we believe we are making only 89 technical decisions, in reality, we are defining (in some degree) 90 what is possible on the Internet itself. 92 This impact has become significant. As the Internet increasingly 93 mediates essential functions in societies, it has unavoidably become 94 profoundly political; it has helped people overthrow governments and 95 revolutionize social orders, swing elections, control populations, 96 collect data about individuals, and reveal secrets. It has created 97 wealth for some individuals and companies while destroying others'. 99 All of this raises the question: Who do we go through the pain of 100 gathering rough consensus and writing running code for? 102 After all, there are a variety of parties that standards can benefit, 103 such as (but not limited to) end users, network operators, schools, 104 equipment vendors, specification authors, specification implementers, 105 content owners, governments, non-governmental organisations, social 106 movements, employers, and parents. 108 Successful specifications will provide some benefit to all of the 109 relevant parties because standards do not represent a zero-sum game. 110 However, there are sometimes situations where there is a need to 111 balance the benefits of a decision between two (or more) parties. 113 In these situations, when one of those parties is an "end user" of 114 the Internet - for example, a person using a Web browser, mail 115 client, or another agent that connects to the Internet - the Internet 116 Architecture Board argues that the IETF should favor their interests 117 over those of parties. 119 Section 2 explains what is meant by "end users"; Section 3 outlines 120 why IETF work should prioritise them, and Section 4 describes how we 121 can do that. 123 2. What Are "End Users"? 125 In this document, "end users," means non-technical users whose 126 activities IETF standards are designed to support, sometimes 127 indirectly. Thus, the end user of a protocol to manage routers is 128 not a router administrator; it is the people using the network that 129 the router operates within. 131 End users are not necessarily a homogenous group; they might have 132 different views of how the Internet should work, and might occupy 133 several roles, such as a seller, buyer, publisher, reader, service 134 provider and consumer. An end user might be browsing the Web, 135 monitoring remote equipment, playing a game, video conferencing with 136 colleagues, sending messages to friends, or performing an operation 137 in a remote surgery theatre. They might be "at the keyboard", or 138 represented by software indirectly (e.g., as a daemon). 140 Likewise, an individual end user might have many interests (e.g., 141 privacy, security, flexibility, reachability) that are sometimes in 142 tension. 144 A person whose interests we need to consider might not directly be 145 using a specific system connected to the Internet. For example, if a 146 child is using a browser, the interests of that child's parents or 147 guardians may be relevant. A person pictured in a photograph may 148 have an interest in systems that process that photograph; a person 149 entering a room with sensors that send data to the Internet has 150 interests that may be involved in our deliberations about how those 151 sensor readings are handled. 153 While such less-direct interactions between people and the Internet 154 may be harder to evaluate, this document's concept of end-user 155 nonetheless includes such people. 157 3. Why The IETF Should Prioritise End Users 159 Even before the IETF was established, the Internet technical 160 community has focused on user needs since at least [RFC0001], which 161 stated that "One of our goals must be to stimulate the immediate and 162 easy use by a wide class of users." 164 And, while we specialise in technical matters, the IETF is not 165 neutral about the purpose of its work in developing the Internet; in 166 "A Mission Statement for the IETF" [RFC3935], the definitions 167 include: 169 The IETF community wants the Internet to succeed because we 170 believe that the existence of the Internet, and its influence on 171 economics, communication, and education, will help us to build a 172 better human society. 174 Later in Section 2.1, "The Scope of the Internet" it says: 176 The Internet isn't value-neutral, and neither is the IETF. We 177 want the Internet to be useful for communities that share our 178 commitment to openness and fairness. We embrace technical 179 concepts such as decentralized control, edge-user empowerment and 180 sharing of resources, because those concepts resonate with the 181 core values of the IETF community. These concepts have little to 182 do with the technology that's possible, and much to do with the 183 technology that we choose to create. 185 In other words, the IETF is concerned with developing and maintaining 186 the Internet to promote the social good, and the society that the 187 IETF is attempting to improve is composed of end users, along with 188 groups of them forming businesses, governments, clubs, civil society 189 organizations, and other institutions. 191 Merely advancing the measurable success of the Internet (e.g., 192 deployment size, bandwidth, latency, number of users) is not an 193 adequate goal; doing so ignores how technology is so often used as a 194 lever to assert power over users, rather than empower them. 196 Beyond fulfilling the IETF's mission, prioritising end users also 197 helps to ensure the long-term health of the Internet and the IETF's 198 relevance to it. Perceptions of capture by vendors or other 199 providers harm both; the IETF's work will (deservedly) lose end 200 users' trust if it prioritises (or is perceived to prioritise) 201 others' interests over them. 203 Ultimately, the Internet will succeed or fail based upon the actions 204 of its users, because they are the driving force behind its growth to 205 date. Not prioritising them jeopardizes the network effect which the 206 Internet relies upon to provide so much value. 208 4. How The IETF Can Prioritise End Users 210 There are a few ways that the IAB believes the IETF community can 211 prioritise end users, based upon our observations. By its nature, 212 this is not a complete list. 214 4.1. Engaging the Internet Community 216 The IETF community does not have any unique insight into what is 217 "good for end users," and it is not uncommon for us to be at a 218 further disadvantage because of our close understanding of some - but 219 not all - aspects of the Internet. 221 At the same time, we do have a culture of considerable deference to a 222 broader "Internet community" in our decision-making processes. Mere 223 deference, however, is not adequate; even with the best intentions, 224 we cannot assume that our experiences of the Internet are those of 225 all of its end users, or that our decisions have a positive impact 226 upon them. 228 Therefore, we have not only a responsibility to analyse and consider 229 the impacts of the IETF's work, but also a responsibility to consult 230 with that greater Internet community. We should enter into a 231 dialogue about not only the technical concerns that are well- 232 represented in the IETF but also the political, social and economic 233 concerns that it engenders, and that are better represented 234 elsewhere. 236 The IETF community faces significant hurdles in doing so. Our work 237 is specialised and often esoteric, and standard processes often occur 238 on very long timescales. Affected parties are rarely technical 239 experts, and their experience of the Internet is often based upon 240 incomplete (and sometimes inaccurate) models. Often, even when we 241 try to engage a broader audience, their participation is minimal - 242 until a change affects someone in a way they don't like. Surprising 243 the Internet community is rarely a good outcome. 245 Government representatives sometimes participate in the IETF 246 community. While this is welcome, it should not be taken as 247 automatically representative of end users elsewhere, or even all end 248 users in the relevant jurisdiction. Furthermore, what is desirable 249 in one jurisdiction (or at least to its administrators) might be 250 detrimental in others (see Section 4.4). 252 While some civil society organisations specialise in technology and 253 Internet policy, they typically do not have the capacity to 254 participate broadly, nor are they necessarily representative of the 255 larger Internet community. Nevertheless, their understanding of end 256 user needs is often profound, and they are in many ways the most 257 representative advocates for end user concerns; they should be 258 considered a primary channel for engaging the broader Internet 259 community. 261 A promising approach to help fill these gaps is to identify and 262 engage with specifically affected communities; for example, one or 263 more industry associations, user groups, or a set of individuals, 264 though we can't of course formally ensure that they are appropriately 265 representative. 267 In doing so, we should not require them to "come to us"; unless a 268 stakeholder community is already engaged in the IETF process 269 effectively, the IETF community should explore how to meet with them 270 on their terms - taking the initiative to contact them, explain our 271 work, and solicit their feedback. 273 In particular, while IAB workshops, BoFs and Bar BoFs can be an 274 effective mechanism to gather input within our community, they often 275 do not have the visibility in other communities that is required to 276 solicit input, much less effective participation. 278 Instead, an event like a workshop should be co-located - and ideally 279 hosted or co-hosted - by a forum that's familiar to that stakeholder 280 community. We should also take the opportunity to raise the 281 visibility of IETF work (or potential IETF work) in such fora through 282 conference talks, panels, newsletter articles, etc. 284 When we engage with the Internet community, we should also clearly 285 identify tailored feedback mechanisms (e.g., subscribing to a mailing 286 list may not be appropriate), and assure that they are well-known in 287 those communities. 289 Finally, we should remember that the RFC series are Requests For 290 Comments; if there are serious implications of our work, we should 291 document them and ask for feedback from the Internet Community. 293 4.2. Creating User-Focused Systems 295 We should pay particular attention to the kinds of architectures we 296 create, and whether they encourage or discourage an Internet that 297 works for end users. 299 For example, one of the most successful Internet applications is the 300 Web. One of its key implementation roles is that of the Web browser - 301 called the User Agent in [RFC7230] and other specifications. Because 302 there are multiple interoperable implementations, users can switch 303 with relatively low costs, and as a result there is a natural 304 tendency to more carefully consider the user's needs as an agent. 305 This leads to Web browsers' interests being better aligned with those 306 of their users, creating an ecosystem that is more user-focused (even 307 if there are serious challenges in it regarding the balance of power 308 between implementations and the barrier to entry for new 309 implementations). 311 In contrast, the Internet of Things (IoT) has not yet seen the 312 emergence of a natural role for representing the needs of the end 313 user. Perhaps as a result of this, that ecosystem and its users face 314 serious challenges. 316 We should also create explicit roles for users in our protocols where 317 appropriate, and respect them. 319 4.3. Identifying Negative End User Impact 321 At its best, our work will unambiguously promote the collective 322 social good. In some cases, we will consciously decide to be neutral 323 and open-ended, allowing the "tussle" among stakeholders to produce a 324 range of results (see [TUSSLE] for further discussion). 326 At the very least, however, we must examine our work for negative 327 impact on end users, and take steps to mitigate it where encountered. 328 In particular, when we've identified a conflict between the interests 329 of end users and other stakeholders, we should err on the side of 330 protecting end users. 332 Note that "negative impact on end users" is not defined in this 333 document; that is something that the relevant body (e.g., Working 334 Group) needs to discuss and come to consensus on. Merely asserting 335 that something is harmful is not adequate. The converse is also 336 true, though; it's not permissible to avoid identifying harms, nor is 337 it acceptable to ignore them when brought to our attention. 339 The IAB and IETF have already established a body of guidance for 340 situations where this sort of conflict is common, including (but not 341 limited to) [RFC7754] on filtering, [RFC7258] and [RFC7624] on 342 pervasive surveillance, [RFC7288] on host firewalls, and [RFC6973] 343 regarding privacy considerations. 345 Much of that advice has focused on maintaining the end-to-end 346 properties of a connection [RFC3724]. This does not mean that our 347 responsibility to users stops there; decisions might affect users in 348 other ways. For example, data collection by various applications 349 even inside otherwise secure connections is a major problem on the 350 Internet today. Also, inappropriate concentration of power on the 351 Internet has become a concerning phenomenon - one that protocol 352 design might have some influence upon. 354 4.4. Handling Conflicting End User Needs 356 When the needs of different end users conflict (for example, two sets 357 of end users both have reasonable desires) we again should try to 358 minimise negative impact. 360 For example, when a decision improves the Internet for end users in 361 one jurisdiction, but at the cost of potential harm to others 362 elsewhere, that is not a good tradeoff. As such, we effectively 363 design the Internet for the pessimal environment; if a user can be 364 harmed, they probably will be, somewhere. 366 There may be cases where genuine technical need requires compromise. 367 However, such tradeoffs are carefully examined and avoided when there 368 are alternate means of achieving the desired goals. If they cannot 369 be, these choices and reasoning ought to be thoroughly documented. 371 4.5. Deprioritising Internal Needs 373 There are a number of needs that are very visible to us as 374 specification authors, but should explicitly not be prioritised over 375 the needs of end users. 377 These include: convenience for document editors, IETF process 378 matters, and "architectural purity" for its own sake. 380 5. IANA Considerations 382 This document does not require action by IANA. 384 6. Security Considerations 386 This document does not have any direct security impact; however, 387 failing to prioritise end users might well affect their security 388 negatively in the long term. 390 7. Informative References 392 [RFC0001] Crocker, S., "Host Software", RFC 1, DOI 10.17487/RFC0001, 393 April 1969, . 395 [RFC3724] Kempf, J., Ed., Austein, R., Ed., and IAB, "The Rise of 396 the Middle and the Future of End-to-End: Reflections on 397 the Evolution of the Internet Architecture", RFC 3724, 398 DOI 10.17487/RFC3724, March 2004, 399 . 401 [RFC3935] Alvestrand, H., "A Mission Statement for the IETF", 402 BCP 95, RFC 3935, DOI 10.17487/RFC3935, October 2004, 403 . 405 [RFC6973] Cooper, A., Tschofenig, H., Aboba, B., Peterson, J., 406 Morris, J., Hansen, M., and R. Smith, "Privacy 407 Considerations for Internet Protocols", RFC 6973, 408 DOI 10.17487/RFC6973, July 2013, 409 . 411 [RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 412 Protocol (HTTP/1.1): Message Syntax and Routing", 413 RFC 7230, DOI 10.17487/RFC7230, June 2014, 414 . 416 [RFC7258] Farrell, S. and H. Tschofenig, "Pervasive Monitoring Is an 417 Attack", BCP 188, RFC 7258, DOI 10.17487/RFC7258, May 418 2014, . 420 [RFC7288] Thaler, D., "Reflections on Host Firewalls", RFC 7288, 421 DOI 10.17487/RFC7288, June 2014, 422 . 424 [RFC7624] Barnes, R., Schneier, B., Jennings, C., Hardie, T., 425 Trammell, B., Huitema, C., and D. Borkmann, 426 "Confidentiality in the Face of Pervasive Surveillance: A 427 Threat Model and Problem Statement", RFC 7624, 428 DOI 10.17487/RFC7624, August 2015, 429 . 431 [RFC7754] Barnes, R., Cooper, A., Kolkman, O., Thaler, D., and E. 432 Nordmark, "Technical Considerations for Internet Service 433 Blocking and Filtering", RFC 7754, DOI 10.17487/RFC7754, 434 March 2016, . 436 [TUSSLE] Clark, D., Sollins, K., Wroclawski, J., and R. Braden, 437 "Tussle in Cyberspace: Defining Tomorrow's Internet", 438 2002, 439 . 442 Appendix A. Acknowledgements 444 This document was influenced by many discussions, both inside and 445 outside of the IETF and IAB. In particular, Edward Snowden's 446 comments regarding the priority of end users at IETF 93 and the HTML5 447 Priority of Constituencies were both influential. 449 Many people gave feedback and input, including Harald Alvestrand, 450 Mohamed Boucadair, Stephen Farrell, Joe Hildebrand, Lee Howard, Russ 451 Housley, Niels ten Oever, Mando Rachovitsa, Martin Thomson, Brian 452 Trammell, John Klensin, Eliot Lear, Ted Hardie, and Jari Arkko. 454 Author's Address 456 Mark Nottingham 458 Email: mnot@mnot.net 459 URI: https://www.mnot.net/