Network Working Group                                      M. Nottingham
Intended status: Best Current Practice                  October 27, 2014
Expires: April 30, 2015

         Representing Stakeholder Rights in Internet Protocols


   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

   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
   ( 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

      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",
   document are to be interpreted as described in [RFC2119].

2.  Identifying Stakeholders

   Protocols MUST document relevant primary stakeholders and their

   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

   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

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

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,

              van Kesteren, A. and M. Stachowiak, "HTML Design
              Principles", November 2007, <

   [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

   [TUSSLE]   Clark, D., Sollins, K., Wroclawski, J., and R. Braden,
              "Tussle in Cyberspace: Defining Tomorrow's Internet",

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

   Thanks also to the WHATWG, for blazing the trail.

   Thanks to Joe Hildebrand and Martin Thomson for their suggestions.

Author's Address

   Mark Nottingham


Nottingham               Expires April 30, 2015                 [Page 7]