Internet DRAFT - draft-nottingham-stakeholder-rights
draft-nottingham-stakeholder-rights
Network Working Group M. Nottingham
Internet-Draft
Intended status: Best Current Practice October 27, 2014
Expires: April 30, 2015
Representing Stakeholder Rights in Internet Protocols
draft-nottingham-stakeholder-rights-00
Abstract
This document proposes a set of guidelines for protocol designers to
help balance concerns and conflicts between different stakeholders.
It also requires the end user to be the highest priority stakeholder
in application protocols.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on April 30, 2015.
Copyright Notice
Copyright (c) 2014 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
(http://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. Code Components extracted from this document must
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.
Nottingham Expires April 30, 2015 [Page 1]
Internet-Draft Stakeholder Rights October 2014
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Notational Conventions . . . . . . . . . . . . . . . . . 3
2. Identifying Stakeholders . . . . . . . . . . . . . . . . . . 3
3. Erosion of Rights . . . . . . . . . . . . . . . . . . . . . . 4
4. Intermediation and Non-Stakeholders . . . . . . . . . . . . . 5
5. Promoting Stakeholders as "Winners" . . . . . . . . . . . . . 5
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6
7. Security Considerations . . . . . . . . . . . . . . . . . . . 6
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 6
8.1. Normative References . . . . . . . . . . . . . . . . . . 6
8.2. Informative References . . . . . . . . . . . . . . . . . 6
Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 7
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 7
1. Introduction
The IETF is often reluctant to make decisions based upon human rights
in our standards documents, for good reason. We are a technical
body, not a political one, and we do not presume to impose our values
onto the users of the Internet. Doing so would not be in the
interest of the users that we aim to protect, because it would set a
precedent that a technical body could do so. Furthermore, embedding
such value judgements in our protocols would make fragmentation of
the network - and therefore losing its embedded value as a whole -
much more likely.
Another way to say this is in the words of Lawrence Lessig, who said
[CODELAW]:
Ours is the age of cyberspace. It, too, has a regulator. This
regulator, too, threatens liberty. But so obsessed are we with
the idea that liberty means "freedom from government" that we
don't even see the regulation in this new space. We therefore
don't see the threat to liberty that this regulation presents.
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 is indeed a heavy responsibility.
Nottingham Expires April 30, 2015 [Page 2]
Internet-Draft Stakeholder Rights October 2014
That said, it is increasingly difficult to avoid making ethical,
societal and even legal judgements in protocol design, as the
Internet has become pervasive in many societies.
A recurring theme in this area is balancing the rights of various
stakeholders, such as (but not limited to) end users, network
operators, equipment vendors, implementers, content owners,
governments, employers, and parents.
This document proposes a set of guidelines regarding these
"stakeholder rights" issues that protocol designers ought to consider
as new protocols are created, as well as when existing protocols are
extended and evolved.
In doing so, we seek to enable "the tussle" [TUSSLE]; that is, our
protocols (and therefore the code that implements them) should not
attempt to establish the law, as Lessig says, but instead aspire to
serve as a level, well-defined playing field where society's back-
and-forth over the Internet can take place.
1.1. Notational Conventions
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119].
2. Identifying Stakeholders
Protocols MUST document relevant primary stakeholders and their
interrelationships.
For example, HTML does so using the priority of constituencies in the
HTML Design Principles [PRIORITY]:
In case of conflict, consider users over authors over implementors
over specifiers over theoretical purity. In other words costs or
difficulties to the user should be given more weight than costs to
authors; which in turn should be given more weight than costs to
implementors; which should be given more weight than costs to
authors of the spec itself, which should be given more weight than
those proposing changes for theoretical reasons alone. Of course,
it is preferred to make things better for multiple constituencies
at once.
Note how the relative priority of stakeholders is explicit; this is
intentional and encouraged. Some stakeholders - especially end
users, for protocols where they are involved - can withdraw their
support when their rights are not respected, leading to a failed
Nottingham Expires April 30, 2015 [Page 3]
Internet-Draft Stakeholder Rights October 2014
effort. In other situations, while a stakeholder believes that their
rights are fundamental, this may not be necessary for the successful
deployment of the protocol, and therefore their rights are not
proportionate to those who are.
Likewise, the responsibilities of, or expectations upon, stakeholders
can vary greatly. For example, end users of Web browsers cannot be
reasonably expected to make informed decisions about security, and
therefore design decisions there are biased towards default security.
When applicable, the expectations upon a stakeholder SHOULD be
documented.
End-user-facing application protocols MUST prioritise their users
higher than any other stakeholders.
Extensions to existing protocols MUST document how they interact with
the extended protocol's stakeholders. If the extended protocol's
stakeholders are not yet documented, the extension MAY estimate its
impact, in coordination with that protocol's community and the IESG.
The burden of this documentation need not be high; if HTML can do it
in a paragraph, so can most protocols. While it might be appropriate
in a separate document (e.g., a requirements or use cases draft) or
the protocol specification itself, documenting stakeholders in the WG
charter has considerable benefits, since it clarifies their
relationships up-front.
3. Erosion of Rights
Changes in the use, deployment patterns, legal context, or other
factors of a protocol can bring pressure to re-balance the priorities
and rights of existing stakeholders, or insert new ones (usually,
when a protocol is either extended or evolved).
Such changes MUST NOT violate documented rights of existing
stakeholders, or those reasonably assumed by existing stakeholders,
without informed consent. Note that this may preclude the change
completely, as it is often impossible to gain the informed consent of
a large or diffuse group of stakeholders (e.g., end users).
For example, there has been increasing pressure to change HTTP
[RFC7230] to make it more amenable to optimisation, filtering, and
interposition of other value-added services, especially in the face
of more pervasive encryption (denoted by HTTPS URIs). However, since
HTTPS is already defined as a two-party protocol with end-to-end
encryption, inserting a third party in any fashion would violate the
rights of two existing stakeholders; end users and content
Nottingham Expires April 30, 2015 [Page 4]
Internet-Draft Stakeholder Rights October 2014
publishers. Therefore, the HTTP Working Group has refused to
consider such changes.
4. Intermediation and Non-Stakeholders
In protocol design, intermediation is often thought of as "those
parties on the direct path between two people attempting to
communicate"; e.g., middleboxes, proxies and so on.
When discussing stakeholder rights, this definition is expanded to
include those parties that have the ability to prevent or control
communication between two parties. This naturally includes
middleboxes, but can also include third parties not directly on-path.
For example, HTTP has on-path intermediaries (proxies, gateways,
etc.), but also off-path intermediaries, in the form of the DNS
registrar, the DNS server, and also the Certificate Authority if TLS
is in use. Certificate Transparency [RFC6962] potentially adds yet
another intermediary to this protocol suite.
While there might be a good technical reason to interpose such an
intermediary, it also introduces a new stakeholder, and thus needs to
be done with due consideration of the impact on other stakeholders.
Therefore, such intermediation SHOULD NOT be accommodated without
purpose in Internet protocols, and protocol revisions (including
extensions) MUST carefully weigh when new levels of intermediation
are added. When a stakeholder has a role as an intermediary (in this
sense), it MUST be documented.
5. Promoting Stakeholders as "Winners"
Protocols often engender network effects. For example, e-mail is
only useful when the parties you wish to communicate with also have
e-mail; when more people have e-mail, its value is greatly increased.
However, network effects can also be captured by a single party, in a
"winner take all" market. For example, if we mint a new
communication protocol without providing a way for two independent
users to identify each other and rendezvous, it creates a condition
whereby a rendezvous service can create network effects and possibly
"win" the market.
This is the antithesis of Internetworking, and SHOULD NOT be
intentionally enabled, by commission or omission, by Internet
protocols.
Nottingham Expires April 30, 2015 [Page 5]
Internet-Draft Stakeholder Rights October 2014
Practically speaking, this means that protocols - especially
application protocols - are required to accommodate what is commonly
known as "federation".
6. IANA Considerations
This document does not require action by IANA.
7. Security Considerations
This document does not specify a protocol; however, applying its
guidelines might affect security positively or negatively for various
stakeholders.
8. References
8.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
8.2. Informative References
[CODELAW] Lessig, L., "Code Is Law: On Liberty in Cyberspace", 2000,
<http://harvardmagazine.com/2000/01/code-is-law-html>.
[PRIORITY]
van Kesteren, A. and M. Stachowiak, "HTML Design
Principles", November 2007, <http://www.w3.org/TR/
html-design-principles/#priority-of-constituencies>.
[RFC6962] Laurie, B., Langley, A., and E. Kasper, "Certificate
Transparency", RFC 6962, June 2013.
[RFC7230] Fielding, R. and J. Reschke, "Hypertext Transfer Protocol
(HTTP/1.1): Message Syntax and Routing", RFC 7230, June
2014.
[TUSSLE] Clark, D., Sollins, K., Wroclawski, J., and R. Braden,
"Tussle in Cyberspace: Defining Tomorrow's Internet",
2002,
<http://groups.csail.mit.edu/ana/Publications/PubPDFs/
Tussle2002.pdf>.
Nottingham Expires April 30, 2015 [Page 6]
Internet-Draft Stakeholder Rights October 2014
Appendix A. Acknowledgements
Thanks to Jacob Appelbaum for making the suggestion that led to this
document.
Thanks also to the WHATWG, for blazing the trail.
Thanks to Joe Hildebrand and Martin Thomson for their suggestions.
Author's Address
Mark Nottingham
Email: mnot@mnot.net
URI: http://www.mnot.net/
Nottingham Expires April 30, 2015 [Page 7]
