<?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-dkg-hrpc-glossary-00" category="info">

<?rfc rfcedstyle="yes"?>
<?rfc toc="yes"?>
<?rfc tocindent="yes"?>
<?rfc sortrefs="yes"?>
<?rfc symrefs="yes"?>
<?rfc strict="yes"?>
<?rfc comments="yes"?>
<?rfc inline="yes"?>
<?rfc text-list-symbols="-o*+"?>

  <front>
    <title abbrev="hrpcg">Human Rights Protocol Considerations Glossary</title>

    <author initials="D.K." surname="Gillmor" fullname="Daniel Kahn Gillmor">
      <organization>ACLU</organization>
      <address>
        <email>dkg@fifthhorseman.net</email>
      </address>
    </author>
    <author initials="N." surname="ten Oever" fullname="Niels ten Oever">
      <organization>Article19</organization>
      <address>
        <email>niels@article19.org</email>
      </address>
    </author>
    <author initials="A." surname="Doria" fullname="Avri Doria">
      <organization>APC</organization>
      <address>
        <email>avri@apc.org</email>
      </address>
    </author>

    <date year="2015" month="July" day="05"/>

    <area>General</area>
    <workgroup>Human Rights Protocol Considerations Research Group</workgroup>
    <keyword>Internet-Draft</keyword>

    <abstract>


<t>This document presents a glossary of terms used to map between
concepts common in human rights discussions and engineering
discussions.  It is intended to facilitate work by the proposed Human
Rights Protocol Considerations research group, as well as other
authors within the IETF.</t>



    </abstract>


  </front>

  <middle>


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

<figure><artwork><![CDATA[
"There's a freedom about the Internet: As long as we accept the
   rules of sending packets around, we can send packets containing
   anything to anywhere."
]]></artwork></figure>

<t><xref target="Berners-Lee"/></t>

<t>The Human Rights Protocol Consideration Proposed Research Group aims
to research whether standards and protocols can enable, strengthen or
threaten human rights, as defined in the Universal Declaration of
Human Rights <xref target="UDHR"/> and the International Covenant ons Civil and
Political Rights <xref target="ICCPR"/>, specifically, but not limited to the
right to freedom of expression and the right to freedom of assembly.</t>

<t>Comunications between people working on human rights and engineers
working on Internet protocols can be improved with a shared vocabulary.</t>

<t>This document aims to provide a shared vocabulary to facilitate
understanding of the intersection between human rights and Internet
protocol design.</t>

<t>Discussion on this draft at: hrpc@irtf.org // https://www.irtf.org/mailman/admindb/hrpc</t>

<t>This document builds on the previous IDs published within the framework of the proposed hrpc research group <xref target="ID"/></t>

</section>
<section anchor="glossary" title="Glossary">

<t>In the analysis of existing RFCs central design and technical concepts have been found which impact human rights.  This is an initial glossary of concepts that could bridge human rights discourse and technical vocabulary. These definitions should be improved and further aligned with existing RFCs.</t>

