idnits 2.17.1 draft-nottingham-for-the-users-07.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 (March 14, 2019) is 1867 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Looks like a reference, but probably isn't: '1' on line 340 -- Looks like a reference, but probably isn't: '2' on line 342 -- Looks like a reference, but probably isn't: '3' on line 344 -- Looks like a reference, but probably isn't: '4' on line 346 -- Obsolete informational reference (is this intentional?): RFC 4941 (Obsoleted by RFC 8981) -- Obsolete informational reference (is this intentional?): RFC 7231 (Obsoleted by RFC 9110) Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group M. Nottingham 3 Internet-Draft March 14, 2019 4 Intended status: Informational 5 Expires: September 15, 2019 7 The Internet is for End Users 8 draft-nottingham-for-the-users-07 10 Abstract 12 This document explains why, when a conflict cannot be avoided, the 13 IETF considers end users as its highest priority concern. 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 September 15, 2019. 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. Code Components extracted from this document must 57 include Simplified BSD License text as described in Section 4.e of 58 the Trust Legal Provisions and are provided without warranty as 59 described in the Simplified BSD License. 61 Table of Contents 63 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 64 2. What Are "End Users"? . . . . . . . . . . . . . . . . . . . . 4 65 3. Why End Users are Prioritised . . . . . . . . . . . . . . . . 5 66 4. How End Users are Prioritised . . . . . . . . . . . . . . . . 5 67 4.1. Examples . . . . . . . . . . . . . . . . . . . . . . . . 6 68 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 69 6. Security Considerations . . . . . . . . . . . . . . . . . . . 6 70 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 71 7.1. Informative References . . . . . . . . . . . . . . . . . 7 72 7.2. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 8 73 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 8 74 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 8 76 1. Introduction 78 The IETF, while focused on technical matters, is not neutral about 79 the purpose of its work in developing the Internet; in "A Mission 80 Statement for the IETF" [RFC3935], the definitions include: 82 The IETF community wants the Internet to succeed because we 83 believe that the existence of the Internet, and its influence on 84 economics, communication, and education, will help us to build a 85 better human society. 87 and later in Section 2.1, "The Scope of the Internet" it says: 89 The Internet isn't value-neutral, and neither is the IETF. We 90 want the Internet to be useful for communities that share our 91 commitment to openness and fairness. We embrace technical 92 concepts such as decentralized control, edge-user empowerment and 93 sharing of resources, because those concepts resonate with the 94 core values of the IETF community. These concepts have little to 95 do with the technology that's possible, and much to do with the 96 technology that we choose to create. 98 However, many in the IETF are most comfortable making what we believe 99 to be purely technical decisions; our process is defined to favor 100 technical merit, through our well-known bias towards "rough consensus 101 and running code". 103 Nevertheless, the running code that results from our process (when 104 things work well) inevitably has an impact beyond technical 105 considerations, because the underlying decisions afford some uses 106 while discouraging others; while we believe we are making purely 107 technical decisions, in reality that may not be possible. Or, in the 108 words of Lawrence Lessig [CODELAW]: 110 Ours is the age of cyberspace. It, too, has a regulator... This 111 regulator is code -- the software and hardware that make 112 cyberspace as it is. This code, or architecture, sets the terms 113 on which life in cyberspace is experienced. It determines how 114 easy it is to protect privacy, or how easy it is to censor speech. 115 It determines whether access to information is general or whether 116 information is zoned. It affects who sees what, or what is 117 monitored. In a host of ways that one cannot begin to see unless 118 one begins to understand the nature of this code, the code of 119 cyberspace regulates. 121 This impact has become significant. As the Internet increasingly 122 mediates key functions in societies, it has unavoidably become 123 profoundly political; it has helped people overthrow governments and 124 revolutionize social orders, control populations and reveal secrets. 125 It has created wealth for some individuals and companies, while 126 destroying others'. 128 All of this raises the question: For whom do we go through the pain 129 of gathering rough consensus and writing running code? 131 There are a variety of identifiable parties in the larger Internet 132 community that standards can provide benefit to, such as (but not 133 limited to) end users, network operators, schools, equipment vendors, 134 specification authors, specification implementers, content owners, 135 governments, non-governmental organisations, social movements, 136 employers, and parents. 138 Successful specifications will provide some benefit to all of the 139 relevant parties, because standards do not represent a zero-sum game. 140 However, there are sometimes situations where there is a need to 141 balance the benefits of a decision between two (or more) parties. 143 In these situations, when one of those parties is an "end user" of 144 the Internet - for example, a person using a Web browser, mail 145 client, or other agent that connects to the Internet - the IETF tends 146 to protect their interests over those of parties such as network 147 operators or equipement vendors. 149 This document explains what is meant by "end users" in Section 2, why 150 they tend to be prioritised in IETF work in Section 3, and how that 151 is done in Section 4. 153 2. What Are "End Users"? 155 In this document, "end users," means non-technical users whose 156 activities IETF protocols are designed to support, sometimes 157 indirectly. Thus, the end user of a protocol to manage routers is 158 not a router administrator; it is the people using the network that 159 the router operates within. 161 An end user could be an individual, or it could be a collection of 162 them; whether that be a social movement, a business, or a government 163 that represents a large number of people. 165 That said, end users are not necessarily a homogenous group; often, 166 but not always, interactions on the Internet are characterised by a 167 seller/buyer, publisher/reader, or service provider/consumer 168 relationship. 170 Also, it's important to note that even though we use the term "user" 171 here, this does not necessarily denote a passive relationship with 172 the Internet; someone producing content, selling goods or providing a 173 service is equally a user of the Internet. The emphasis here is on 174 "end" - as in endpoint [RFC3724]. 176 Similarly, a person whose interests we need to consider might not 177 directly be an end-user of a specific system connected to the 178 Internet. For example, if a child is using a browser, the interests 179 of that child's parents or guardians may be relevant; if a person is 180 pictured in a photograph, that person may have an interest in systems 181 that process that photograph, or if a person entering a room triggers 182 sensors that send data to the Internet than that person's interests 183 may be involved in our deliberations about how those sensor readings 184 are handled. 186 While such less-direct interactions between people and the Internet 187 may be harder to evaluate compared to those involving people with 188 accounts on some web service, such people are nonetheless included in 189 this document's concept of end-user. 191 3. Why End Users are Prioritised 193 While networks need to be managed, employers and equipment vendors 194 need to meet business goals, and so on, the IETF's mission is to 195 "build a better human society" [RFC3935] and - on the Internet - 196 society is composed of end users, along with groups of them forming 197 business, governments, clubs, civil society organizations, and other 198 institutions that influence it. 200 Prioritising end users helps the IETF achieve its mission, and also 201 helps to assure the long-term health of the Internet. By 202 prioritising their concerns, we assure that the Internet reaches the 203 greatest number of people, thereby delivering greater utility by 204 maximising its network effect. 206 Prioritising end users' needs also helps to assure that the Internet 207 itself retains end users' trust, preserving the benefit its network 208 effect brings. 210 4. How End Users are Prioritised 212 The IETF community does not have any specific insight into what is 213 "good for end users"; to help make decisions involving them, it 214 interacts with the greater Internet community. Because end users are 215 typically not technical experts, the IETF has a responsibility to 216 consider their interests, and engages with those who understand how 217 IETF work will affect end users, such as civil society organisations, 218 as well as governments, businesses and other groups representing some 219 aspect of end user interests. 221 When we've identified a conflict between the interests of end users 222 and another stakeholder (e.g., a network operator), and need a 223 "tiebreaker", we should err on the side of finding a solution that 224 doesn't harm end users. 226 Note that "harm" is not defined in this document; that is something 227 that the relevant body (e.g., Working Group) needs to discuss. 229 The IETF has already established a body of guidance for situations 230 where this sort of conflict is common, including (but not limited to) 231 [RFC7754] on filtering, [RFC7258] and [RFC7624] on pervasive 232 surveillance, [RFC7288] on host firewalls, and [RFC6973] regarding 233 privacy considerations. 235 When such advice is not yet available, we try to find a different 236 solution, or another way to frame the problem, distilling the 237 underlying principles into more general advice where appropriate. 239 When the needs of different end users conflict; for example, between 240 governments and individuals, we again try to minimise harm - this 241 time, to the greatest number and most specific of end users. In 242 other words, when a decision improves the Internet for end users in 243 one jurisdiction, but at the cost of potential harm to others 244 elsewhere, that is not a good tradeoff. 246 There may be cases where genuine technical need requires compromise. 247 However, such tradeoffs are carefully examined, and avoided when 248 there are alternate means of achieving the desired goals. If they 249 cannot be, these choices and reasoning ought to be carefully 250 documented. 252 4.1. Examples 254 o IPv6 [RFC8200] can be used to assign a client with a unique 255 address prefix - even though this provides a way to track end user 256 activity and helps identify them - because it is technically 257 necessary to provide networking (and despite this, there are 258 mechanisms like [RFC4941] to mitigate this effect, for those users 259 who desire it). 261 o Different network operator communities have, from time to time, 262 asked for a mechanism that would allow them to insert themselves 263 into HTTPS [RFC7231] connections to interpose caching and other 264 performance optimisations. This was rejected for a number of 265 reasons, including that end users' conception of HTTPS as an 266 encrypted end-to-end protocol had already formed, so that changing 267 it would harm user security. 269 TODO: more examples. 271 5. IANA Considerations 273 This document does not require action by IANA. 275 6. Security Considerations 277 This document does not have direct security impact; however, failing 278 to prioritise end users might well affect their security negatively 279 in the long term. 281 7. References 282 7.1. Informative References 284 [CODELAW] Lessig, L., "Code Is Law: On Liberty in Cyberspace", 2000, 285 . 287 [RFC3724] Kempf, J., Ed., Austein, R., Ed., and IAB, "The Rise of 288 the Middle and the Future of End-to-End: Reflections on 289 the Evolution of the Internet Architecture", RFC 3724, 290 DOI 10.17487/RFC3724, March 2004, 291 . 293 [RFC3935] Alvestrand, H., "A Mission Statement for the IETF", 294 BCP 95, RFC 3935, DOI 10.17487/RFC3935, October 2004, 295 . 297 [RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy 298 Extensions for Stateless Address Autoconfiguration in 299 IPv6", RFC 4941, DOI 10.17487/RFC4941, September 2007, 300 . 302 [RFC6973] Cooper, A., Tschofenig, H., Aboba, B., Peterson, J., 303 Morris, J., Hansen, M., and R. Smith, "Privacy 304 Considerations for Internet Protocols", RFC 6973, 305 DOI 10.17487/RFC6973, July 2013, 306 . 308 [RFC7231] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 309 Protocol (HTTP/1.1): Semantics and Content", RFC 7231, 310 DOI 10.17487/RFC7231, June 2014, 311 . 313 [RFC7258] Farrell, S. and H. Tschofenig, "Pervasive Monitoring Is an 314 Attack", BCP 188, RFC 7258, DOI 10.17487/RFC7258, May 315 2014, . 317 [RFC7288] Thaler, D., "Reflections on Host Firewalls", RFC 7288, 318 DOI 10.17487/RFC7288, June 2014, 319 . 321 [RFC7624] Barnes, R., Schneier, B., Jennings, C., Hardie, T., 322 Trammell, B., Huitema, C., and D. Borkmann, 323 "Confidentiality in the Face of Pervasive Surveillance: A 324 Threat Model and Problem Statement", RFC 7624, 325 DOI 10.17487/RFC7624, August 2015, 326 . 328 [RFC7754] Barnes, R., Cooper, A., Kolkman, O., Thaler, D., and E. 329 Nordmark, "Technical Considerations for Internet Service 330 Blocking and Filtering", RFC 7754, DOI 10.17487/RFC7754, 331 March 2016, . 333 [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 334 (IPv6) Specification", STD 86, RFC 8200, 335 DOI 10.17487/RFC8200, July 2017, 336 . 338 7.2. URIs 340 [1] https://github.com/mnot/I-D/labels/for-the-users 342 [2] https://mnot.github.io/I-D/for-the-users/ 344 [3] https://github.com/mnot/I-D/commits/gh-pages/for-the-users 346 [4] https://datatracker.ietf.org/doc/draft-nottingham-for-the-users/ 348 Appendix A. Acknowledgements 350 Thanks to Edward Snowden for his comments regarding the priority of 351 end users at IETF93. 353 Thanks to the WHATWG for blazing the trail with the Priority of 354 Constituencies. 356 Thanks to Harald Alvestrand for his substantial feedback and Mohamed 357 Boucadair, Stephen Farrell, Joe Hildebrand, Lee Howard, Russ Housley, 358 Niels ten Oever, Mando Rachovitsa, Martin Thomson, and Brian Trammell 359 for their suggestions. 361 Author's Address 363 Mark Nottingham 365 Email: mnot@mnot.net 366 URI: https://www.mnot.net/