tech-invite   World Map
3GPP     Specs     Glossaries     Architecture     IMS     UICC       IETF     RFCs     Groups     SIP     ABNFs       Search     Home

RFC 8280

Informational
Pages: 81
Top     in Index     Prev     Next
in Group Index     Prev in Group     No Next: Highest Number in Group     Group: IRTF

Research into Human Rights Protocol Considerations

Part 1 of 4, p. 1 to 15
None       Next Section

 


Top       ToC       Page 1 
Internet Research Task Force (IRTF)                         N. ten Oever
Request for Comments: 8280                                    ARTICLE 19
Category: Informational                                          C. Cath
ISSN: 2070-1721                                Oxford Internet Institute
                                                            October 2017


           Research into Human Rights Protocol Considerations

Abstract

   This document aims to propose guidelines for human rights
   considerations, similar to the work done on the guidelines for
   privacy considerations (RFC 6973).  The other parts of this document
   explain the background of the guidelines and how they were developed.

   This document is the first milestone in a longer-term research
   effort.  It has been reviewed by the Human Rights Protocol
   Considerations (HRPC) Research Group and also by individuals from
   outside the research group.

Status of This Memo

   This document is not an Internet Standards Track specification; it is
   published for informational purposes.

   This document is a product of the Internet Research Task Force
   (IRTF).  The IRTF publishes the results of Internet-related research
   and development activities.  These results might not be suitable for
   deployment.  This RFC represents the consensus of the Human Rights
   Protocol Considerations Research Group of the Internet Research Task
   Force (IRTF).  Documents approved for publication by the IRSG are not
   a candidate for any level of Internet Standard; see Section 2 of
   RFC 7841.

   Information about the current status of this document, any errata,
   and how to provide feedback on it may be obtained at
   https://www.rfc-editor.org/info/rfc8280.