<t><list style="hanging">
  <t hangText='Accessibility'>
  Full Internet Connectivity as described in <xref target="RFC4084"/> to provide unfettered access to the Internet </t>
  <t>The design of protocols, services or implementation that provide an enabling environment for people with disabilities.</t>
  <t>The ability to receive information available on the Internet</t>
  <t hangText='Anonymity'>
  The fact of not being identified</t>
  <t hangText='Authenticity'>
  The act of confirming the truth of an attribute of a single piece of data or entity.</t>
  <t hangText='Confidentiality'>
  The non-disclosure of information to any unintended person or host or party</t>
  <t hangText='Connectivity'>
  The extent to which a device or network is able to reach other devices or networks to exchange data. The Internet is the tool for providing global connectivity <xref target="RFC1958"/>. </t>
  <t hangText='Content-agnosticism'>
  Treating network traffic identically regardless of content.</t>
  <t hangText='Debugging:'>
  Debugging is a methodical process of finding and reducing the number of bugs, or defects, or malfunctions in a protocol or its implementation, thus making it behave as expected and analyse the consequences that might have emanated from the error. Debugging tends to be harder when various subsystems are tightly coupled, as changes in one may cause bugs to emerge in another. <xref target="WP-Debugging"/></t>
  <t>The process through which people troubleshoot a technical issue, which may include inspection of program source code or device configurations. Can also include tracing or monitoring packet flow.</t>
  <t hangText='Decentralized'>
  Opportunity for implementation or deployment of standards, protocols or systems without a single point of control.</t>
  <t hangText='Distributed'>
  A distributed architecture is a system in which not all processes reside in a single computer.</t>
  <t hangText='End-to-End'>
  The principal of extending characteristics of a protocol or system as far as possible within the system. For example, end-to-end instant message encryption would conceal communications from one user’s instant messaging application through any intermediate devices and servers all the way to the recipient’s instant messaging application. If the message was decrypted at any intermediate point–for example at a service provider–then the property of end-to-end encryption would not be present.</t>
  <t>One of the key architectural guidelines of the Internet is the end-to-end principle in the papers by Saltzer, Reed, and Clark <xref target="Saltzer"/> <xref target="Clark"/>. The end-to-end principle was originally articulated as a question of where best not to put functions in a communication system. Yet, in the ensuing years, it has evolved to address concerns of maintaining openness, increasing reliability and robustness, and preserving the properties of user choice and ease of new service development as discussed by Blumenthal and Clark in <xref target="Blumenthal"/>; concerns that were not part of the original articulation of the end-to-end principle. <xref target="RFC3724"/></t>
  <t hangText='Federation'>
  The possibility of connecting autonomous systems into a single distributed system.</t>
  <t hangText='Integrity'>
  Maintenance and assurance of the accuracy and consistency of data to ensure it has not been (intentionally or unintentionally) altered</t>
  <t hangText='Inter-operable'>
  A property of a documented standard or protocol which allows different independent implementations to work with each other without any restricted negotiation, access or functionality. </t>
  <t hangText='Internationalization'>
  The practice of the adaptation and facilitation of protocols, standards, and implementation to different languages and scripts.</t>
  <t hangText='Open standards'>
  Conform  <xref target="RFC2606"/>: Various national and international standards bodies, such as ANSI,
    ISO, IEEE, and ITU-T, develop a variety of protocol and service
    specifications that are similar to Technical Specifications
    defined here.  National and international groups also publish
    “implementors’ agreements” that are analogous to Applicability
    Statements, capturing a body of implementation-specific detail
    concerned with the practical application of their standards.  All
    of these are considered to be “open external standards” for the
    purposes of the Internet Standards Process.</t>
  <t hangText='Openness'>
  The quality of the unfiltered Internet that allows for free access to other hosts</t>
  <t hangText='Permissionless innovation'>
  The freedom and ability of to freely create and deploy new protocols on top of the communications constructs that currently exist</t>
  <t hangText='Privacy'>
  Please see <xref target=" RFC6973 "/></t>
  <t hangText='Reliable'>
  Reliability ensures that a protocol will execute its function consistently and error resistant as described and function without unexpected result. A system that is reliable degenerates gracefully and will have a documented way to announce degradation.  It also has mechanisms to recover from failure gracefully, and if applicable, allow for partial healing. </t>
  <t hangText='Resilience'>
  The maintaining of dependability and performance in the face of unanticipated changes and circumstances.</t>
  <t hangText='Robust'>
  The resistance of protocols and their implementations to errors, and to involuntary, legal or malicious attempts to disrupt its mode of operations.</t>
  <t hangText='Scalable'>
  The ability to handle increased or decreased workloads predictably within defined expectations. There should be a clear definition of its scope and applicability.  The limits of a systems scalability should be defined. </t>
  <t hangText='Stateless / stateful '>
  In computing, a stateless protocol is a communications protocol that treats each request as an independent transaction that is unrelated to any previous request so that the communication consists of independent pairs of request and response. A stateless protocol does not require the server to retain session information or status about each communications partner for the duration of multiple requests. In contrast, a protocol which requires keeping of the internal state on the server is known as a stateful protocol. <xref target="WP-Stateless"/></t>
  <t hangText='Transparent:'>
  “transparency” refers to the original Internet concept of a single universal logical addressing scheme, and the mechanisms by which packets may flow from source to destination essentially unaltered. <xref target="RFC2775"/></t>
