<?xml version="1.0" encoding="UTF-8"?>
  <?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?>

<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
]>

<rfc ipr="trust200902" docName="draft-nottingham-stakeholder-rights-00" category="bcp">

<?rfc toc="yes"?>
<?rfc tocindent="yes"?>
<?rfc sortrefs="yes"?>
<?rfc symrefs="yes"?>
<?rfc strict="yes"?>
<?rfc compact="yes"?>
<?rfc comments="yes"?>
<?rfc inline="yes"?>

  <front>
    <title abbrev="Stakeholder Rights">Representing Stakeholder Rights in Internet Protocols</title>

    <author initials="M." surname="Nottingham" fullname="Mark Nottingham">
      <organization></organization>
      <address>
        <email>mnot@mnot.net</email>
        <uri>http://www.mnot.net/</uri>
      </address>
    </author>

    <date year="2014"/>

    <area>General</area>
    
    <keyword>Internet-Draft</keyword>

    <abstract>


<t>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.</t>



    </abstract>


  </front>

  <middle>


<section anchor="introduction" title="Introduction">

<t>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.</t>

<t>Another way to say this is in the words of Lawrence Lessig, who said <xref target="CODELAW"/>:</t>

<t><list style='empty'>
  <t>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.</t>
</list></t>

<t><list style='empty'>
  <t>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.</t>
</list></t>

<t>This is indeed a heavy responsibility.</t>

<t>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. </t>

<t>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.</t>

<t>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.</t>

<t>In doing so, we seek to enable “the tussle” <xref target="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.</t>

<section anchor="notational-conventions" title="Notational Conventions">

<t>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
<xref target="RFC2119"/>.</t>

</section>
</section>
<section anchor="identifying-stakeholders" title="Identifying Stakeholders">

<t>Protocols MUST document relevant primary stakeholders and their interrelationships.</t>

<t>For example, HTML does so using the priority of constituencies in the HTML Design Principles
<xref target="PRIORITY"/>:</t>

<t><list style='empty'>
  <t>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.</t>
</list></t>

<t>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 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.</t>

<t>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.</t>

<t>End-user-facing application protocols MUST prioritise their users higher than any other
stakeholders.</t>

<t>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.</t>

<t>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.</t>

</section>
<section anchor="erosion-of-rights" title="Erosion of Rights">

<t>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).</t>

<t>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).</t>

<t>For example, there has been increasing pressure to change HTTP <xref target="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 publishers. Therefore, the HTTP
Working Group has refused to consider such changes.</t>

</section>
<section anchor="intermediation-and-non-stakeholders" title="Intermediation and Non-Stakeholders">

<t>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.</t>

<t>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.</t>

<t>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 <xref target="RFC6962"/> potentially adds yet another
intermediary to this protocol suite.</t>

<t>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. </t>

<t>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.</t>

</section>
<section anchor="promoting-stakeholders-as-winners" title="Promoting Stakeholders as “Winners”">

<t>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.</t>

<t>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.</t>

<t>This is the antithesis of Internetworking, and SHOULD NOT be intentionally enabled, by commission
or omission, by Internet protocols.</t>

<t>Practically speaking, this means that protocols – especially application protocols – are required
to accommodate what is commonly known as “federation”.</t>

</section>
<section anchor="iana-considerations" title="IANA Considerations">

<t>This document does not require action by IANA.</t>

</section>
<section anchor="security-considerations" title="Security Considerations">

<t>This document does not specify a protocol; however, applying its guidelines might affect security
positively or negatively for various stakeholders.</t>

</section>


  </middle>

  <back>

    <references title='Normative References'>





<reference anchor='RFC2119'>

<front>
<title abbrev='RFC Key Words'>Key words for use in RFCs to Indicate Requirement Levels</title>
<author initials='S.' surname='Bradner' fullname='Scott Bradner'>
<organization>Harvard University</organization>
<address>
<postal>
<street>1350 Mass. Ave.</street>
<street>Cambridge</street>
<street>MA 02138</street></postal>
<phone>- +1 617 495 3864</phone>
<email>sob@harvard.edu</email></address></author>
<date year='1997' month='March' />
<area>General</area>
<keyword>keyword</keyword>
<abstract>
<t>
   In many standards track documents several words are used to signify
   the requirements in the specification.  These words are often
   capitalized.  This document defines these words as they should be
   interpreted in IETF documents.  Authors who follow these guidelines
   should incorporate this phrase near the beginning of their document:

<list>
<t>
      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
      RFC 2119.
</t></list></t>
<t>
   Note that the force of these words is modified by the requirement
   level of the document in which they are used.
