diff options
Diffstat (limited to 'doc/rfc/rfc8890.txt')
| -rw-r--r-- | doc/rfc/rfc8890.txt | 494 |
1 files changed, 494 insertions, 0 deletions
diff --git a/doc/rfc/rfc8890.txt b/doc/rfc/rfc8890.txt new file mode 100644 index 0000000..4eff9cc --- /dev/null +++ b/doc/rfc/rfc8890.txt @@ -0,0 +1,494 @@ + + + + +Internet Architecture Board (IAB) M. Nottingham +Request for Comments: 8890 August 2020 +Category: Informational +ISSN: 2070-1721 + + + The Internet is for End Users + +Abstract + + This document explains why the IAB believes that, when there is a + conflict between the interests of end users of the Internet and other + parties, IETF decisions should favor end users. It also explores how + the IETF can more effectively achieve this. + +Status of This Memo + + This document is not an Internet Standards Track specification; it is + published for informational purposes. + + This document is a product of the Internet Architecture Board (IAB) + and represents information that the IAB has deemed valuable to + provide for permanent record. It represents the consensus of the + Internet Architecture Board (IAB). Documents approved for + publication by the IAB are not candidates for any level of Internet + Standard; see Section 2 of RFC 7841. + + Information about the current status of this document, any errata, + and how to provide feedback on it may be obtained at + https://www.rfc-editor.org/info/rfc8890. + +Copyright Notice + + Copyright (c) 2020 IETF Trust and the persons identified as the + document authors. All rights reserved. + + This document is subject to BCP 78 and the IETF Trust's Legal + Provisions Relating to IETF Documents + (https://trustee.ietf.org/license-info) in effect on the date of + publication of this document. Please review these documents + carefully, as they describe your rights and restrictions with respect + to this document. + +Table of Contents + + 1. Introduction + 2. Who Are "End Users"? + 3. Why the IETF Should Prioritize End Users + 4. How the IETF Can Prioritize End Users + 4.1. Engaging the Internet Community + 4.2. Creating User-Focused Systems + 4.3. Identifying Negative End-User Impact + 4.4. Handling Conflicting End-User Needs + 4.5. Deprioritizing Internal Needs + 5. IANA Considerations + 6. Security Considerations + 7. Informative References + IAB Members at the Time of Approval + Acknowledgements + Author's Address + +1. Introduction + + Many who participate in the IETF are most comfortable making what we + believe to be purely technical decisions; our process favors + technical merit through our well-known mantra of "rough consensus and + running code." + + Nevertheless, the running code that results from our process (when + things work well) inevitably has an impact beyond technical + considerations, because the underlying decisions afford some uses + while discouraging others. While we believe we are making only + technical decisions, in reality, we are defining (in some degree) + what is possible on the Internet itself. + + This impact has become significant. As the Internet increasingly + mediates essential functions in societies, it has unavoidably become + profoundly political; it has helped people overthrow governments, + revolutionize social orders, swing elections, control populations, + collect data about individuals, and reveal secrets. It has created + wealth for some individuals and companies while destroying that of + others. + + All of this raises the question: For whom do we go through the pain + of gathering rough consensus and writing running code? + + After all, there are a variety of parties that standards can benefit, + such as (but not limited to) end users, network operators, schools, + equipment vendors, specification authors, specification implementers, + content owners, governments, nongovernmental organizations, social + movements, employers, and parents. + + Successful specifications will provide some benefit to all the + relevant parties because standards do not represent a zero-sum game. + However, there are sometimes situations where there is a conflict + between the needs of two (or more) parties. + + In these situations, when one of those parties is an "end user" of + the Internet -- for example, a person using a web browser, mail + client, or another agent that connects to the Internet -- the + Internet Architecture Board argues that the IETF should favor their + interests over those of other parties. + + Section 2 explains what is meant by "end users", Section 3 outlines + why IETF work should prioritize them, and Section 4 describes how we + can do that. + +2. Who Are "End Users"? + + In this document, "end users" means human users whose activities IETF + standards support, sometimes indirectly. Thus, the end user of a + protocol to manage routers is not a router administrator; it is the + people using the network that the router operates within. + + End users are not necessarily a homogenous group; they might have + different views of how the Internet should work and might occupy + several roles, such as a seller, buyer, publisher, reader, service + provider, and consumer. An end user might browse the Web, monitor + remote equipment, play a game, videoconference with colleagues, send + messages to friends, or perform an operation in a remote surgery + theater. They might be "at the keyboard" or represented by software + indirectly (e.g., as a daemon). + + Likewise, an individual end user might have many interests (e.g., + privacy, security, flexibility, reachability) that are sometimes in + tension. + + A person whose interests we need to consider might not directly be + using a specific system connected to the Internet. For example, if a + child is using a browser, the interests of that child's parents or + guardians may be relevant. A person pictured in a photograph may + have an interest in systems that process that photograph; a person + entering a room with sensors that send data to the Internet may have + interests that may be involved in our deliberations about how those + sensor readings are handled. + + While such less-direct interactions between people and the Internet + may be harder to evaluate, this document's concept of "end user" + nonetheless includes such people. + +3. Why the IETF Should Prioritize End Users + + Even before the IETF was established, the Internet technical + community has focused on user needs since at least [RFC0001], which + stated that "One of our goals must be to stimulate the immediate and + easy use by a wide class of users." + + And, while we specialize in technical matters, the IETF is not + neutral about the purpose of its work in developing the Internet; in + "A Mission Statement for the IETF" [RFC3935], the definitions + include: + + | The IETF community wants the Internet to succeed because we + | believe that the existence of the Internet, and its influence on + | economics, communication, and education, will help us to build a + | better human society. + + Later, in "The Scope of the Internet" (Section 4.1 of [RFC3935]), it + says: + + | The Internet isn't value-neutral, and neither is the IETF. We + | want the Internet to be useful for communities that share our + | commitment to openness and fairness. We embrace technical + | concepts such as decentralized control, edge-user empowerment and + | sharing of resources, because those concepts resonate with the + | core values of the IETF community. These concepts have little to + | do with the technology that's possible, and much to do with the + | technology that we choose to create. + + In other words, the IETF develops and maintains the Internet to + promote the social good. The society that the IETF is attempting to + enhance is composed of end users, along with groups of them forming + businesses, governments, clubs, civil society organizations, and + other institutions. + + Merely advancing the measurable success of the Internet (e.g., + deployment size, bandwidth, latency, number of users) is not an + adequate goal; doing so ignores how technology is so often used as a + lever to assert power over users, rather than empower them. + + Beyond fulfilling the IETF's mission, prioritizing end users can also + help to ensure the long-term health of the Internet and the IETF's + relevance to it. Perceptions of capture by vendors or other + providers harm both; the IETF's work will (deservedly) lose end + users' trust if it prioritizes (or is perceived to prioritize) + others' interests over them. + + Ultimately, the Internet will succeed or fail based upon the actions + of its end users, because they are the driving force behind its + growth to date. Not prioritizing them jeopardizes the network effect + that the Internet relies upon to provide so much value. + +4. How the IETF Can Prioritize End Users + + There are a few ways that the IAB believes the IETF community can + prioritize end users, based upon our observations. This is not a + complete list. + +4.1. Engaging the Internet Community + + The IETF community does not have any unique insight into what is + "good for end users", and it is not uncommon for us to be at a + further disadvantage because of our close understanding of some -- + but not all -- aspects of the Internet. + + At the same time, we have a culture of considerable deference to a + broader "Internet community" -- roughly what this document calls end + users -- in our decision-making processes. Mere deference, however, + is not adequate; even with the best intentions, we cannot assume that + our experiences of the Internet are those of all of its end users or + that our decisions have a positive impact upon them. + + Therefore, we have not only a responsibility to analyze and consider + the impacts of the IETF's work, but also a responsibility to consult + with that greater Internet community. In particular, we should do so + when one of our decisions has a potential impact upon end users. + + The IETF community faces significant hurdles in doing so. Our work + is specialized and often esoteric, and processes for developing + standards often involve very long timescales. Affected parties are + rarely technical experts, and they often base their understanding of + the Internet upon incomplete (and sometimes inaccurate) models. + Often, even when we try to engage a broader audience, their + participation is minimal -- until a change affects someone in a way + they don't like. Surprising the Internet community is rarely a good + outcome. + + Government-sponsored individuals sometimes participate in the IETF + community. While this is welcome, it should not be taken as + automatically representative of end users elsewhere, or even all end + users in the relevant jurisdiction. Furthermore, what is desirable + in one jurisdiction (or at least to its administrators) might be + detrimental in others (see Section 4.4). + + While some civil society organizations specialize in technology and + Internet policy, they rarely can participate broadly, nor are they + necessarily representative of the larger Internet community. + Nevertheless, their understanding of end-user needs is often + profound, and they are in many ways the best-informed advocates for + end-user concerns; they should be considered a primary channel for + engaging the broader Internet community. + + A promising approach to help fill these gaps is to identify and + engage with specifically affected communities when making decisions + that might affect them, for example, one or more industry + associations, user groups, or a set of individuals, though we can't + formally ensure that they are appropriately representative. + + In doing so, we should not require them to "come to us"; unless a + stakeholder community is already engaged in the IETF process + effectively, the IETF community should explore how to meet with them + on their terms -- take the initiative to contact them, explain our + work, and solicit their feedback. + + In particular, while IAB workshops, BOFs, and Bar BOFs can be an + effective mechanism to gather input within our community, they rarely + have the visibility into other communities that is required to + solicit input, much less effective participation. + + Instead, an event like a workshop may be more effective if co-located + with -- and ideally hosted or co-hosted by -- a forum that's familiar + to that stakeholder community. We should also raise the visibility + of IETF work (or potential IETF work) in such fora through conference + talks, panels, newsletter articles, etc. + + For example, the IAB ESCAPE workshop [RFC8752] solicited input from + Internet publishers and advertisers about a proposal that might + affect them. While the workshop was considered successful, + participation might have been improved by identifying an appropriate + industry forum and working with them to host the event. + + When we engage with the Internet community, we should also clearly + identify tailored feedback mechanisms (e.g., subscribing to a mailing + list may not be appropriate) and assure that they are well known in + those communities. + + The Internet Society can be an invaluable partner in these efforts; + their focus on the Internet community, policy expertise, and + resources can help to facilitate discussions with the appropriate + parties. + + Finally, we should remember that the RFC Series contains Requests For + Comments; if there are serious implications of our work, we should + document them and ask for feedback from the Internet community. + +4.2. Creating User-Focused Systems + + We should pay particular attention to the kinds of architectures we + create and whether they encourage or discourage an Internet that + works for end users. + + For example, one of the most successful Internet applications is the + Web, which uses the HTTP application protocol. One of HTTP's key + implementation roles is that of the web browser -- called the "user + agent" in [RFC7230] and other specifications. + + User agents act as intermediaries between a service and the end user; + rather than downloading an executable program from a service that has + arbitrary access into the users' system, the user agent only allows + limited access to display content and run code in a sandboxed + environment. End users are diverse and the ability of a few user + agents to represent individual interests properly is imperfect, but + this arrangement is an improvement over the alternative -- the need + to trust a website completely with all information on your system to + browse it. + + Defining the user agent role in standards also creates a virtuous + cycle; it allows multiple implementations, allowing end users to + switch between them with relatively low costs (although there are + concerns about the complexity of the Web creating barriers to entry + for new implementations). This creates an incentive for implementers + to consider the users' needs carefully, which are often reflected + into the defining standards. The resulting ecosystem has many + remaining problems, but a distinguished user agent role provides an + opportunity to improve it. + + In contrast, the Internet of Things (IoT) has not yet seen the broad + adoption of a similar role; many current systems require opaque, + vendor-specific software or hardware for the user-facing component. + Perhaps as a result of this, that ecosystem and its end users face + serious challenges. + +4.3. Identifying Negative End-User Impact + + At its best, our work will unambiguously build a better human + society. Sometimes, we will consciously be neutral and open-ended, + allowing the "tussle" among stakeholders to produce a range of + results (see [TUSSLE] for further discussion). + + At the very least, however, we must examine our work for negative + impact on end users and take steps to mitigate it where encountered. + In particular, when we've identified a conflict between the interests + of end users and other stakeholders, we should err on the side of + protecting end users. + + Note that "negative impact on end users" is not defined in this + document; that is something that the relevant body (e.g., working + group) needs to discuss and come to consensus on. Merely asserting + that something is harmful is not adequate. The converse is also + true, though; it's not good practice to avoid identifying harms, nor + is it acceptable to ignore them when brought to our attention. + + The IAB and IETF have already established a body of guidance for + situations where this conflict is common, including (but not limited + to) [RFC7754] on filtering, [RFC7258] and [RFC7624] on pervasive + surveillance, [RFC7288] on host firewalls, and [RFC6973] regarding + privacy considerations. + + Much of that advice has focused on maintaining the end-to-end + properties of a connection [RFC3724]. This does not mean that our + responsibility to end users stops there; decisions might affect them + in other ways. For example, data collection by various applications + even inside otherwise secure connections is a major problem on the + Internet today. Also, inappropriate concentration of power on the + Internet has become a concerning phenomenon -- one that protocol + design might have some influence upon. + +4.4. Handling Conflicting End-User Needs + + When the needs of different end users conflict (for example, two sets + of end users both have reasonable desires), we again should try to + minimize negative impact. + + For example, when a decision improves the Internet for end users in + one jurisdiction, but at the cost of potential harm to others + elsewhere, that is not a good trade-off. As such, we design the + Internet for the pessimal environment; if a user can be harmed, they + probably will be, somewhere. + + There may be cases where genuine technical need requires compromise. + However, such trade-offs are carefully examined and avoided when + there are alternate means of achieving the desired goals. If they + cannot be, these choices and reasoning ought to be thoroughly + documented. + +4.5. Deprioritizing Internal Needs + + There are several needs that are very visible to us as specification + authors but should explicitly not be prioritized over the needs of + end users. + + These include convenience for document editors, IETF process matters, + and "architectural purity" for its own sake. + +5. IANA Considerations + + This document has no IANA actions. + +6. Security Considerations + + This document does not have any direct security impact; however, + failing to prioritize end users might well affect their security + negatively in the long term. + +7. Informative References + + [RFC0001] Crocker, S., "Host Software", RFC 1, DOI 10.17487/RFC0001, + April 1969, <https://www.rfc-editor.org/info/rfc1>. + + [RFC3724] Kempf, J., Ed., Austein, R., Ed., and IAB, "The Rise of + the Middle and the Future of End-to-End: Reflections on + the Evolution of the Internet Architecture", RFC 3724, + DOI 10.17487/RFC3724, March 2004, + <https://www.rfc-editor.org/info/rfc3724>. + + [RFC3935] Alvestrand, H., "A Mission Statement for the IETF", + BCP 95, RFC 3935, DOI 10.17487/RFC3935, October 2004, + <https://www.rfc-editor.org/info/rfc3935>. + + [RFC6973] Cooper, A., Tschofenig, H., Aboba, B., Peterson, J., + Morris, J., Hansen, M., and R. Smith, "Privacy + Considerations for Internet Protocols", RFC 6973, + DOI 10.17487/RFC6973, July 2013, + <https://www.rfc-editor.org/info/rfc6973>. + + [RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer + Protocol (HTTP/1.1): Message Syntax and Routing", + RFC 7230, DOI 10.17487/RFC7230, June 2014, + <https://www.rfc-editor.org/info/rfc7230>. + + [RFC7258] Farrell, S. and H. Tschofenig, "Pervasive Monitoring Is an + Attack", BCP 188, RFC 7258, DOI 10.17487/RFC7258, May + 2014, <https://www.rfc-editor.org/info/rfc7258>. + + [RFC7288] Thaler, D., "Reflections on Host Firewalls", RFC 7288, + DOI 10.17487/RFC7288, June 2014, + <https://www.rfc-editor.org/info/rfc7288>. + + [RFC7624] Barnes, R., Schneier, B., Jennings, C., Hardie, T., + Trammell, B., Huitema, C., and D. Borkmann, + "Confidentiality in the Face of Pervasive Surveillance: A + Threat Model and Problem Statement", RFC 7624, + DOI 10.17487/RFC7624, August 2015, + <https://www.rfc-editor.org/info/rfc7624>. + + [RFC7754] Barnes, R., Cooper, A., Kolkman, O., Thaler, D., and E. + Nordmark, "Technical Considerations for Internet Service + Blocking and Filtering", RFC 7754, DOI 10.17487/RFC7754, + March 2016, <https://www.rfc-editor.org/info/rfc7754>. + + [RFC8752] Thomson, M. and M. Nottingham, "Report from the IAB + Workshop on Exploring Synergy between Content Aggregation + and the Publisher Ecosystem (ESCAPE)", RFC 8752, + DOI 10.17487/RFC8752, March 2020, + <https://www.rfc-editor.org/info/rfc8752>. + + [TUSSLE] Clark, D., Sollins, K., Wroclawski, J., and R. Braden, + "Tussle in Cyberspace: Defining Tomorrow's Internet", + DOI 10.1145/633025.633059, August 2002, + <https://groups.csail.mit.edu/ana/Publications/PubPDFs/ + Tussle2002.pdf>. + +IAB Members at the Time of Approval + + Internet Architecture Board members at the time this document was + approved for publication were: + + Jari Arkko + Alissa Cooper + Stephen Farrell + Wes Hardaker + Ted Hardie + Christian Huitema + Zhenbin Li + Erik Nordmark + Mark Nottingham + Melinda Shore + Jeff Tantsura + Martin Thomson + Brian Trammell + +Acknowledgements + + Many discussions influenced this document, both inside and outside of + the IETF and IAB. In particular, Edward Snowden's comments regarding + the priority of end users at IETF 93 and the HTML5 Priority of + Constituencies were both influential. + + Many people gave feedback and input, including Harald Alvestrand, + Mohamed Boucadair, Joe Hildebrand, Lee Howard, Russ Housley, Niels + ten Oever, Mando Rachovitsa, John Klensin, and Eliot Lear. + +Author's Address + + Mark Nottingham + Prahran VIC + Australia + + Email: mnot@mnot.net + URI: https://www.mnot.net/ |