</list></t>

<t>The combination of content agnosticism, connectivity, security, privacy (as defined in <xref target="RFC6973"/>, and open standards are the technical principles that underlay freedom of expression on the Internet.</t>

<figure><artwork><![CDATA[
  (  ( End-to-End      )               )                            
 (  (  Interoperability )               )                           
(   (  Resilience       )  Connectivity  )                          
(   (  Reliability      )                )   = freedom of expression
(    ( Robustness      )                 )                          
(              Privacy                   )                          
(              Security                  )                           
 (             Content agnosticism      )
  (	       Open Standards          )                            
]]></artwork></figure>

<t>The combination of reliability, confidentiality, integrity, anonymity, and authenticity is what makes up security on the Internet</t>

<figure><artwork><![CDATA[
             ( Reliability    ) 	
security =  (  Confidentiality )	  
            (  Integrity       )
            (  Authenticity    )
             ( Anonymity      )
]]></artwork></figure>

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

<t>As this draft concerns a research document, there are no security considerations.</t>

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

<t>This document has no actions for IANA.</t>

</section>
<section anchor="research-group-information" title="Research Group Information">

<t>The discussion list for the IRTF Human Rights Protocol Considerations
proposed working group is located at the e-mail address
<eref target="mailto:hrpc@ietf.org">hrpc@ietf.org</eref>. Information on the group and information on how to
subscribe to the list is at
<eref target="https://www.irtf.org/mailman/listinfo/hrpc">https://www.irtf.org/mailman/listinfo/hrpc</eref></t>

<t>Archives of the list can be found at:
<eref target="https://www.irtf.org/mail-archive/web/hrpc/current/index.html">https://www.irtf.org/mail-archive/web/hrpc/current/index.html</eref></t>

</section>


  </middle>

  <back>


    <references title='Informative References'>





<reference anchor='RFC1958'>

<front>
<title>Architectural Principles of the Internet</title>
<author initials='B.' surname='Carpenter' fullname='Brian E. Carpenter'>
<organization>CERN, European Laboratory for Particle Physics</organization>
<address>
<postal>
<street>1211 Geneva 23</street>
<country>CH</country></postal>
<phone>+41 22 7674967</phone>
<facsimile>+41 22 7677155</facsimile>
<email>brian@dxcoms.cern.ch</email></address></author>
<date year='1996' month='June' />
<abstract>
<t>The Internet and its architecture have grown in evolutionary fashion from modest beginnings, rather than from a Grand Plan. While this process of evolution is one of the main reasons for the technology's success, it nevertheless seems useful to record a snapshot of the current principles of the Internet architecture. This is intended for general guidance and general interest, and is in no way intended to be a formal or invariant reference model.</t></abstract></front>

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



<reference anchor='RFC2606'>

<front>
<title>Reserved Top Level DNS Names</title>
<author initials='D.E.' surname='Eastlake' fullname='Donald E. Eastlake 3rd'>
<organization>IBM</organization>
<address>
<postal>
<street>65 Shindegan Hill Road</street>
<street>RR #1</street>
<city>Carmel</city>
<region>NY</region>
<code>10512</code>
<country>US</country></postal>
<phone>+1 914 276 1668</phone>
<facsimile>+1 914 784 3833</facsimile>
<email>dee3@us.ibm.com</email></address></author>
<author initials='A.' surname='Panitz' fullname='Aliza R. Panitz'>
<organization />
<address>
<postal>
<street>500 Stamford Dr. No. 310</street>
<city>Newark</city>
<region>DE</region>
<code>19711</code>
<country>US</country></postal>
<phone>+1 302 738 1554</phone>
<email>buglady@fuschia.net</email></address></author>
<date year='1999' month='June' />
<abstract>
<t>To reduce the likelihood of conflict and confusion, a few top level domain names are reserved for use in private testing, as examples in documentation, and the like.  In addition, a few second level domain names reserved for use as examples are documented.</t></abstract></front>

<seriesInfo name='BCP' value='32' />
<seriesInfo name='RFC' value='2606' />
<format type='TXT' octets='8008' target='http://www.rfc-editor.org/rfc/rfc2606.txt' />
</reference>



<reference anchor='RFC2775'>

<front>
<title>Internet Transparency</title>
<author initials='B.E.' surname='Carpenter' fullname='Brian E. Carpenter'>
<organization>IBM c/o iCAIR</organization>
<address>
<postal>
<street>1890 Maple Avenue</street>
<street>Suite 150</street>
<city>Evanston</city>
<region>IL</region>
<code>60201</code>
<country>US</country></postal>
<email>brian@icair.org</email></address></author>
<date year='2000' month='February' />
<abstract>
<t>This document describes the current state of the Internet from the architectural viewpoint, concentrating on issues of end-to-end connectivity and transparency. It concludes with a summary of some major architectural alternatives facing the Internet network layer.</t>
<t>This document was used as input to the IAB workshop on the future of the network layer held in July 1999. For this reason, it does not claim to be complete and definitive, and it refrains from making recommendations.</t></abstract></front>

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



<reference anchor='RFC3724'>

<front>
<title>The Rise of the Middle and the Future of End-to-End: Reflections on the Evolution of the Internet Architecture</title>
<author initials='J.' surname='Kempf' fullname='J. Kempf'>
<organization /></author>
<author initials='R.' surname='Austein' fullname='R. Austein'>
<organization /></author>
<author>
<organization>IAB</organization></author>
<date year='2004' month='March' />
<abstract>
<t>The end-to-end principle is the core architectural guideline of the Internet.  In this document, we briefly examine the development of the end-to-end principle as it has been applied to the Internet architecture over the years.  We discuss current trends in the evolution of the Internet architecture in relation to the end-to-end principle, and try to draw some conclusion about the evolution of the end-to-end principle, and thus for the Internet architecture which it supports, in light of these current trends.  This memo provides information for the Internet community.</t></abstract></front>

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



<reference anchor='RFC4084'>

<front>
<title>Terminology for Describing Internet Connectivity</title>
<author initials='J.' surname='Klensin' fullname='J. Klensin'>
<organization /></author>
<date year='2005' month='May' />
<abstract>
<t>As the Internet has evolved, many types of arrangements have been advertised and sold as "Internet connectivity".  Because these may differ significantly in the capabilities they offer, the range of options, and the lack of any standard terminology, the effort to distinguish between these services has caused considerable consumer confusion.  This document provides a list of terms and definitions that may be helpful to providers, consumers, and, potentially, regulators in clarifying the type and character of services being offered.  This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.</t></abstract></front>

<seriesInfo name='BCP' value='104' />
<seriesInfo name='RFC' value='4084' />
<format type='TXT' octets='24522' target='http://www.rfc-editor.org/rfc/rfc4084.txt' />
</reference>



<reference anchor='RFC6973'>

<front>
<title>Privacy Considerations for Internet Protocols</title>
<author initials='A.' surname='Cooper' fullname='A. Cooper'>
<organization /></author>
<author initials='H.' surname='Tschofenig' fullname='H. Tschofenig'>
<organization /></author>
<author initials='B.' surname='Aboba' fullname='B. Aboba'>
<organization /></author>
<author initials='J.' surname='Peterson' fullname='J. Peterson'>
<organization /></author>
<author initials='J.' surname='Morris' fullname='J. Morris'>
<organization /></author>
<author initials='M.' surname='Hansen' fullname='M. Hansen'>
<organization /></author>
<author initials='R.' surname='Smith' fullname='R. Smith'>
<organization /></author>
<date year='2013' month='July' />
<abstract>
<t>This document offers guidance for developing privacy considerations for inclusion in protocol specifications.  It aims to make designers, implementers, and users of Internet protocols aware of privacy-related design choices.  It suggests that whether any individual RFC warrants a specific privacy considerations section will depend on the document's content.</t></abstract></front>

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


<reference anchor="UDHR" target="http://www.un.org/en/documents/udhr/">
  <front>
    <title>The Universal Declaration of Human Rights</title>
    <author >
      <organization>United Nations General Assembly</organization>
    </author>
    <date year="1948"/>
  </front>
</reference>
<reference anchor="ICCPR" target="http://www.ohchr.org/EN/ProfessionalInterest/Pages/CCPR.aspx">
  <front>
    <title>International Covenant on Civil and Political Rights</title>
    <author >
      <organization>United Nations General Assembly</organization>
    </author>
    <date year="1976"/>
  </front>
</reference>
<reference anchor="Berners-Lee" >
  <front>
    <title>Weaving the Web,</title>
    <author initials="T." surname="Berners-Lee">
      <organization></organization>
    </author>
    <author initials="M." surname="Fischetti">
      <organization></organization>
    </author>
    <date year="1999"/>
  </front>
  <seriesInfo name="HarperCollins" value="p 208"/>
</reference>
<reference anchor="Saltzer" >
  <front>
    <title>End-to-End Arguments in System Design</title>
    <author initials="J.H." surname="Saltzer">
      <organization></organization>
    </author>
    <author initials="D.P." surname="Reed">
      <organization></organization>
    </author>
    <author initials="D.D." surname="Clark">
      <organization></organization>
    </author>
    <date year="1984"/>
  </front>
  <seriesInfo name="ACM TOCS, Vol 2, Number 4, November 1984, pp 277-288." value=""/>
</reference>
<reference anchor="Clark" >
  <front>
    <title>The Design Philosophy of the DARPA Internet Protocols</title>
    <author initials="D." surname="Clark">
      <organization></organization>
    </author>
    <date year="1988"/>
  </front>
  <seriesInfo name="Proc SIGCOMM 88, ACM CCR Vol 18, Number 4, August 1988, pp. 106-114." value=""/>
</reference>
<reference anchor="Blumenthal" >
  <front>
    <title>Rethinking the design of the Internet: The end-to-end arguments vs. the brave new world</title>
    <author initials="M." surname="Blumenthal">
      <organization></organization>
    </author>
    <author initials="D.D." surname="Clark">
      <organization></organization>
    </author>
    <date year="2001"/>
  </front>
  <seriesInfo name="ACM Transactions on Internet Technology, Vol. 1, No. 1, August 2001, pp 70-109." value=""/>
</reference>
<reference anchor="WP-Stateless" target="https://en.wikipedia.org/wiki/Stateless_protocol">
  <front>
    <title>Stateless protocol</title>
    <author >
      <organization></organization>
    </author>
    <date year="n.d."/>
  </front>
</reference>
<reference anchor="WP-Debugging" target="https://en.wikipedia.org/wiki/Debugging">
  <front>
    <title>Debugging</title>
    <author >
      <organization></organization>
    </author>
    <date year="n.d."/>
  </front>
</reference>
<reference anchor="ID" target="http://tools.ietf.org/html/draft-doria-hrpc-proposal">
  <front>
    <title>Proposal for research on human rights protocol considerations</title>
    <author initials="N." surname="ten Oever">
      <organization></organization>
    </author>
    <author initials="A." surname="Doria">
      <organization></organization>
    </author>
    <author initials="J." surname="Varon">
      <organization></organization>
    </author>
    <date year="2015"/>
  </front>
</reference>


    </references>



  </back>
</rfc>