</t></abstract></front>

<seriesInfo name='BCP' value='14' />
<seriesInfo name='RFC' value='2119' />
<format type='TXT' octets='4723' target='http://www.rfc-editor.org/rfc/rfc2119.txt' />
<format type='HTML' octets='17970' target='http://xml.resource.org/public/rfc/html/rfc2119.html' />
<format type='XML' octets='5777' target='http://xml.resource.org/public/rfc/xml/rfc2119.xml' />
</reference>




    </references>

    <references title='Informative References'>

<reference anchor="CODELAW" target="http://harvardmagazine.com/2000/01/code-is-law-html">
  <front>
    <title>Code Is Law: On Liberty in Cyberspace</title>
    <author initials="L." surname="Lessig" fullname="Lawrence Lessig">
      <organization>Harvard Magazine</organization>
    </author>
    <date year="2000"/>
  </front>
</reference>
<reference anchor="TUSSLE" target="http://groups.csail.mit.edu/ana/Publications/PubPDFs/Tussle2002.pdf">
  <front>
    <title>Tussle in Cyberspace: Defining Tomorrow’s Internet</title>
    <author initials="D." surname="Clark" fullname="David D. Clark">
      <organization>MIT Lab for Computer Science</organization>
    </author>
    <author initials="K." surname="Sollins" fullname="Karen R. Sollins">
      <organization>MIT Lab for Computer Science</organization>
    </author>
    <author initials="J." surname="Wroclawski" fullname="John Wroclawski">
      <organization>MIT Lab for Computer Science</organization>
    </author>
    <author initials="R." surname="Braden" fullname="Robert Braden">
      <organization>USC Information Sciences Institute</organization>
    </author>
    <date year="2002"/>
  </front>
</reference>
<reference anchor="PRIORITY" target="http://www.w3.org/TR/html-design-principles/#priority-of-constituencies">
  <front>
    <title>HTML Design Principles</title>
    <author initials="A." surname="van Kesteren" fullname="Anne van Kesteren">
      <organization>Opera Software ASA</organization>
    </author>
    <author initials="M." surname="Stachowiak" fullname="Maciej Stachowiak">
      <organization>Apple Inc</organization>
    </author>
    <date year="2007" month="November"/>
  </front>
</reference>




<reference anchor='RFC6962'>

<front>
<title>Certificate Transparency</title>
<author initials='B.' surname='Laurie' fullname='B. Laurie'>
<organization /></author>
<author initials='A.' surname='Langley' fullname='A. Langley'>
<organization /></author>
<author initials='E.' surname='Kasper' fullname='E. Kasper'>
<organization /></author>
<date year='2013' month='June' />
<abstract>
<t>This document describes an experimental protocol for publicly logging the existence of Transport Layer Security (TLS) certificates as they are issued or observed, in a manner that allows anyone to audit certificate authority (CA) activity and notice the issuance of suspect certificates as well as to audit the certificate logs themselves. The intent is that eventually clients would refuse to honor certificates that do not appear in a log, effectively forcing CAs to add all issued certificates to the logs.&lt;/t>&lt;t> Logs are network services that implement the protocol operations for submissions and queries that are defined in this document.</t></abstract></front>

<seriesInfo name='RFC' value='6962' />
<format type='TXT' octets='55048' target='http://www.rfc-editor.org/rfc/rfc6962.txt' />
</reference>



<reference anchor='RFC7230'>

<front>
<title>Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing</title>
<author initials='R.' surname='Fielding' fullname='R. Fielding'>
<organization /></author>
<author initials='J.' surname='Reschke' fullname='J. Reschke'>
<organization /></author>
<date year='2014' month='June' />
<abstract>
<t>The Hypertext Transfer Protocol (HTTP) is a stateless application-level protocol for distributed, collaborative, hypertext information systems.  This document provides an overview of HTTP architecture and its associated terminology, defines the "http" and "https" Uniform Resource Identifier (URI) schemes, defines the HTTP/1.1 message syntax and parsing requirements, and describes related security concerns for implementations.</t></abstract></front>

<seriesInfo name='RFC' value='7230' />
<format type='TXT' octets='205947' target='http://www.rfc-editor.org/rfc/rfc7230.txt' />
</reference>




    </references>


<section anchor="acknowledgements" title="Acknowledgements">

<t>Thanks to Jacob Appelbaum for making the suggestion that led to this document.</t>

<t>Thanks also to the WHATWG, for blazing the trail. </t>

<t>Thanks to Joe Hildebrand and Martin Thomson for their suggestions.</t>

</section>


  </back>
</rfc>