Top      ToC       Page 2 
Copyright Notice

   Copyright (c) 2017 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
   (https://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.

Top       Page 3 
Table of Contents

   1. Introduction ....................................................4
   2. Vocabulary Used .................................................6
   3. Research Questions .............................................12
   4. Literature and Discussion Review ...............................12
   5. Methodology ....................................................15
      5.1. Data Sources ..............................................17
           5.1.1. Discourse Analysis of RFCs .........................17
           5.1.2. Interviews with Members of the IETF Community ......17
           5.1.3. Participant Observation in Working Groups ..........17
      5.2. Data Analysis Strategies ..................................18
           5.2.1. Identifying Qualities of Technical Concepts
                  That Relate to Human Rights ........................18
           5.2.2. Relating Human Rights to Technical Concepts ........20
           5.2.3. Mapping Cases of Protocols, Implementations, and
                  Networking Paradigms That Adversely Impact Human
                  Rights or Are Enablers Thereof .....................21
   6. Model for Developing Human Rights Protocol Considerations ......40
      6.1. Human Rights Threats ......................................40
      6.2. Guidelines for Human Rights Considerations ................42
           6.2.1. Connectivity .......................................43
           6.2.2. Privacy ............................................43
           6.2.3. Content Agnosticism ................................44
           6.2.4. Security ...........................................45
           6.2.5. Internationalization ...............................46
           6.2.6. Censorship Resistance ..............................47
           6.2.7. Open Standards .....................................48
           6.2.8. Heterogeneity Support ..............................50
           6.2.9. Anonymity ..........................................51
           6.2.10. Pseudonymity ......................................51
           6.2.11. Accessibility .....................................53
           6.2.12. Localization ......................................53
           6.2.13. Decentralization ..................................54
           6.2.14. Reliability .......................................55
           6.2.15. Confidentiality ...................................56
           6.2.16. Integrity .........................................58
           6.2.17. Authenticity ......................................59
           6.2.18. Adaptability ......................................60
           6.2.19. Outcome Transparency ..............................61
   7. Security Considerations ........................................61
   8. IANA Considerations ............................................61
   9. Research Group Information .....................................62
   10. Informative References ........................................62
   Acknowledgements ..................................................80
   Authors' Addresses ................................................81

Top      ToC       Page 4 
1.  Introduction

   "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."  [Berners-Lee]

   "The Internet isn't value-neutral, and neither is the IETF."
   [RFC3935]

   The ever-growing interconnectedness of the Internet and society
   increases the impact of the Internet on the lives of individuals.
   Because of this, the design and development of the Internet
   infrastructure also have a growing impact on society.  This has led
   to a broad recognition that human rights [UDHR] [ICCPR] [ICESCR] have
   a role in the development and management of the Internet [UNGA2013]
   [NETmundial].  It has also been argued that the Internet should be
   strengthened as an enabling environment for human rights [Brown].

   This document aims to (1) expose the relationship between protocols
   and human rights, (2) propose possible guidelines to protect the
   Internet as an enabling environment for human rights in future
   protocol development, in a manner similar to the work done for
   privacy considerations [RFC6973], and (3) increase the awareness, in
   both the human rights community and the technical community, of the
   importance of the technical workings of the Internet and its impact
   on human rights.

   Document authors who want to apply this work to their own can go
   directly to Section 6 of this document.

   Open, secure, and reliable connectivity is necessary (although not
   sufficient) to exercise human rights such as freedom of expression
   and freedom of association [FOC], as defined in the Universal
   Declaration of Human Rights [UDHR].  The purpose of the Internet is
   to be a global network of networks that provides unfettered
   connectivity to all users, and for any content [RFC1958].  This
   objective of stimulating global connectivity contributes to the
   Internet's role as an enabler of human rights.  The Internet has
   given people a platform to exchange opinions and gather information;
   it has enabled people of different backgrounds and genders to
   participate in the public debate; it has also allowed people to
   congregate and organize.  Next to that, the strong commitment to
   security [RFC1984] [RFC3365] and privacy [RFC6973] [RFC7258] in the
   Internet's architectural design contributes to the strengthening of
   the Internet as an enabling environment for human rights.  One could
   even argue that the Internet is not only an enabler of human rights
   but that human rights lie at the base of, and are ingrained in, the
   architecture of the networks that make up the Internet.  Internet

Top      ToC       Page 5 
   connectivity increases the capacity for individuals to exercise their
   rights; the core of the Internet -- its architectural design -- is
   therefore closely intertwined with the human rights framework
   [CathFloridi].  The quintessential link between the Internet's
   infrastructure and human rights has been argued by many.  [Bless1],
   for instance, argues that "to a certain extent, the Internet and its
   protocols have already facilitated the realization of human rights,
   e.g., the freedom of assembly and expression.  In contrast, measures
   of censorship and pervasive surveillance violate fundamental human
   rights."  [DeNardis15] argues that "Since the first hints of Internet
   commercialization and internationalization, the IETF has supported
   strong security in protocol design and has sometimes served as a
   force resisting protocol-enabled surveillance features."  By doing
   so, the IETF enabled the manifestation of the right to privacy,
   through the Internet's infrastructure.  Additionally, access to
   freely available information gives people access to knowledge that
   enables them to help satisfy other human rights; as such, the
   Internet increasingly becomes a precondition for human rights rather
   than a supplement.

   Human rights can be in conflict with each other, such as the right to
   freedom of expression and the right to privacy.  In such cases, the
   different affected rights need to be balanced.  To do this, it is
   crucial that the impacts on rights are clearly documented in order to
   mitigate potential harm.  This research aims to ultimately contribute
   to making that process tangible and practical for protocol
   developers.  Technology can never be fully equated with a human
   right.  Whereas a specific technology might be a strong enabler of a
   specific human right, it might have an adverse impact on another
   human right.  In this case, decisions on design and deployment need
   to take this into account.

   The open nature of the initial technical design and its open
   standards, as well as developments like open source, fostered freedom
   of communication.  What emerged was a network of networks that could
   enable everyone to connect and to exchange data, information, and
   code.  For many, enabling such connections became a core value.
   However, as the scale and the commercialization of the Internet grew,
   topics like access, rights, and connectivity have been forced to
   compete with other values.  Therefore, important characteristics of
   the Internet that enable human rights might be degraded if they're
   not properly defined, described, and protected as such.  Conversely,
   not protecting characteristics that enable human rights could also
   result in (partial) loss of functionality and connectivity, along
   with other inherent parts of the Internet's architecture of networks.
   New protocols, particularly those that upgrade the core
   infrastructure of the network, should be designed to continue to
   enable fundamental human rights.

Top      ToC       Page 6 
   The IETF has produced guidelines and procedures to ensure and
   galvanize the privacy of individuals and security of the network in
   protocol development.  This document aims to explore the possibility
   of developing similar procedures for guidelines for human rights
   considerations to ensure that protocols developed in the IETF do not
   have an adverse impact on the realization of human rights on the
   Internet.  By carefully considering the answers to the questions
   posed in Section 6 of this document, document authors should be
   (1) able to produce a comprehensive analysis that can serve as the
   basis for discussion on whether the protocol adequately protects
   against specific human rights threats and (2) potentially stimulated
   to think about alternative design choices.

   This document was developed within the framework of the Human Rights
   Protocol Considerations (HRPC) Research Group, based on discussions
   on the HRPC mailing list (Section 9); this document was also
   extensively discussed during HRPC sessions.  This document has
   received eleven in-depth reviews on the mailing list, and it received
   many comments from inside and outside the IRTF and IETF communities.

2.  Vocabulary Used

   In the discussion of human rights and Internet architecture, concepts
   developed in computer science, networking, law, policy-making, and
   advocacy are coming together [Dutton] [Kaye] [Franklin] [RFC1958].
   The same concepts might have a very different meaning and
   implications in other areas of expertise.  In order to foster a
   constructive interdisciplinary debate and minimize differences in
   interpretation, the following glossary is provided.  It builds as
   much as possible on existing definitions; when definitions were not
   available in IETF documents, definitions were taken from other
   Standards Development Organizations (SDOs) or academic literature.

   Accessibility:  "Full Internet Connectivity", as described in
      [RFC4084], to provide unfettered access to the Internet.

      The design of protocols, services, or implementations that provide
      an enabling environment for people with disabilities.

      The ability to receive information available on the Internet.

   Anonymity:  The condition of an identity being unknown or concealed
      [RFC4949].

   Anonymous:  A state of an individual in which an observer or attacker
      cannot identify the individual within a set of other individuals
      (the anonymity set) [RFC6973].

Top      ToC       Page 7 
   Authenticity:  The property of being genuine and able to be verified
      and be trusted [RFC4949].

   Blocking:  The practice of preventing access to resources in the
      aggregate [RFC7754].  Both blocking and filtering can be
      implemented at the level of "services" (web hosting or video
      streaming, for example) or at the level of particular "content"
      [RFC7754].

   Censorship:  Technical mechanisms, including both blocking and
      filtering, that certain political or private actors around the
      world use to block or degrade Internet traffic.  For further
      details on the various elements of Internet censorship, see
      [Hall].

   Censorship resistance:  Methods and measures to mitigate Internet
      censorship.

   Confidentiality:  The property that data is not disclosed to system
      entities unless they have been authorized to know the data
      [RFC4949].

   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 [RFC1958].  Different
      types of connectivity are further specified in [RFC4084].

      The end-to-end principle, interoperability, distributed
      architecture, resilience, reliability, and robustness in
      combination constitute the enabling factors that result in
      connectivity to, and on, the Internet.

   Content agnosticism:  Treating network traffic identically regardless
      of content.

   Decentralized:  Implementation or deployment of standards, protocols,
      or systems without one single point of control.

   End-to-end principle:  The principle that application-specific
      functions should not be embedded into the network and thus stay at
      the endpoints.  In many cases, especially when dealing with
      failures, the right decisions can only be made with the
      corresponding application-specific knowledge, which is available
      at endpoints not in the network.

      The end-to-end principle is one of the key architectural
      guidelines of the Internet.  The argument in favor of the
      end-to-end approach to system design is laid out in the

Top      ToC       Page 8 
      fundamental papers by Saltzer, Reed, and Clark [Saltzer] [Clark].
      In these papers, the authors argue in favor of radical
      simplification: system designers should only build the essential
      and shared functions into the network, as most functions can only
      be implemented at network endpoints.  Building features into the
      network for the benefit of certain applications will come at the
      expense of others.  As such, in general system designers should
      attempt to steer clear of building anything into the network that
      is not a bare necessity for its functioning.  Following the
      end-to-end principle is crucial for innovation, as it makes
      innovation at the edges possible without having to make changes to
      the network, and it protects the robustness of the network.
      [RFC2775] further elaborates on various aspects of end-to-end
      connectivity.

   Federation:  The possibility of connecting autonomous and possibly
      centralized systems into a single system without a central
      authority.

   Filtering:  The practice of preventing access to specific resources
      within an aggregate [RFC7754].

   Heterogeneity:  "The Internet is characterized by heterogeneity on
      many levels: devices and nodes, router scheduling algorithms and
      queue management mechanisms, routing protocols, levels of
      multiplexing, protocol versions and implementations, underlying
      link layers (e.g., point-to-point, multi-access links, wireless,
      FDDI, etc.), in the traffic mix and in the levels of congestion at
      different times and places.  Moreover, as the Internet is composed
      of autonomous organizations and internet service providers, each
      with their own separate policy concerns, there is a large
      heterogeneity of administrative domains and pricing structures."
      [FIArch]

      As a result, per [FIArch], the heterogeneity principle proposed in
      [RFC1958] needs to be supported by design.

   Human rights:  Principles and norms that are indivisible,
      interrelated, unalienable, universal, and mutually reinforcing.
      Human rights have been codified in national and international
      bodies of law.  The Universal Declaration of Human Rights [UDHR]
      is the most well-known document in the history of human rights.
      The aspirations from [UDHR] were later codified into treaties such
      as the International Covenant on Civil and Political Rights
      [ICCPR] and the International Covenant on Economic, Social and
      Cultural Rights [ICESCR], after which signatory countries were

Top      ToC       Page 9 
      obliged to reflect them in their national bodies of law.  There is
      also a broad recognition that not only states have obligations
      vis-a-vis human rights, but non-state actors do as well.

   Integrity:  The property that data has not been changed, destroyed,
      or lost in an unauthorized or accidental manner [RFC4949].

   Internationalization (i18n):  The practice of making protocols,
      standards, and implementations usable in different languages and
      scripts (see Section 6.2.12 ("Localization")).

      "In the IETF, 'internationalization' means to add or improve the
      handling of non-ASCII text in a protocol" [RFC6365].

      A different perspective, more appropriate to protocols that are
      designed for global use from the beginning, is the definition used
      by the World Wide Web Consortium (W3C) [W3Ci18nDef]:
      "Internationalization is the design and development of a product,
      application or document content that enables easy localization for
      target audiences that vary in culture, region, or language."

      Many protocols that handle text only handle one charset
      (US-ASCII), or they leave the question of encoding up to local
      guesswork (which leads, of course, to interoperability problems)
      [RFC3536].  If multiple charsets are permitted, they must be
      explicitly identified [RFC2277].  Adding non-ASCII text to a
      protocol allows the protocol to handle more scripts, hopefully all
      scripts in use in the world.  In today's world, that is normally
      best accomplished by allowing Unicode encoded in UTF-8 only,
      thereby shifting conversion issues away from ad hoc choices.

   Interoperable:  A property of a documented standard or protocol that
      allows different independent implementations to work with each
      other without any restriction on functionality.

   Localization (l10n):  The practice of translating an implementation
      to make it functional in a specific language or for users in a
      specific locale (see Section 6.2.5 ("Internationalization")).

      (cf. [RFC6365]): The process of adapting an internationalized
      application platform or application to a specific cultural
      environment.  In localization, the same semantics are preserved
      while the syntax may be changed [FRAMEWORK].

      Localization is the act of tailoring an application for a
      different language, script, or culture.  Some internationalized
      applications can handle a wide variety of languages.  Typical
      users only understand a small number of languages, so the program

Top      ToC       Page 10 
      must be tailored to interact with users in just the languages they
      know.  The major work of localization is translating the user
      interface and documentation.  Localization involves not only
      changing the language interaction but also other relevant changes,
      such as display of numbers, dates, currency, and so on.  The
      better internationalized an application is, the easier it is to
      localize it for a particular language and character-encoding
      scheme.

   Open standards:  Conform with [RFC2026], which states the following:
      "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."

   Openness:  Absence of centralized points of control -- "a feature
      that is assumed to make it easy for new users to join and new uses
      to unfold" [Brown].

   Permissionless innovation:  The freedom and ability to freely create
      and deploy new protocols on top of the communications constructs
      that currently exist.

   Privacy:  The right of an entity (normally a person), acting on its
      own behalf, to determine the degree to which it will interact with
      its environment, including the degree to which the entity is
      willing to share its personal information with others [RFC4949].

      The right of individuals to control or influence what information
      related to them may be collected and stored, and by whom and to
      whom that information may be disclosed.

      Privacy is a broad concept relating to the protection of
      individual or group autonomy and the relationship between an
      individual or group and society, including government, companies,
      and private individuals.  It is often summarized as "the right to
      be left alone", but it encompasses a wide range of rights,
      including protections from intrusions into family and home life,
      control of sexual and reproductive rights, and communications
      secrecy.  It is commonly recognized as a core right that underpins
      human dignity and other values such as freedom of association and
      freedom of speech.

Top      ToC       Page 11 
      The right to privacy is also recognized in nearly every national
      constitution and in most international human rights treaties.  It
      has been adjudicated upon by both international and regional
      bodies.  The right to privacy is also legally protected at the
      national level through provisions in civil and/or criminal codes.

   Reliability:  Ensures that a protocol will execute its function
      consistently as described and function without unexpected results.
      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 [dict].

   Resilience:  The maintaining of dependability and performance in the
      face of unanticipated changes and circumstances [Meyer].

   Robustness:  The resistance of protocols and their implementations to
      errors, and resistance to involuntary, legal, or malicious
      attempts to disrupt their modes of operation [RFC760] [RFC791]
      [RFC793] [RFC1122].  Or, framed more positively, a system can
      provide functionality consistently and without errors despite
      involuntary, legal, or malicious attempts to disrupt its mode of
      operation.

   Scalability:  The ability to handle increased or decreased system
      parameters (number of end systems, users, data flows, routing
      entries, etc.) predictably within defined expectations.  There
      should be a clear definition of its scope and applicability.  The
      limits of a system's scalability should be defined.  Growth or
      shrinkage of these parameters is typically considered by orders of
      magnitude.

   Strong encryption / cryptography:  Used to describe a cryptographic
      algorithm that would require a large amount of computational power
      to defeat it [RFC4949].  In the modern usage of the definition of
      "strong encryption", this refers to an amount of computing power
      currently not available, not even to major state-level actors.

   Transparency:  In this context, linked to the comprehensibility of a
      protocol in relation to the choices it makes for users, protocol
      developers, and implementers, and to its outcome.

      Outcome transparency is linked to the comprehensibility of the
      effects of a protocol in relation to the choices it makes for
      users, protocol developers, and implementers, including the
      comprehensibility of possible unintended consequences of protocol
      choices (e.g., lack of authenticity may lead to lack of integrity
      and negative externalities).

Top      ToC       Page 12 
3.  Research Questions

   The Human Rights Protocol Considerations (HRPC) Research Group in the
   Internet Research Task Force (IRTF) embarked on its mission to answer
   the following two questions, which are also the main two questions
   that this document seeks to answer:

   1.  How can Internet protocols and standards impact human rights, by
       either enabling them or creating a restrictive environment?

   2.  Can guidelines be developed to improve informed and transparent
       decision-making about the potential impact of protocols on human
       rights?

4.  Literature and Discussion Review

   Protocols and standards are regularly seen as merely performing
   technical functions.  However, these protocols and standards do not
   exist outside of their technical context, nor do they exist outside
   of their political, historical, economic, legal, or cultural context.
   This is best exemplified by the way in which some Internet processes
   and protocols have become part and parcel of political processes and
   public policies: one only has to look at the IANA transition,
   [RFC7258] ("Pervasive Monitoring Is an Attack"), or global innovation
   policy, for concrete examples [DeNardis15].  According to [Abbate],
   "protocols are politics by other means."  This statement would
   probably not garner IETF consensus, but it nonetheless reveals that
   protocols are based on decision-making, most often by humans.  In
   this process, the values and ideas about the role that a particular
   technology should perform in society are embedded into the design.
   Often, these design decisions are partly "purely technical" and
   partly inspired by a certain world view of how technology should
   function that is inspired by personal, corporate, and political
   views.  Within the community of IETF participants, there is a strong
   desire to solve technical problems and to minimize engagement with
   political processes and non-protocol-related political issues.

   Since the late 1990s, a burgeoning group of academics and
   practitioners researched questions surrounding the societal impact of
   protocols, as well as the politics of protocols.  These studies vary
   in focus and scope: some focus on specific standards [Davidson-etal]
   [Musiani]; others look into the political, legal, commercial, or
   social impact of protocols [BrownMarsden] [Lessig] [Mueller]; and yet
   others look at how the engineers' personal set of values get
   translated into technology [Abbate] [CathFloridi] [DeNardis15]
   [WynsbergheMoura].

Top      ToC       Page 13 
   Commercial and political influences on the management of the
   Internet's infrastructure are well documented in the academic
   literature and will thus not be discussed here; see [Benkler],
   [Brown-etal], [DeNardis15], [Lessig], [Mueller], and [Zittrain].  It
   is sufficient to say that the IETF community consistently tries to
   push back against the standardization of surveillance and certain
   other issues that negatively influence an end user's experience of,
   and trust in, the Internet [DeNardis14].  The role that human rights
   play in engineering, infrastructure maintenance, and protocol design
   is much less clear.

   It is very important to understand how protocols and standards impact
   human rights, in particular because SDOs are increasingly becoming
   venues where social values (like human rights) are discussed,
   although often from a technological point of view.  These SDOs are
   becoming a new focal point for discussions about "values by design"
   and the role of technical engineers in protecting or enabling human
   rights [Brown-etal] [Clark-etal] [DeNardis14] [CathFloridi] [Lessig]
   [Rachovitsa].

   In the academic literature, five clear positions can be discerned in
   relation to the role of human rights in protocol design and how to
   account for these human rights in protocol development: Clark
   et al. [Clark-etal] argue that there is a need to design "for
   variation in outcome -- so that the outcome can be different in
   different places, and the tussle takes place within the design (...)"
   [as] "Rigid designs will be broken; designs that permit variation
   will flex under pressure and survive."  They hold that human rights
   should not be hard-coded into protocols for three reasons: First, the
   rights in the UDHR are not absolute.  Second, technology is not the
   only tool in the tussle over human rights.  And last but not least,
   it is dangerous to make promises that can't be kept.  The open nature
   of the Internet will never, they argue, be enough to fully protect
   individuals' human rights.

   Conversely, Brown et al. [Brown-etal] state that "some key, universal
   values -- of which the UDHR is the most legitimate expression --
   should be baked into the architecture at design time."  They argue
   that design choices have offline consequences and are able to shape
   the power positions of groups or individuals in society.  As such,
   the individuals making these technical decisions have a moral
   obligation to take into account the impact of their decisions on
   society and, by extension, human rights.  Brown et al. recognize that
   values and the implementation of human rights vary across the globe.
   Yet they argue that all members of the United Nations have found
   "common agreement on the values proclaimed in the Universal
   Declaration of Human Rights.  In looking for the most legitimate set

Top      ToC       Page 14 
   of global values to embed in the future Internet architectures, the
   UDHR has the democratic assent of a significant fraction of the
   planet's population, through their elected representatives."

   The main disagreement between these two academic positions lies
   mostly in the question of whether (1) a particular value system
   should be embedded into the Internet's architectures or (2) the
   architectures need to account for a varying set of values.

   A third position, which is similar to that of Brown et al., is taken
   by [Broeders], in which Broeders argues that "we must find ways to
   continue guaranteeing the overall integrity and functionality of the
   public core of the Internet."  He argues that the best way to do this
   is by declaring the backbone of the Internet -- which includes the
   TCP/IP protocol suite, numerous standards, the Domain Name System
   (DNS), and routing protocols -- a common public good.  This is a
   different approach than those of [Clark-etal] and [Brown-etal]
   because Broeders does not suggest that social values should (or
   should not) be explicitly coded into the Internet, but rather that
   the existing infrastructure should be seen as an entity of public
   value.

   Bless and Orwat [Bless2] represent a fourth position.  They argue
   that it is too early to make any definitive claims but that there is
   a need for more careful analysis of the impact of protocol design
   choices on human rights.  They also argue that it is important to
   search for solutions that "create awareness in the technical
   community about impact of design choices on social values" and "work
   towards a methodology for co-design of technical and institutional
   systems."

   Berners-Lee and Halpin [BernersLeeHalpin] represent a fifth position.
   They argue that the Internet could lead to even newer capacities, and
   these capacities may over time be viewed as new kinds of rights.  For
   example, Internet access may be viewed as a human right in and of
   itself if it is taken to be a precondition for other rights, even if
   it could not have been predicted at the time that the UDHR was
   written (after the end of World War II).

   It is important to contextualize the technical discussion with the
   academic discussions on this issue.  The academic discussions are
   also important to document, as they inform the position of the
   authors of this document.  The research group's position is that
   hard-coding human rights into protocols is complicated and changes
   with the context.  At this point, it is difficult to say whether or
   not hard-coding human rights into protocols is wise or feasible.
   Additionally, there are many human rights, but not all are relevant
   for information and communications technologies (ICTs).  A partial

Top      ToC       Page 15 
   catalog (with references to sources) of human rights related to ICTs
   can be found in [Hill2014].  It is, however, important to make
   conscious and explicit design decisions that take into account the
   human rights protocol considerations guidelines developed below.
   This will contribute to the understanding of the impact that
   protocols can have on human rights, for both developers and users.
   In addition, it contributes to (1) the careful consideration of the
   impact that a specific protocol might have on human rights and
   (2) the dissemination of the practice of documenting protocol design
   decisions related to human rights.

   Pursuant to the principle of constant change, because the function
   and scope of the Internet evolve, so does the role of the IETF in
   developing standards.  Internet Standards are adopted based on a
   series of criteria, including high technical quality, support by
   community consensus, and their overall benefit to the Internet.  The
   latter calls for an assessment of the interests of all affected
   parties and the specifications' impact on the Internet's users.  In
   this respect, the effective exercise of the human rights of the
   Internet users is a relevant consideration that needs to be
   appreciated in the standardization process insofar as it is directly
   linked to the reliability and core values of the Internet [RFC1958]
   [RFC2775] [RFC3439] [RFC3724].

   This document details the steps taken in the research into human
   rights protocol considerations by the HRPC Research Group to clarify
   the relationship between technical concepts used in the IETF and
   human rights.  This document sets out some preliminary steps and
   considerations for engineers to take into account when developing
   standards and protocols.



(page 15 continued on part 2)

Next Section