| draft-nottingham-for-the-users-08.txt |  | draft-iab-for-the-users-00.txt |
--- | --- | --- | --- | ---
| Network Working Group M. Nottingham |  | Network Working Group M. Nottingham |
| Internet-Draft June 10, 2019 |  | Internet-Draft July 1, 2019 |
| Intended status: Informational |  | Intended status: Informational |
| Expires: December 12, 2019 |  | Expires: January 2, 2020 |
| The Internet is for End Users |  | The Internet is for End Users |
| draft-nottingham-for-the-users-08 |  | draft-iab-for-the-users-00 |
| Abstract |  | Abstract |
| This document explains why the IETF should consider end-users as its |  | This document explains why the IAB believes the IETF should consider |
| highest priority concern, and how. |  | end-users as its highest priority concern, and how that can be done. |
| Note to Readers |  | Note to Readers |
| The issues list for this draft can be found at |  | The issues list for this draft can be found at |
| https://github.com/mnot/I-D/labels/for-the-users [1]. |  | https://github.com/mnot/I-D/labels/for-the-users [1]. |
| The most recent (often, unpublished) draft is at |  | The most recent (often, unpublished) draft is at |
| https://mnot.github.io/I-D/for-the-users/ [2]. |  | https://mnot.github.io/I-D/for-the-users/ [2]. |
| Recent changes are listed at https://github.com/mnot/I-D/commits/gh- |  | Recent changes are listed at https://github.com/mnot/I-D/commits/gh- |
| skipping to change at page 1, line 45 ¶ |  | skipping to change at page 1, line 45 ¶ |
| Internet-Drafts are working documents of the Internet Engineering |  | Internet-Drafts are working documents of the Internet Engineering |
| Task Force (IETF). Note that other groups may also distribute |  | Task Force (IETF). Note that other groups may also distribute |
| working documents as Internet-Drafts. The list of current Internet- |  | working documents as Internet-Drafts. The list of current Internet- |
| Drafts is at https://datatracker.ietf.org/drafts/current/. |  | Drafts is at https://datatracker.ietf.org/drafts/current/. |
| Internet-Drafts are draft documents valid for a maximum of six months |  | Internet-Drafts are draft documents valid for a maximum of six months |
| and may be updated, replaced, or obsoleted by other documents at any |  | and may be updated, replaced, or obsoleted by other documents at any |
| time. It is inappropriate to use Internet-Drafts as reference |  | time. It is inappropriate to use Internet-Drafts as reference |
| material or to cite them other than as "work in progress." |  | material or to cite them other than as "work in progress." |
| This Internet-Draft will expire on December 12, 2019. |  | This Internet-Draft will expire on January 2, 2020. |
| Copyright Notice |  | Copyright Notice |
| Copyright (c) 2019 IETF Trust and the persons identified as the |  | Copyright (c) 2019 IETF Trust and the persons identified as the |
| document authors. All rights reserved. |  | document authors. All rights reserved. |
| This document is subject to BCP 78 and the IETF Trust's Legal |  | This document is subject to BCP 78 and the IETF Trust's Legal |
| Provisions Relating to IETF Documents |  | Provisions Relating to IETF Documents |
| (https://trustee.ietf.org/license-info) in effect on the date of |  | (https://trustee.ietf.org/license-info) in effect on the date of |
| publication of this document. Please review these documents |  | publication of this document. Please review these documents |
| carefully, as they describe your rights and restrictions with respect |  | carefully, as they describe your rights and restrictions with respect |
| to this document. Code Components extracted from this document must |  | to this document. |
| include Simplified BSD License text as described in Section 4.e of |  |  |
| the Trust Legal Provisions and are provided without warranty as |  |  |
| described in the Simplified BSD License. |  |  |
| Table of Contents |  | Table of Contents |
| 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 |  | 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 |
| 2. What Are "End Users"? . . . . . . . . . . . . . . . . . . . . 3 |  | 2. What Are "End Users"? . . . . . . . . . . . . . . . . . . . . 3 |
| 3. Why End Users Should Be Prioritised . . . . . . . . . . . . . 4 |  | 3. Why End Users Should Be Prioritised . . . . . . . . . . . . . 4 |
| 4. How End Users are Prioritised . . . . . . . . . . . . . . . . 5 |  | 4. How End Users are Prioritised . . . . . . . . . . . . . . . . 5 |
| 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 |  | 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 |
| 6. Security Considerations . . . . . . . . . . . . . . . . . . . 7 |  | 6. Security Considerations . . . . . . . . . . . . . . . . . . . 6 |
| 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 |  | 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 |
| 7.1. Informative References . . . . . . . . . . . . . . . . . 7 |  | 7.1. Informative References . . . . . . . . . . . . . . . . . 7 |
| 7.2. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 8 |  | 7.2. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 7 |
| Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 8 |  | Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 8 |
| Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 8 |  | Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 8 |
| 1. Introduction |  | 1. Introduction |
| Many who participate in the IETF are most comfortable making what we |  | Many who participate in the IETF are most comfortable making what we |
| believe to be purely technical decisions; our process is defined to |  | believe to be purely technical decisions; our process is defined to |
| favor technical merit, through our well-known mantra of "rough |  | favor technical merit, through our well-known mantra of "rough |
| consensus and running code." |  | consensus and running code." |
| Nevertheless, the running code that results from our process (when |  | Nevertheless, the running code that results from our process (when |
| things work well) inevitably has an impact beyond technical |  | things work well) inevitably has an impact beyond technical |
| considerations, because the underlying decisions afford some uses |  | considerations, because the underlying decisions afford some uses |
| while discouraging others; while we believe we are making purely |  | while discouraging others; while we believe we are making purely |
| technical decisions, in reality, we are defining what is possible on |  | technical decisions, in reality, we are defining what is possible on |
| the Internet itself. Or, in the words of Lawrence Lessig [CODELAW]: |  | the Internet itself. |
| Ours is the age of cyberspace. It, too, has a regulator... This |  |  |
| regulator is code -- the software and hardware that make |  |  |
| cyberspace as it is. This code, or architecture, sets the terms |  |  |
| on which life in cyberspace is experienced. It determines how |  |  |
| easy it is to protect privacy, or how easy it is to censor speech. |  |  |
| It determines whether access to information is general or whether |  |  |
| information is zoned. It affects who sees what, or what is |  |  |
| monitored. In a host of ways that one cannot begin to see unless |  |  |
| one begins to understand the nature of this code, the code of |  |  |
| cyberspace regulates. |  |  |
| This impact has become significant. As the Internet increasingly |  | This impact has become significant. As the Internet increasingly |
| mediates essential functions in societies, it has unavoidably become |  | mediates essential functions in societies, it has unavoidably become |
| profoundly political; it has helped people overthrow governments and |  | profoundly political; it has helped people overthrow governments and |
| revolutionize social orders, control populations and reveal secrets. |  | revolutionize social orders, control populations, collect data about |
| It has created wealth for some individuals and companies while |  | individuals, and reveal secrets. It has created wealth for some |
| destroying others'. |  | individuals and companies while destroying others'. |
| All of this raises the question: Who do we go through the pain of |  | All of this raises the question: Who do we go through the pain of |
| gathering rough consensus and writing running code for? |  | gathering rough consensus and writing running code for? |
| After all, there are a variety of identifiable parties in the broader |  | After all, there are a variety of identifiable parties in the broader |
| Internet community that standards can provide benefit to, such as |  | Internet community that standards can provide benefit to, such as |
| (but not limited to) end users, network operators, schools, equipment |  | (but not limited to) end users, network operators, schools, equipment |
| vendors, specification authors, specification implementers, content |  | vendors, specification authors, specification implementers, content |
| owners, governments, non-governmental organisations, social |  | owners, governments, non-governmental organisations, social |
| movements, employers, and parents. |  | movements, employers, and parents. |
| Successful specifications will provide some benefit to all of the |  | Successful specifications will provide some benefit to all of the |
| relevant parties because standards do not represent a zero-sum game. |  | relevant parties because standards do not represent a zero-sum game. |
| However, there are sometimes situations where there is a need to |  | However, there are sometimes situations where there is a need to |
| balance the benefits of a decision between two (or more) parties. |  | balance the benefits of a decision between two (or more) parties. |
| In these situations, when one of those parties is an "end user" of |  | In these situations, when one of those parties is an "end user" of |
| the Internet - for example, a person using a Web browser, mail |  | the Internet - for example, a person using a Web browser, mail |
| client, or another agent that connects to the Internet - this |  | client, or another agent that connects to the Internet - the Internet |
| document argues that the IETF should protect their interests over |  | Architecture Board argues that the IETF should protect their |
| those of parties. |  | interests over those of parties. |
| Section 2 explains what is meant by "end users"; Section 3 outlines |  | Section 2 explains what is meant by "end users"; Section 3 outlines |
| why they should be prioritised in IETF work, and Section 4 describes |  | why they should be prioritised in IETF work, and Section 4 describes |
| how that can be done. |  | how that can be done. |
| 2. What Are "End Users"? |  | 2. What Are "End Users"? |
| In this document, "end users," means non-technical users whose |  | In this document, "end users," means non-technical users whose |
| activities IETF protocols are designed to support, sometimes |  | activities IETF protocols are designed to support, sometimes |
| indirectly. Thus, the end user of a protocol to manage routers is |  | indirectly. Thus, the end user of a protocol to manage routers is |
| skipping to change at page 5, line 23 ¶ |  | skipping to change at page 5, line 11 ¶ |
| helps to ensure the long-term health of the Internet. Many aspects |  | helps to ensure the long-term health of the Internet. Many aspects |
| of the Internet are user-focused, and it will (deservedly) lose their |  | of the Internet are user-focused, and it will (deservedly) lose their |
| trust if prioritises others' interests. Because one of the primary |  | trust if prioritises others' interests. Because one of the primary |
| mechanisms of the Internet is the "network effect", such trust is |  | mechanisms of the Internet is the "network effect", such trust is |
| crucial to maintain; the Internet itself depends upon it. |  | crucial to maintain; the Internet itself depends upon it. |
| 4. How End Users are Prioritised |  | 4. How End Users are Prioritised |
| The IETF community does not have any unique insight into what is |  | The IETF community does not have any unique insight into what is |
| "good for end users." To inform its decisions, it has a |  | "good for end users." To inform its decisions, it has a |
| responsibility to interact with the greater Internet community, |  | responsibility to analyse and consider the impacts of its work, as |
|  |  | well as, where needed, interact with the greater Internet community, |
| soliciting input from others and considering the issues raised. |  | soliciting input from others and considering the issues raised. |
| End users are typically not technical experts; their experience of |  | End users are typically not technical experts; their experience of |
| the Internet is often based upon inadequate models of its properties, |  | the Internet is often based upon inadequate models of its properties, |
| operation, and administration. Therefore, the IETF should primarily |  | operation, and administration. Therefore, the IETF should primarily |
| engage with those who understand how changes to it will affect end |  | engage with those who understand how changes to it will affect end |
| users; in particular civil society organisations, as well as |  | users; in particular civil society organisations, as well as |
| governments, businesses and other groups representing some aspect of |  | governments, businesses and other groups representing some aspect of |
| end-user interests. |  | end-user interests. |
| The onus is on us to engage with these parties on terms that suit |  | The IAB encourages the IETF to explicitly consider user impacts and |
| them; it is not acceptable to require them to understand the mores |  | points of view in any IETF work. The IAB also encourages the IETF to |
| and peculiarities of the IETF community - even as we attempt to |  | engage with the above parties on terms that suit them; it is not |
| enculture them into it. This means that when appropriate, we should |  | reasonable to require them to understand the mores and peculiarities |
| take the initiative to contact these communities and explain our |  | of the IETF community - even though we encourage them to participate |
| work, solicit their feedback, and encourage their participation. In |  | in it. |
| cases where it is not reasonable a stakeholder community to engage in |  |  |
| the IETF, we should go to them - for example, holding workshops. |  | That means, when appropriate, the technical community should take the |
|  |  | initiative to contact these communities and explain our work, solicit |
|  |  | their feedback, and encourage their participation. In cases where it |
|  |  | is not reasonable for a stakeholder community to engage in the IETF |
|  |  | process, the technical community should meet with them. IAB |
|  |  | workshops can serve this purpose and the IAB encourages suggestions |
|  |  | for topics where this would be of benefit. |
| At our best, this will result in work that promotes the social good. |  | At our best, this will result in work that promotes the social good. |
| In some cases, we will consciously decide to be neutral and open- |  | In some cases, we will consciously decide to be neutral and open- |
| ended, allowing the "tussle" among stakeholders to produce a range of |  | ended, allowing the "tussle" among stakeholders to produce a range of |
| results (see [TUSSLE] for further discussion). |  | results (see [TUSSLE] for further discussion). |
| At the very least, however, we must examine our work for harm to end |  | At the very least, however, we must examine our work for impact on |
| users, and take positive steps to avoid it where we see it. In |  | end users, and take positive steps to avoid it where we see it. In |
| particular, when we've identified a conflict between the interests of |  | particular, when we've identified a conflict between the interests of |
| end users and another stakeholder, we should err on the side of |  | end users and another stakeholder, we should err on the side of |
| finding a solution that avoids that harm. |  | finding a solution that avoids harmful consequences to end sers. |
| Note that "harm" is not defined in this document; that is something |  | Note that "harmful" is not defined in this document; that is |
| that the relevant body (e.g., Working Group) needs to discuss. |  | something that the relevant body (e.g., Working Group) needs to |
| Furthermore, harm to end users is judged just like any other decision |  | discuss. Furthermore, harm to end users is judged just like any |
| in the IETF, with consensus gathering and the normal appeals process; |  | other decision in the IETF, with consensus gathering and the normal |
| merely asserting that something is harmful is not adequate. The |  | appeals process; merely asserting that something is harmful is not |
| converse is also true, though; it's not permissible to avoid |  | adequate. The converse is also true, though; it's not permissible to |
| identifying harms, nor is it acceptable to ignore them when brought |  | avoid identifying harms, nor is it acceptable to ignore them when |
| to us. |  | brought to us. |
| The IETF has already established a body of guidance for situations |  | The IETF has already established a body of guidance for situations |
| where this sort of conflict is common, including (but not limited to) |  | where this sort of conflict is common, including (but not limited to) |
| [RFC7754] on filtering, [RFC7258] and [RFC7624] on pervasive |  | [RFC7754] on filtering, [RFC7258] and [RFC7624] on pervasive |
| surveillance, [RFC7288] on host firewalls, and [RFC6973] regarding |  | surveillance, [RFC7288] on host firewalls, and [RFC6973] regarding |
| privacy considerations. When specific advice is not yet available, |  | privacy considerations. When specific advice is not yet available, |
| we try to find a different solution or another way to frame the |  | we try to find a different solution or another way to frame the |
| problem, distilling the underlying principles into more general |  | problem, distilling the underlying principles into more general |
| advice where appropriate. |  | advice where appropriate. |
| Much of that advice has focused on maintaining the end-to-end |  | Much of that advice has focused on maintaining the end-to-end |
| security properties of a connection. This does not mean that our |  | security properties of a connection. This does not mean that our |
| responsibility to users stops there; protocols decisions might affect |  | responsibility to users stops there; protocol decisions might affect |
| users in other ways. For example, inappropriate concentration of |  | users in other ways. For example, data collection by various |
|  |  | applications even inside otherwise secure connections is a major |
|  |  | problem in the Internet today. Also, inappropriate concentration of |
| power on the Internet has become a concerning phenomenon - one that |  | power on the Internet has become a concerning phenomenon - one that |
| protocol design might have some influence upon. |  | protocol design might have some influence upon. |
| When the needs of different end users conflict (for example, two sets |  | When the needs of different end users conflict (for example, two sets |
| of end users both have reasonable desires) we again should try to |  | of end users both have reasonable desires) we again should try to |
| minimise harm. For example, when a decision improves the Internet |  | minimise harm. For example, when a decision improves the Internet |
| for end users in one jurisdiction, but at the cost of potential harm |  | for end users in one jurisdiction, but at the cost of potential harm |
| to others elsewhere, that is not a good tradeoff. As such, we |  | to others elsewhere, that is not a good tradeoff. As such, we |
| effectively design the Internet for the pessimal environment; if a |  | effectively design the Internet for the pessimal environment; if a |
| user can be harmed, they probably will be. |  | user can be harmed, they probably will be. |
| skipping to change at page 7, line 15 ¶ |  | skipping to change at page 7, line 9 ¶ |
| 6. Security Considerations |  | 6. Security Considerations |
| This document does not have any direct security impact; however, |  | This document does not have any direct security impact; however, |
| failing to prioritise end users might well affect their security |  | failing to prioritise end users might well affect their security |
| negatively in the long term. |  | negatively in the long term. |
| 7. References |  | 7. References |
| 7.1. Informative References |  | 7.1. Informative References |
| [CODELAW] Lessig, L., "Code Is Law: On Liberty in Cyberspace", 2000, |  |  |
| <http://harvardmagazine.com/2000/01/code-is-law-html>. |  |  |
| [RFC3935] Alvestrand, H., "A Mission Statement for the IETF", |  | [RFC3935] Alvestrand, H., "A Mission Statement for the IETF", |
| BCP 95, RFC 3935, DOI 10.17487/RFC3935, October 2004, |  | BCP 95, RFC 3935, DOI 10.17487/RFC3935, October 2004, |
| <https://www.rfc-editor.org/info/rfc3935>. |  | <https://www.rfc-editor.org/info/rfc3935>. |
| [RFC6973] Cooper, A., Tschofenig, H., Aboba, B., Peterson, J., |  | [RFC6973] Cooper, A., Tschofenig, H., Aboba, B., Peterson, J., |
| Morris, J., Hansen, M., and R. Smith, "Privacy |  | Morris, J., Hansen, M., and R. Smith, "Privacy |
| Considerations for Internet Protocols", RFC 6973, |  | Considerations for Internet Protocols", RFC 6973, |
| DOI 10.17487/RFC6973, July 2013, |  | DOI 10.17487/RFC6973, July 2013, |
| <https://www.rfc-editor.org/info/rfc6973>. |  | <https://www.rfc-editor.org/info/rfc6973>. |
| skipping to change at page 8, line 17 ¶ |  | skipping to change at page 8, line 9 ¶ |
| [1] https://github.com/mnot/I-D/labels/for-the-users |  | [1] https://github.com/mnot/I-D/labels/for-the-users |
| [2] https://mnot.github.io/I-D/for-the-users/ |  | [2] https://mnot.github.io/I-D/for-the-users/ |
| [3] https://github.com/mnot/I-D/commits/gh-pages/for-the-users |  | [3] https://github.com/mnot/I-D/commits/gh-pages/for-the-users |
| [4] https://datatracker.ietf.org/doc/draft-nottingham-for-the-users/ |  | [4] https://datatracker.ietf.org/doc/draft-nottingham-for-the-users/ |
| Appendix A. Acknowledgements |  | Appendix A. Acknowledgements |
| Thanks to Edward Snowden for his comments regarding the priority of |  | This document was influenced by many discussions, both inside and |
| end users at IETF93. |  | outside of the IETF and IAB. In particular, Edward Snowden's |
|  |  | comments regarding the priority of end users at IETF 93 and the |
| Thanks to the WHATWG for blazing the trail with the Priority of |  | WHATWG's Priority of Constituencies for HTML were both influential. |
| Constituencies. |  |  |
| Thanks to Harald Alvestrand for his substantial feedback and Mohamed |  | Many people gave feedback and input, including Harald Alvestrand, |
| Boucadair, Stephen Farrell, Joe Hildebrand, Lee Howard, Russ Housley, |  | Mohamed Boucadair, Stephen Farrell, Joe Hildebrand, Lee Howard, Russ |
| Niels ten Oever, Mando Rachovitsa, Martin Thomson, and Brian Trammell |  | Housley, Niels ten Oever, Mando Rachovitsa, Martin Thomson, Brian |
| for their suggestions. |  | Trammell, John Klensin, Eliot Lear, Ted Hardie, and Jari Arkko. |
| Author's Address |  | Author's Address |
| Mark Nottingham |  | Mark Nottingham |
| Email: mnot@mnot.net |  | Email: mnot@mnot.net |
| URI: https://www.mnot.net/ |  | URI: https://www.mnot.net/ |
End of changes. 20 change blocks.
| 65 lines changed or deleted |  | 55 lines changed or added |
This html diff was produced by rfcdiff 1.46. The latest version is available from http://tools.ietf.org/tools/rfcdiff/