idnits 2.17.1 draft-iab-for-the-users-01.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 abstract seems to contain references ([2], [3], [4], [1]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (November 18, 2019) is 1622 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Looks like a reference, but probably isn't: '1' on line 458 -- Looks like a reference, but probably isn't: '2' on line 460 -- Looks like a reference, but probably isn't: '3' on line 462 -- Looks like a reference, but probably isn't: '4' on line 464 -- Obsolete informational reference (is this intentional?): RFC 7230 (Obsoleted by RFC 9110, RFC 9112) Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 6 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 November 18, 2019 4 Intended status: Informational 5 Expires: May 21, 2020 7 The Internet is for End Users 8 draft-iab-for-the-users-01 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/issuess [1]. 20 The most recent (often, unpublished) draft is at 21 https://intarchboard.github.io/for-the-users/ [2]. 23 Recent changes are listed at https://github.com/intarchboard/for-the- 24 users/commits/master [3]. 26 See also the draft's current status in the IETF datatracker, at 27 https://datatracker.ietf.org/doc/draft-iab-for-the-users/ [4]. 29 Status of This Memo 31 This Internet-Draft is submitted in full conformance with the 32 provisions of BCP 78 and BCP 79. 34 Internet-Drafts are working documents of the Internet Engineering 35 Task Force (IETF). Note that other groups may also distribute 36 working documents as Internet-Drafts. The list of current Internet- 37 Drafts is at https://datatracker.ietf.org/drafts/current/. 39 Internet-Drafts are draft documents valid for a maximum of six months 40 and may be updated, replaced, or obsoleted by other documents at any 41 time. It is inappropriate to use Internet-Drafts as reference 42 material or to cite them other than as "work in progress." 44 This Internet-Draft will expire on May 21, 2020. 46 Copyright Notice 48 Copyright (c) 2019 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents 53 (https://trustee.ietf.org/license-info) in effect on the date of 54 publication of this document. Please review these documents 55 carefully, as they describe your rights and restrictions with respect 56 to this document. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 61 2. What Are "End Users"? . . . . . . . . . . . . . . . . . . . . 3 62 3. Why The IETF Should Prioritise End Users . . . . . . . . . . 4 63 4. How The IETF Can Prioritise End Users . . . . . . . . . . . . 5 64 4.1. Engaging the Internet Community . . . . . . . . . . . . . 5 65 4.2. Creating User-Focused Systems . . . . . . . . . . . . . . 7 66 4.3. Designing for Positive User Outcomes . . . . . . . . . . 7 67 4.4. Identifying Negative End User Impact . . . . . . . . . . 8 68 4.5. Handling Conflicting End User Needs . . . . . . . . . . . 8 69 4.6. Deprioritising Internal Needs . . . . . . . . . . . . . . 9 70 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 71 6. Security Considerations . . . . . . . . . . . . . . . . . . . 9 72 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 73 7.1. Informative References . . . . . . . . . . . . . . . . . 9 74 7.2. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 10 75 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 10 76 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 11 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 The IETF has focused on user needs since [RFC0001], which stated that 160 "One of our goals must be to stimulate the immediate and easy use by 161 a wide class of users." 163 And, while we specialise in technical matters, the IETF is not 164 neutral about the purpose of its work in developing the Internet; in 165 "A Mission Statement for the IETF" [RFC3935], the definitions 166 include: 168 The IETF community wants the Internet to succeed because we 169 believe that the existence of the Internet, and its influence on 170 economics, communication, and education, will help us to build a 171 better human society. 173 Later in Section 2.1, "The Scope of the Internet" it says: 175 The Internet isn't value-neutral, and neither is the IETF. We 176 want the Internet to be useful for communities that share our 177 commitment to openness and fairness. We embrace technical 178 concepts such as decentralized control, edge-user empowerment and 179 sharing of resources, because those concepts resonate with the 180 core values of the IETF community. These concepts have little to 181 do with the technology that's possible, and much to do with the 182 technology that we choose to create. 184 In other words, the IETF is concerned with developing and maintaining 185 the Internet to promote the social good, and the society that the 186 IETF is attempting to improve is composed of end users, along with 187 groups of them forming businesses, governments, clubs, civil society 188 organizations, and other institutions. 190 Merely advancing the measurable success of the Internet (e.g., 191 deployment size, bandwidth, latency, number of users) is not an 192 adequate goal; doing so ignores how technology is so often used as a 193 lever to assert power over users, rather than empower them. 195 Beyond fulfilling the IETF's mission, prioritising end users also 196 helps to ensure the long-term health of the Internet and the IETF's 197 relevance to it. Perceptions of capture by vendors or other entities 198 harm both; the IETF's work will (deservedly) lose end users' trust if 199 it prioritises (or is perceived to prioritise) others' interests over 200 them. 202 Ultimately, the Internet will succeed or fail based upon the actions 203 of its users, because they are the driving force behind its growth to 204 date. Not prioritising them jeopardizes the network effect which the 205 Internet relies upon to provide so much value. 207 4. How The IETF Can Prioritise End Users 209 There are a few ways that the IAB believes the IETF community can 210 prioritise end users, based upon our observations. By its nature, 211 this is not a complete list. 213 4.1. Engaging the Internet Community 215 The IETF community does not have any unique insight into what is 216 "good for end users," and it is not uncommon for us to be at a 217 further disadvantage because of our close understanding of some - but 218 not all - aspects of the Internet. 220 At the same time, we do have a culture of considerable deference to a 221 broader "Internet community" in our decision-making processes. Mere 222 deference, however, is not adequate; even with the best intentions, 223 we cannot assume that our experiences of the Internet are those of 224 all of its end users, or that our decisions have a positive impact 225 upon them. 227 Therefore, we have not only a responsibility to analyse and consider 228 the impacts of the IETF's work, but also a responsibility to consult 229 with that greater Internet community. We should enter into a 230 dialogue about not only the technical concerns that are well- 231 represented in the IETF but also the political, social and economic 232 concerns that it engenders, and that are better represented 233 elsewhere. 235 The IETF community faces significant hurdles in doing so. Our work 236 is specialised and often esoteric, and standard processes often occur 237 on very long timescales. Affected parties are rarely technical 238 experts, and their experience of the Internet is often based upon 239 incomplete (and sometimes inaccurate) models. Often, even when we 240 try to engage a broader audience, their participation is minimal - 241 until a change affects someone in a way they don't like. Surprising 242 the Internet community is rarely a good outcome. 244 Government representatives 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.5). 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 most 256 representative advocates for end user concerns; they should be 257 considered a primary channel for engaging the broader Internet 258 community. 260 A promising approach to help fill these gaps is to identify and 261 engage with specifically affected communities; for example, one or 262 more industry associations, user groups, or a set of individuals, 263 though we can't of course formally ensure that they are appropriately 264 representative. 266 In doing so, we should not require them to "come to us"; unless a 267 stakeholder community is already engaged in the IETF process 268 effectively, the IETF community should explore how to meet with them 269 on their terms - taking the initiative to contact them, explain our 270 work, and solicit their feedback. 272 In particular, while IAB workshops, BoFs and Bar BoFs can be an 273 effective mechanism to gather input within our community, they often 274 do not have the visibility in other communities that is required to 275 solicit input, much less effective participation. 277 Instead, an event like a workshop should be co-located - and ideally 278 hosted or co-hosted - by a forum that's familiar to that stakeholder 279 community. We should also take the opportunity to raise the 280 visibility of IETF work (or potential IETF work) in such fora through 281 conference talks, panels, newsletter articles, etc. 283 When we engage with the Internet community, we should also clearly 284 identify tailored feedback mechanisms (e.g., subscribing to a mailing 285 list may not be appropriate), and assure that they are well-known in 286 those communities. 288 Finally, we should remember that the RFC series are Requests For 289 Comments; if there are serious implications of our work, we should 290 document them and ask for feedback from the Internet Community. 292 4.2. Creating User-Focused Systems 294 We should pay particular attention to the kinds of architectures we 295 create, and whether they encourage or discourage an Internet that 296 works for end users. 298 For example, one of the most successful Internet applications is the 299 Web. One of its key implementation roles is that of the Web browser - 300 called the User Agent in [RFC7230] and other specifications. Because 301 there is more than one implementation of the standards that specify a 302 Web browser, there is a natural competition between them to do 303 carefully consider the user's needs as an agent. As a result, Web 304 browsers' interests are better aligned with those of their users, 305 creating an ecosystem that is positively user-focused. 307 In contrast, the Internet of Things (IoT) has not yet seen the 308 emergence of a natural role for representing the needs of the end 309 user. Perhaps as a result of this, that ecosystem and its users face 310 serious challenges. 312 We should also create explicit roles for users in our protocols where 313 appropriate, and respect them. 315 4.3. Designing for Positive User Outcomes 317 The Internet's users are heterogeneous; they have different access 318 characteristics (latency, available bandwidth, reliability), contexts 319 (economic, social, and political), and different characteristics 320 (languages spoken and read, cognitive and physical abilities). 322 The issues involved in serving them well are often not singular in 323 nature; they often require multiple solutions. While the network 324 effects of a single solution might be significant, this should not 325 stop us from meeting user needs with multiple solutions if they are 326 necessary. 328 However, this is not a reason to introduce alternative mechanisms 329 that are harmful; see Section 4.5. 331 4.4. Identifying Negative End User Impact 333 At its best, our work will unambiguously promote the collective 334 social good. In some cases, we will consciously decide to be neutral 335 and open-ended, allowing the "tussle" among stakeholders to produce a 336 range of results (see [TUSSLE] for further discussion). 338 At the very least, however, we must examine our work for negative 339 impact on end users, and take steps to mitigate it where encountered. 340 In particular, when we've identified a conflict between the interests 341 of end users and other stakeholders, we should err on the side of 342 protecting end users. 344 Note that "negative impact on end users" is not defined in this 345 document; that is something that the relevant body (e.g., Working 346 Group) needs to discuss and come to consensus on. Merely asserting 347 that something is harmful is not adequate. The converse is also 348 true, though; it's not permissible to avoid identifying harms, nor is 349 it acceptable to ignore them when brought to our attention. 351 The IAB and IETF have already established a body of guidance for 352 situations where this sort of conflict is common, including (but not 353 limited to) [RFC7754] on filtering, [RFC7258] and [RFC7624] on 354 pervasive surveillance, [RFC7288] on host firewalls, and [RFC6973] 355 regarding privacy considerations. 357 Much of that advice has focused on maintaining the end-to-end 358 properties of a connection [RFC3724]. This does not mean that our 359 responsibility to users stops there; decisions might affect users in 360 other ways. For example, data collection by various applications 361 even inside otherwise secure connections is a major problem on the 362 Internet today. Also, inappropriate concentration of power on the 363 Internet has become a concerning phenomenon - one that protocol 364 design might have some influence upon. 366 4.5. Handling Conflicting End User Needs 368 When the needs of different end users conflict (for example, two sets 369 of end users both have reasonable desires) we again should try to 370 minimise negative impact. 372 For example, when a decision improves the Internet for end users in 373 one jurisdiction, but at the cost of potential harm to others 374 elsewhere, that is not a good tradeoff. As such, we effectively 375 design the Internet for the pessimal environment; if a user can be 376 harmed, they probably will be, somewhere. 378 There may be cases where genuine technical need requires compromise. 379 However, such tradeoffs are carefully examined and avoided when there 380 are alternate means of achieving the desired goals. If they cannot 381 be, these choices and reasoning ought to be thoroughly documented. 383 4.6. Deprioritising Internal Needs 385 There are a number of needs that are very visible to us as 386 specification authors, but should explicitly not be prioritised over 387 the needs of end users. 389 These include: convenience for document editors, IETF process 390 matters, and "architectural purity". 392 5. IANA Considerations 394 This document does not require action by IANA. 396 6. Security Considerations 398 This document does not have any direct security impact; however, 399 failing to prioritise end users might well affect their security 400 negatively in the long term. 402 7. References 404 7.1. Informative References 406 [RFC0001] Crocker, S., "Host Software", RFC 1, DOI 10.17487/RFC0001, 407 April 1969, . 409 [RFC3724] Kempf, J., Ed., Austein, R., Ed., and IAB, "The Rise of 410 the Middle and the Future of End-to-End: Reflections on 411 the Evolution of the Internet Architecture", RFC 3724, 412 DOI 10.17487/RFC3724, March 2004, 413 . 415 [RFC3935] Alvestrand, H., "A Mission Statement for the IETF", 416 BCP 95, RFC 3935, DOI 10.17487/RFC3935, October 2004, 417 . 419 [RFC6973] Cooper, A., Tschofenig, H., Aboba, B., Peterson, J., 420 Morris, J., Hansen, M., and R. Smith, "Privacy 421 Considerations for Internet Protocols", RFC 6973, 422 DOI 10.17487/RFC6973, July 2013, 423 . 425 [RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 426 Protocol (HTTP/1.1): Message Syntax and Routing", 427 RFC 7230, DOI 10.17487/RFC7230, June 2014, 428 . 430 [RFC7258] Farrell, S. and H. Tschofenig, "Pervasive Monitoring Is an 431 Attack", BCP 188, RFC 7258, DOI 10.17487/RFC7258, May 432 2014, . 434 [RFC7288] Thaler, D., "Reflections on Host Firewalls", RFC 7288, 435 DOI 10.17487/RFC7288, June 2014, 436 . 438 [RFC7624] Barnes, R., Schneier, B., Jennings, C., Hardie, T., 439 Trammell, B., Huitema, C., and D. Borkmann, 440 "Confidentiality in the Face of Pervasive Surveillance: A 441 Threat Model and Problem Statement", RFC 7624, 442 DOI 10.17487/RFC7624, August 2015, 443 . 445 [RFC7754] Barnes, R., Cooper, A., Kolkman, O., Thaler, D., and E. 446 Nordmark, "Technical Considerations for Internet Service 447 Blocking and Filtering", RFC 7754, DOI 10.17487/RFC7754, 448 March 2016, . 450 [TUSSLE] Clark, D., Sollins, K., Wroclawski, J., and R. Braden, 451 "Tussle in Cyberspace: Defining Tomorrow's Internet", 452 2002, 453 . 456 7.2. URIs 458 [1] https://github.com/intarchboard/for-the-users/issuess 460 [2] https://intarchboard.github.io/for-the-users/ 462 [3] https://github.com/intarchboard/for-the-users/commits/master 464 [4] https://datatracker.ietf.org/doc/draft-iab-for-the-users/ 466 Appendix A. Acknowledgements 468 This document was influenced by many discussions, both inside and 469 outside of the IETF and IAB. In particular, Edward Snowden's 470 comments regarding the priority of end users at IETF 93 and the HTML5 471 Priority of Constituencies were both influential. 473 Thanks to Sandra Braman for her insightful overview of the RFC series 474 from a legal perspective. 476 Many people gave feedback and input, including Harald Alvestrand, 477 Mohamed Boucadair, Stephen Farrell, Joe Hildebrand, Lee Howard, Russ 478 Housley, Niels ten Oever, Mando Rachovitsa, Martin Thomson, Brian 479 Trammell, John Klensin, Eliot Lear, Ted Hardie, and Jari Arkko. 481 Author's Address 483 Mark Nottingham 485 Email: mnot@mnot.net 486 URI: https://www.mnot.net/