idnits 2.17.1 draft-nottingham-for-the-users-09.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 (July 22, 2019) is 1739 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Looks like a reference, but probably isn't: '1' on line 325 -- Looks like a reference, but probably isn't: '2' on line 327 -- Looks like a reference, but probably isn't: '3' on line 329 -- Looks like a reference, but probably isn't: '4' on line 331 Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group M. Nottingham 3 Internet-Draft July 22, 2019 4 Intended status: Informational 5 Expires: January 23, 2020 7 The Internet is for End Users 8 draft-nottingham-for-the-users-09 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/mnot/I-D/labels/for-the-users [1]. 20 The most recent (often, unpublished) draft is at 21 https://mnot.github.io/I-D/for-the-users/ [2]. 23 Recent changes are listed at https://github.com/mnot/I-D/commits/gh- 24 pages/for-the-users [3]. 26 See also the draft's current status in the IETF datatracker, at 27 https://datatracker.ietf.org/doc/draft-nottingham-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 January 23, 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 End Users Should Be Prioritised . . . . . . . . . . . . . 4 63 4. How End Users are Prioritised . . . . . . . . . . . . . . . . 5 64 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 65 6. Security Considerations . . . . . . . . . . . . . . . . . . . 6 66 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 67 7.1. Informative References . . . . . . . . . . . . . . . . . 7 68 7.2. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 7 69 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 8 70 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 8 72 1. Introduction 74 Many who participate in the IETF are most comfortable making what we 75 believe to be purely technical decisions; our process is defined to 76 favor technical merit, through our well-known mantra of "rough 77 consensus and running code." 79 Nevertheless, the running code that results from our process (when 80 things work well) inevitably has an impact beyond technical 81 considerations, because the underlying decisions afford some uses 82 while discouraging others; while we believe we are making purely 83 technical decisions, in reality, we are defining what is possible on 84 the Internet itself. 86 This impact has become significant. As the Internet increasingly 87 mediates essential functions in societies, it has unavoidably become 88 profoundly political; it has helped people overthrow governments and 89 revolutionize social orders, control populations, collect data about 90 individuals, and reveal secrets. It has created wealth for some 91 individuals and companies while destroying others'. 93 All of this raises the question: Who do we go through the pain of 94 gathering rough consensus and writing running code for? 96 After all, there are a variety of identifiable parties in the broader 97 Internet community that standards can provide benefit to, such as 98 (but not limited to) end users, network operators, schools, equipment 99 vendors, specification authors, specification implementers, content 100 owners, governments, non-governmental organisations, social 101 movements, employers, and parents. 103 Successful specifications will provide some benefit to all of the 104 relevant parties because standards do not represent a zero-sum game. 105 However, there are sometimes situations where there is a need to 106 balance the benefits of a decision between two (or more) parties. 108 In these situations, when one of those parties is an "end user" of 109 the Internet - for example, a person using a Web browser, mail 110 client, or another agent that connects to the Internet - the Internet 111 Architecture Board argues that the IETF should protect their 112 interests over those of parties. 114 Section 2 explains what is meant by "end users"; Section 3 outlines 115 why they should be prioritised in IETF work, and Section 4 describes 116 how that can be done. 118 2. What Are "End Users"? 120 In this document, "end users," means non-technical users whose 121 activities IETF protocols are designed to support, sometimes 122 indirectly. Thus, the end user of a protocol to manage routers is 123 not a router administrator; it is the people using the network that 124 the router operates within. 126 End users are not necessarily a homogenous group; they might have 127 different views of how the Internet should work (from their 128 viewpoint) and might occupy several roles, such as a seller, buyer, 129 publisher, reader, service provider and consumer. An end user might 130 be browsing the Web, monitoring remote equipment, playing a game, 131 video conferencing with colleagues, sending messages to friends, or 132 performing an operation in a remote surgery theatre. 134 Likewise, an individual end user might have many interests (e.g., 135 privacy, security, flexibility, reachability) that are sometimes in 136 tension. 138 A person whose interests we need to consider might not directly be 139 using a specific system connected to the Internet. For example, if a 140 child is using a browser, the interests of that child's parents or 141 guardians may be relevant; if a person is pictured in a photograph, 142 that person may have an interest in systems that process that 143 photograph, or if a person entering a room triggers sensors that send 144 data to the Internet than that person's interests may be involved in 145 our deliberations about how those sensor readings are handled. 147 While such less-direct interactions between people and the Internet 148 may be harder to evaluate, such people are nonetheless included in 149 this document's concept of end-user. 151 3. Why End Users Should Be Prioritised 153 While focused on technical matters, the IETF is not neutral about the 154 purpose of its work in developing the Internet; in "A Mission 155 Statement for the IETF" [RFC3935], the definitions include: 157 The IETF community wants the Internet to succeed because we 158 believe that the existence of the Internet, and its influence on 159 economics, communication, and education, will help us to build a 160 better human society. 162 and later in Section 2.1, "The Scope of the Internet" it says: 164 The Internet isn't value-neutral, and neither is the IETF. We 165 want the Internet to be useful for communities that share our 166 commitment to openness and fairness. We embrace technical 167 concepts such as decentralized control, edge-user empowerment and 168 sharing of resources, because those concepts resonate with the 169 core values of the IETF community. These concepts have little to 170 do with the technology that's possible, and much to do with the 171 technology that we choose to create. 173 In other words, the IETF is concerned with developing and maintaining 174 the Internet to promote the social good, and the society that the 175 IETF is attempting to improve is composed of end users, along with 176 groups of them forming businesses, governments, clubs, civil society 177 organizations, and other institutions. 179 Merely advancing the measurable success of the Internet (e.g., 180 deployment size, bandwidth, latency, number of users) is not 181 adequate; doing so ignores how technology so often used as a lever to 182 assert power over users, rather than empower them. 184 Beyond fulfilling the IETF's mission, prioritising end users also 185 helps to ensure the long-term health of the Internet. Many aspects 186 of the Internet are user-focused, and it will (deservedly) lose their 187 trust if prioritises others' interests. Because one of the primary 188 mechanisms of the Internet is the "network effect", such trust is 189 crucial to maintain; the Internet itself depends upon it. 191 4. How End Users are Prioritised 193 The IETF community does not have any unique insight into what is 194 "good for end users." To inform its decisions, it has a 195 responsibility to analyse and consider the impacts of its work, as 196 well as, where needed, interact with the greater Internet community, 197 soliciting input from others and considering the issues raised. 199 End users are typically not technical experts; their experience of 200 the Internet is often based upon inadequate models of its properties, 201 operation, and administration. Therefore, the IETF should primarily 202 engage with those who understand how changes to it will affect end 203 users; in particular civil society organisations, as well as 204 governments, businesses and other groups representing some aspect of 205 end-user interests. 207 The IAB encourages the IETF to explicitly consider user impacts and 208 points of view in any IETF work. The IAB also encourages the IETF to 209 engage with the above parties on terms that suit them; it is not 210 reasonable to require them to understand the mores and peculiarities 211 of the IETF community - even though we encourage them to participate 212 in it. 214 That means, when appropriate, the technical community should take the 215 initiative to contact these communities and explain our work, solicit 216 their feedback, and encourage their participation. In cases where it 217 is not reasonable for a stakeholder community to engage in the IETF 218 process, the technical community should meet with them. IAB 219 workshops can serve this purpose and the IAB encourages suggestions 220 for topics where this would be of benefit. 222 At our best, this will result in work that promotes the social good. 223 In some cases, we will consciously decide to be neutral and open- 224 ended, allowing the "tussle" among stakeholders to produce a range of 225 results (see [TUSSLE] for further discussion). 227 At the very least, however, we must examine our work for impact on 228 end users, and take positive steps to avoid it where we see it. In 229 particular, when we've identified a conflict between the interests of 230 end users and another stakeholder, we should err on the side of 231 finding a solution that avoids harmful consequences to end users. 233 Note that "harmful" is not defined in this document; that is 234 something that the relevant body (e.g., Working Group) needs to 235 discuss. Furthermore, harm to end users is judged just like any 236 other decision in the IETF, with consensus gathering and the normal 237 appeals process; merely asserting that something is harmful is not 238 adequate. The converse is also true, though; it's not permissible to 239 avoid identifying harms, nor is it acceptable to ignore them when 240 brought to us. 242 The IETF has already established a body of guidance for situations 243 where this sort of conflict is common, including (but not limited to) 244 [RFC7754] on filtering, [RFC7258] and [RFC7624] on pervasive 245 surveillance, [RFC7288] on host firewalls, and [RFC6973] regarding 246 privacy considerations. When specific advice is not yet available, 247 we try to find a different solution or another way to frame the 248 problem, distilling the underlying principles into more general 249 advice where appropriate. 251 Much of that advice has focused on maintaining the end-to-end 252 security properties of a connection. This does not mean that our 253 responsibility to users stops there; protocol decisions might affect 254 users in other ways. For example, data collection by various 255 applications even inside otherwise secure connections is a major 256 problem in the Internet today. Also, inappropriate concentration of 257 power on the Internet has become a concerning phenomenon - one that 258 protocol design might have some influence upon. 260 When the needs of different end users conflict (for example, two sets 261 of end users both have reasonable desires) we again should try to 262 minimise harm. For example, when a decision improves the Internet 263 for end users in one jurisdiction, but at the cost of potential harm 264 to others elsewhere, that is not a good tradeoff. As such, we 265 effectively design the Internet for the pessimal environment; if a 266 user can be harmed, they probably will be. 268 There may be cases where genuine technical need requires compromise. 269 However, such tradeoffs are carefully examined and avoided when there 270 are alternate means of achieving the desired goals. If they cannot 271 be, these choices and reasoning ought to be thoroughly documented. 273 5. IANA Considerations 275 This document does not require action by IANA. 277 6. Security Considerations 279 This document does not have any direct security impact; however, 280 failing to prioritise end users might well affect their security 281 negatively in the long term. 283 7. References 285 7.1. Informative References 287 [RFC3935] Alvestrand, H., "A Mission Statement for the IETF", 288 BCP 95, RFC 3935, DOI 10.17487/RFC3935, October 2004, 289 . 291 [RFC6973] Cooper, A., Tschofenig, H., Aboba, B., Peterson, J., 292 Morris, J., Hansen, M., and R. Smith, "Privacy 293 Considerations for Internet Protocols", RFC 6973, 294 DOI 10.17487/RFC6973, July 2013, 295 . 297 [RFC7258] Farrell, S. and H. Tschofenig, "Pervasive Monitoring Is an 298 Attack", BCP 188, RFC 7258, DOI 10.17487/RFC7258, May 299 2014, . 301 [RFC7288] Thaler, D., "Reflections on Host Firewalls", RFC 7288, 302 DOI 10.17487/RFC7288, June 2014, 303 . 305 [RFC7624] Barnes, R., Schneier, B., Jennings, C., Hardie, T., 306 Trammell, B., Huitema, C., and D. Borkmann, 307 "Confidentiality in the Face of Pervasive Surveillance: A 308 Threat Model and Problem Statement", RFC 7624, 309 DOI 10.17487/RFC7624, August 2015, 310 . 312 [RFC7754] Barnes, R., Cooper, A., Kolkman, O., Thaler, D., and E. 313 Nordmark, "Technical Considerations for Internet Service 314 Blocking and Filtering", RFC 7754, DOI 10.17487/RFC7754, 315 March 2016, . 317 [TUSSLE] Clark, D., Sollins, K., Wroclawski, J., and R. Braden, 318 "Tussle in Cyberspace: Defining Tomorrow's Internet", 319 2002, 320 . 323 7.2. URIs 325 [1] https://github.com/mnot/I-D/labels/for-the-users 327 [2] https://mnot.github.io/I-D/for-the-users/ 329 [3] https://github.com/mnot/I-D/commits/gh-pages/for-the-users 331 [4] https://datatracker.ietf.org/doc/draft-nottingham-for-the-users/ 333 Appendix A. Acknowledgements 335 This document was influenced by many discussions, both inside and 336 outside of the IETF and IAB. In particular, Edward Snowden's 337 comments regarding the priority of end users at IETF 93 and the 338 WHATWG's Priority of Constituencies for HTML were both influential. 340 Many people gave feedback and input, including Harald Alvestrand, 341 Mohamed Boucadair, Stephen Farrell, Joe Hildebrand, Lee Howard, Russ 342 Housley, Niels ten Oever, Mando Rachovitsa, Martin Thomson, Brian 343 Trammell, John Klensin, Eliot Lear, Ted Hardie, and Jari Arkko. 345 Author's Address 347 Mark Nottingham 349 Email: mnot@mnot.net 350 URI: https://www.mnot.net/