idnits 2.17.1 draft-nottingham-stakeholder-rights-00.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 (October 27, 2014) is 3466 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) -- Obsolete informational reference (is this intentional?): RFC 6962 (Obsoleted by RFC 9162) -- Obsolete informational reference (is this intentional?): RFC 7230 (Obsoleted by RFC 9110, RFC 9112) Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group M. Nottingham 3 Internet-Draft 4 Intended status: Best Current Practice October 27, 2014 5 Expires: April 30, 2015 7 Representing Stakeholder Rights in Internet Protocols 8 draft-nottingham-stakeholder-rights-00 10 Abstract 12 This document proposes a set of guidelines for protocol designers to 13 help balance concerns and conflicts between different stakeholders. 14 It also requires the end user to be the highest priority stakeholder 15 in application protocols. 17 Status of This Memo 19 This Internet-Draft is submitted in full conformance with the 20 provisions of BCP 78 and BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF). Note that other groups may also distribute 24 working documents as Internet-Drafts. The list of current Internet- 25 Drafts is at http://datatracker.ietf.org/drafts/current/. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 This Internet-Draft will expire on April 30, 2015. 34 Copyright Notice 36 Copyright (c) 2014 IETF Trust and the persons identified as the 37 document authors. All rights reserved. 39 This document is subject to BCP 78 and the IETF Trust's Legal 40 Provisions Relating to IETF Documents 41 (http://trustee.ietf.org/license-info) in effect on the date of 42 publication of this document. Please review these documents 43 carefully, as they describe your rights and restrictions with respect 44 to this document. Code Components extracted from this document must 45 include Simplified BSD License text as described in Section 4.e of 46 the Trust Legal Provisions and are provided without warranty as 47 described in the Simplified BSD License. 49 Table of Contents 51 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 52 1.1. Notational Conventions . . . . . . . . . . . . . . . . . 3 53 2. Identifying Stakeholders . . . . . . . . . . . . . . . . . . 3 54 3. Erosion of Rights . . . . . . . . . . . . . . . . . . . . . . 4 55 4. Intermediation and Non-Stakeholders . . . . . . . . . . . . . 5 56 5. Promoting Stakeholders as "Winners" . . . . . . . . . . . . . 5 57 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 58 7. Security Considerations . . . . . . . . . . . . . . . . . . . 6 59 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 60 8.1. Normative References . . . . . . . . . . . . . . . . . . 6 61 8.2. Informative References . . . . . . . . . . . . . . . . . 6 62 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 7 63 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 7 65 1. Introduction 67 The IETF is often reluctant to make decisions based upon human rights 68 in our standards documents, for good reason. We are a technical 69 body, not a political one, and we do not presume to impose our values 70 onto the users of the Internet. Doing so would not be in the 71 interest of the users that we aim to protect, because it would set a 72 precedent that a technical body could do so. Furthermore, embedding 73 such value judgements in our protocols would make fragmentation of 74 the network - and therefore losing its embedded value as a whole - 75 much more likely. 77 Another way to say this is in the words of Lawrence Lessig, who said 78 [CODELAW]: 80 Ours is the age of cyberspace. It, too, has a regulator. This 81 regulator, too, threatens liberty. But so obsessed are we with 82 the idea that liberty means "freedom from government" that we 83 don't even see the regulation in this new space. We therefore 84 don't see the threat to liberty that this regulation presents. 86 This regulator is code--the software and hardware that make 87 cyberspace as it is. This code, or architecture, sets the terms 88 on which life in cyberspace is experienced. It determines how 89 easy it is to protect privacy, or how easy it is to censor speech. 90 It determines whether access to information is general or whether 91 information is zoned. It affects who sees what, or what is 92 monitored. In a host of ways that one cannot begin to see unless 93 one begins to understand the nature of this code, the code of 94 cyberspace regulates. 96 This is indeed a heavy responsibility. 98 That said, it is increasingly difficult to avoid making ethical, 99 societal and even legal judgements in protocol design, as the 100 Internet has become pervasive in many societies. 102 A recurring theme in this area is balancing the rights of various 103 stakeholders, such as (but not limited to) end users, network 104 operators, equipment vendors, implementers, content owners, 105 governments, employers, and parents. 107 This document proposes a set of guidelines regarding these 108 "stakeholder rights" issues that protocol designers ought to consider 109 as new protocols are created, as well as when existing protocols are 110 extended and evolved. 112 In doing so, we seek to enable "the tussle" [TUSSLE]; that is, our 113 protocols (and therefore the code that implements them) should not 114 attempt to establish the law, as Lessig says, but instead aspire to 115 serve as a level, well-defined playing field where society's back- 116 and-forth over the Internet can take place. 118 1.1. Notational Conventions 120 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 121 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 122 document are to be interpreted as described in [RFC2119]. 124 2. Identifying Stakeholders 126 Protocols MUST document relevant primary stakeholders and their 127 interrelationships. 129 For example, HTML does so using the priority of constituencies in the 130 HTML Design Principles [PRIORITY]: 132 In case of conflict, consider users over authors over implementors 133 over specifiers over theoretical purity. In other words costs or 134 difficulties to the user should be given more weight than costs to 135 authors; which in turn should be given more weight than costs to 136 implementors; which should be given more weight than costs to 137 authors of the spec itself, which should be given more weight than 138 those proposing changes for theoretical reasons alone. Of course, 139 it is preferred to make things better for multiple constituencies 140 at once. 142 Note how the relative priority of stakeholders is explicit; this is 143 intentional and encouraged. Some stakeholders - especially end 144 users, for protocols where they are involved - can withdraw their 145 support when their rights are not respected, leading to a failed 146 effort. In other situations, while a stakeholder believes that their 147 rights are fundamental, this may not be necessary for the successful 148 deployment of the protocol, and therefore their rights are not 149 proportionate to those who are. 151 Likewise, the responsibilities of, or expectations upon, stakeholders 152 can vary greatly. For example, end users of Web browsers cannot be 153 reasonably expected to make informed decisions about security, and 154 therefore design decisions there are biased towards default security. 155 When applicable, the expectations upon a stakeholder SHOULD be 156 documented. 158 End-user-facing application protocols MUST prioritise their users 159 higher than any other stakeholders. 161 Extensions to existing protocols MUST document how they interact with 162 the extended protocol's stakeholders. If the extended protocol's 163 stakeholders are not yet documented, the extension MAY estimate its 164 impact, in coordination with that protocol's community and the IESG. 166 The burden of this documentation need not be high; if HTML can do it 167 in a paragraph, so can most protocols. While it might be appropriate 168 in a separate document (e.g., a requirements or use cases draft) or 169 the protocol specification itself, documenting stakeholders in the WG 170 charter has considerable benefits, since it clarifies their 171 relationships up-front. 173 3. Erosion of Rights 175 Changes in the use, deployment patterns, legal context, or other 176 factors of a protocol can bring pressure to re-balance the priorities 177 and rights of existing stakeholders, or insert new ones (usually, 178 when a protocol is either extended or evolved). 180 Such changes MUST NOT violate documented rights of existing 181 stakeholders, or those reasonably assumed by existing stakeholders, 182 without informed consent. Note that this may preclude the change 183 completely, as it is often impossible to gain the informed consent of 184 a large or diffuse group of stakeholders (e.g., end users). 186 For example, there has been increasing pressure to change HTTP 187 [RFC7230] to make it more amenable to optimisation, filtering, and 188 interposition of other value-added services, especially in the face 189 of more pervasive encryption (denoted by HTTPS URIs). However, since 190 HTTPS is already defined as a two-party protocol with end-to-end 191 encryption, inserting a third party in any fashion would violate the 192 rights of two existing stakeholders; end users and content 193 publishers. Therefore, the HTTP Working Group has refused to 194 consider such changes. 196 4. Intermediation and Non-Stakeholders 198 In protocol design, intermediation is often thought of as "those 199 parties on the direct path between two people attempting to 200 communicate"; e.g., middleboxes, proxies and so on. 202 When discussing stakeholder rights, this definition is expanded to 203 include those parties that have the ability to prevent or control 204 communication between two parties. This naturally includes 205 middleboxes, but can also include third parties not directly on-path. 207 For example, HTTP has on-path intermediaries (proxies, gateways, 208 etc.), but also off-path intermediaries, in the form of the DNS 209 registrar, the DNS server, and also the Certificate Authority if TLS 210 is in use. Certificate Transparency [RFC6962] potentially adds yet 211 another intermediary to this protocol suite. 213 While there might be a good technical reason to interpose such an 214 intermediary, it also introduces a new stakeholder, and thus needs to 215 be done with due consideration of the impact on other stakeholders. 217 Therefore, such intermediation SHOULD NOT be accommodated without 218 purpose in Internet protocols, and protocol revisions (including 219 extensions) MUST carefully weigh when new levels of intermediation 220 are added. When a stakeholder has a role as an intermediary (in this 221 sense), it MUST be documented. 223 5. Promoting Stakeholders as "Winners" 225 Protocols often engender network effects. For example, e-mail is 226 only useful when the parties you wish to communicate with also have 227 e-mail; when more people have e-mail, its value is greatly increased. 229 However, network effects can also be captured by a single party, in a 230 "winner take all" market. For example, if we mint a new 231 communication protocol without providing a way for two independent 232 users to identify each other and rendezvous, it creates a condition 233 whereby a rendezvous service can create network effects and possibly 234 "win" the market. 236 This is the antithesis of Internetworking, and SHOULD NOT be 237 intentionally enabled, by commission or omission, by Internet 238 protocols. 240 Practically speaking, this means that protocols - especially 241 application protocols - are required to accommodate what is commonly 242 known as "federation". 244 6. IANA Considerations 246 This document does not require action by IANA. 248 7. Security Considerations 250 This document does not specify a protocol; however, applying its 251 guidelines might affect security positively or negatively for various 252 stakeholders. 254 8. References 256 8.1. Normative References 258 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 259 Requirement Levels", BCP 14, RFC 2119, March 1997. 261 8.2. Informative References 263 [CODELAW] Lessig, L., "Code Is Law: On Liberty in Cyberspace", 2000, 264 . 266 [PRIORITY] 267 van Kesteren, A. and M. Stachowiak, "HTML Design 268 Principles", November 2007, . 271 [RFC6962] Laurie, B., Langley, A., and E. Kasper, "Certificate 272 Transparency", RFC 6962, June 2013. 274 [RFC7230] Fielding, R. and J. Reschke, "Hypertext Transfer Protocol 275 (HTTP/1.1): Message Syntax and Routing", RFC 7230, June 276 2014. 278 [TUSSLE] Clark, D., Sollins, K., Wroclawski, J., and R. Braden, 279 "Tussle in Cyberspace: Defining Tomorrow's Internet", 280 2002, 281 . 284 Appendix A. Acknowledgements 286 Thanks to Jacob Appelbaum for making the suggestion that led to this 287 document. 289 Thanks also to the WHATWG, for blazing the trail. 291 Thanks to Joe Hildebrand and Martin Thomson for their suggestions. 293 Author's Address 295 Mark Nottingham 297 Email: mnot@mnot.net 298 URI: http://www.mnot.net/