idnits 2.17.1 draft-nottingham-for-the-users-06.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 (February 23, 2018) is 2254 days in the past. Is this intentional? Checking references for intended status: Best Current Practice ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Looks like a reference, but probably isn't: '1' on line 296 -- Looks like a reference, but probably isn't: '2' on line 298 -- Looks like a reference, but probably isn't: '3' on line 300 -- Looks like a reference, but probably isn't: '4' on line 302 == Unused Reference: 'RFC2119' is defined on line 236, but no explicit reference was found in the text == Unused Reference: 'RFC2460' is defined on line 246, but no explicit reference was found in the text == Unused Reference: 'RFC7282' is defined on line 269, but no explicit reference was found in the text -- Obsolete informational reference (is this intentional?): RFC 2460 (Obsoleted by RFC 8200) -- Obsolete informational reference (is this intentional?): RFC 4941 (Obsoleted by RFC 8981) Summary: 1 error (**), 0 flaws (~~), 4 warnings (==), 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 February 23, 2018 4 Intended status: Best Current Practice 5 Expires: August 27, 2018 7 The Internet is for End Users 8 draft-nottingham-for-the-users-06 10 Abstract 12 This document why, when a conflict cannot be avoided, the IETF 13 considers end users as their 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 August 27, 2018. 46 Copyright Notice 48 Copyright (c) 2018 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. Guidelines for IETF Decisions . . . . . . . . . . . . . . . . 4 65 3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 66 4. Security Considerations . . . . . . . . . . . . . . . . . . . 5 67 5. References . . . . . . . . . . . . . . . . . . . . . . . . . 5 68 5.1. Normative References . . . . . . . . . . . . . . . . . . 6 69 5.2. Informative References . . . . . . . . . . . . . . . . . 6 70 5.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 7 71 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 7 72 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 7 74 1. Introduction 76 The IETF, while focused on technical matters, is not neutral about 77 the purpose of its work in developing the Internet [RFC3935]: 79 The IETF community wants the Internet to succeed because we 80 believe that the existence of the Internet, and its influence on 81 economics, communication, and education, will help us to build a 82 better human society. 84 and: 86 The Internet isn't value-neutral, and neither is the IETF. We 87 want the Internet to be useful for communities that share our 88 commitment to openness and fairness. We embrace technical 89 concepts such as decentralized control, edge-user empowerment and 90 sharing of resources, because those concepts resonate with the 91 core values of the IETF community. These concepts have little to 92 do with the technology that's possible, and much to do with the 93 technology that we choose to create. 95 However, the IETF is most comfortable making what we believe to be 96 purely technical decisions; our process is defined to favor technical 97 merit, through our well-known bias towards "rough consensus and 98 running code". 100 Nevertheless, the running code that results from our process (when 101 things work well) inevitably has an impact beyond technical 102 considerations, because the underlying decisions afford some uses 103 while discouraging others; while we believe we are making purely 104 technical decisions, in reality that may not be possible. Or, in the 105 words of Lawrence Lessig [CODELAW]: 107 Ours is the age of cyberspace. It, too, has a regulator... This 108 regulator is code -- the software and hardware that make 109 cyberspace as it is. This code, or architecture, sets the terms 110 on which life in cyberspace is experienced. It determines how 111 easy it is to protect privacy, or how easy it is to censor speech. 112 It determines whether access to information is general or whether 113 information is zoned. It affects who sees what, or what is 114 monitored. In a host of ways that one cannot begin to see unless 115 one begins to understand the nature of this code, the code of 116 cyberspace regulates. 118 This impact has become significant. As the Internet increasingly 119 mediates key functions in societies, it has unavoidably become 120 profoundly political; it has helped people overthrow governments and 121 revolutionize social orders, control populations and reveal secrets. 122 It has created wealth for some individuals and companies, while 123 destroying others'. 125 All of this raises the question: For whom do we go through the pain 126 of gathering rough consensus and writing running code? 128 There are a variety of identifiable parties in the larger Internet 129 community that standards can provide benefit to, such as (but not 130 limited to) end users, network operators, schools, equipment vendors, 131 specification authors, specification implementers, content owners, 132 governments, non-governmental organisations, social movements, 133 employers, and parents. 135 Successful specifications will provide some benefit to all of the 136 relevant parties, because standards do not represent a zero-sum game. 137 However, there are sometimes situations where we need to balance the 138 benefits of a decision between two (or more) parties. 140 In these situations, when one of those parties is the "end user" of 141 the Internet - for example, a person using a Web browser, mail 142 client, or other agent that connects to the Internet - we tend to 143 favour their needs over that of parties such as network operators or 144 equipement vendors. 146 Our goal is not to avoid all potential harm to or constraint of end 147 users; rather, it's to give guidance in a particular situation - when 148 we've identified a conflict between the interests of end users and 149 another stakeholder (e.g., a network operator), and need a 150 "tiebreaker", we should err on the side of finding a solution that 151 doesn't harm end users. 153 Note that "harm" is not defined in this document; that is something 154 that the relevant body (e.g., Working Group) needs to discuss. The 155 IETF has already established a body of guidance for such decisions, 156 including (but not limited to) [RFC7754] on filtering, [RFC7258] and 157 [RFC7624] on pervasive surveillance, [RFC7288] on host firewalls, and 158 [RFC6973] regarding privacy considerations. 160 Over time, additional guidance is likely to be defined. In the 161 absence of specific guidance on a given topic (such as that 162 referenced above), this document provides a general approach to 163 making such decisions. 165 Doing so helps the IETF achieve its mission, and also helps to assure 166 the long-term health of the Internet. By prioritising the concerns 167 of end users, we assure that it reaches the greatest number of 168 people, thereby delivering greater utility by maximising its network 169 effect. 171 Prioritising end users' needs also helps to assure that the Internet 172 itself retains end users' trust, preserving the benefit its network 173 effect brings. 175 2. Guidelines for IETF Decisions 177 When there are unresolvable conflicts between the interests of 178 different parties, we consider the end users of the Internet to have 179 priority over other parties. 181 While networks need to be managed, employers and equipment vendors 182 need to meet business goals, and so on, the IETF's mission is to 183 "build a better human society" [RFC3935] and - on the Internet - 184 society is composed of end users, along with groups of them forming 185 business, governments, clubs, civil society organizations, and other 186 institutions that influence it. 188 By "end users," we mean non-technical users whose activities our 189 protocols are designed to support. Thus, the end user of a protocol 190 to manage routers is not a router administrator; it is the people 191 using the network that the router operates within. 193 This does not mean that the IETF community has any specific insight 194 into what is "good for end users"; as always, we will need to 195 interact with the greater Internet community and apply our process to 196 help us make decisions, deploy our protocols, and ultimately 197 determine their success or failure. 199 It does means that, because end users are not technical experts, we 200 have a responsibility to consider their interests, and will need to 201 engage with those who understand how our work will affect end users, 202 such as civil society organisations, as well as governments, 203 businesses and other groups representing some aspect of end user 204 interests. 206 When a proposed solution to a problem has a benefit to some other 207 party at the identified expense of end users, we will find a 208 different solution or find another way to frame the problem. 210 There may be cases where genuine technical need requires compromise. 211 However, such tradeoffs need to be carefully examined, and avoided 212 when there are alternate means of achieving the desired goals. If 213 they cannot be, these choices and reasoning ought to be carefully 214 documented. 216 For example, IPv6 [RFC8200] can be used to assign a client with a 217 unique address prefix - even though this provides a way to track end 218 user activity and helps identify them - because it is technically 219 necessary to provide networking (and despite this, there are 220 mechanisms like [RFC4941] to mitigate this effect, for those users 221 who desire it). 223 3. IANA Considerations 225 This document does not require action by IANA. 227 4. Security Considerations 229 This document does not have direct security impact; however, failing 230 to prioritise end users might well affect their security negatively 231 in the long term. 233 5. References 234 5.1. Normative References 236 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 237 Requirement Levels", BCP 14, RFC 2119, 238 DOI 10.17487/RFC2119, March 1997, 239 . 241 5.2. Informative References 243 [CODELAW] Lessig, L., "Code Is Law: On Liberty in Cyberspace", 2000, 244 . 246 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 247 (IPv6) Specification", RFC 2460, DOI 10.17487/RFC2460, 248 December 1998, . 250 [RFC3935] Alvestrand, H., "A Mission Statement for the IETF", 251 BCP 95, RFC 3935, DOI 10.17487/RFC3935, October 2004, 252 . 254 [RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy 255 Extensions for Stateless Address Autoconfiguration in 256 IPv6", RFC 4941, DOI 10.17487/RFC4941, September 2007, 257 . 259 [RFC6973] Cooper, A., Tschofenig, H., Aboba, B., Peterson, J., 260 Morris, J., Hansen, M., and R. Smith, "Privacy 261 Considerations for Internet Protocols", RFC 6973, 262 DOI 10.17487/RFC6973, July 2013, 263 . 265 [RFC7258] Farrell, S. and H. Tschofenig, "Pervasive Monitoring Is an 266 Attack", BCP 188, RFC 7258, DOI 10.17487/RFC7258, May 267 2014, . 269 [RFC7282] Resnick, P., "On Consensus and Humming in the IETF", 270 RFC 7282, DOI 10.17487/RFC7282, June 2014, 271 . 273 [RFC7288] Thaler, D., "Reflections on Host Firewalls", RFC 7288, 274 DOI 10.17487/RFC7288, June 2014, 275 . 277 [RFC7624] Barnes, R., Schneier, B., Jennings, C., Hardie, T., 278 Trammell, B., Huitema, C., and D. Borkmann, 279 "Confidentiality in the Face of Pervasive Surveillance: A 280 Threat Model and Problem Statement", RFC 7624, 281 DOI 10.17487/RFC7624, August 2015, 282 . 284 [RFC7754] Barnes, R., Cooper, A., Kolkman, O., Thaler, D., and E. 285 Nordmark, "Technical Considerations for Internet Service 286 Blocking and Filtering", RFC 7754, DOI 10.17487/RFC7754, 287 March 2016, . 289 [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 290 (IPv6) Specification", STD 86, RFC 8200, 291 DOI 10.17487/RFC8200, July 2017, 292 . 294 5.3. URIs 296 [1] https://github.com/mnot/I-D/labels/for-the-users 298 [2] https://mnot.github.io/I-D/for-the-users/ 300 [3] https://github.com/mnot/I-D/commits/gh-pages/for-the-users 302 [4] https://datatracker.ietf.org/doc/draft-nottingham-for-the-users/ 304 Appendix A. Acknowledgements 306 Thanks to Edward Snowden for his comments regarding the priority of 307 end users at IETF93. 309 Thanks to the WHATWG for blazing the trail with the Priority of 310 Constituencies. 312 Thanks to Harald Alvestrand for his substantial feedback and Mohamed 313 Boucadair, Stephen Farrell, Joe Hildebrand, Lee Howard, Russ Housley, 314 Niels ten Oever, Mando Rachovitsa, Martin Thomson, and Brian Trammell 315 for their suggestions. 317 Author's Address 319 Mark Nottingham 321 Email: mnot@mnot.net 322 URI: https://www.mnot.net/