< draft-irtf-hrpc-guidelines-12.txt   draft-irtf-hrpc-guidelines-13.txt >
Human Rights Protocol Considerations Research Group G. Grover Human Rights Protocol Considerations Research Group G. Grover
Internet-Draft Centre for Internet and Society Internet-Draft Centre for Internet and Society
Updates: 8280 (if approved) N. ten Oever Updates: 8280 (if approved) N. ten Oever
Intended status: Informational University of Amsterdam Intended status: Informational University of Amsterdam
Expires: 29 July 2022 25 January 2022 Expires: 29 September 2022 28 March 2022
Guidelines for Human Rights Protocol and Architecture Considerations Guidelines for Human Rights Protocol and Architecture Considerations
draft-irtf-hrpc-guidelines-12 draft-irtf-hrpc-guidelines-13
Abstract Abstract
This document sets guidelines for human rights considerations for This document sets guidelines for human rights considerations for
developers working on network protocols and architectures, similar to developers working on network protocols and architectures, similar to
the work done on the guidelines for privacy considerations [RFC6973]. the work done on the guidelines for privacy considerations [RFC6973].
This is an updated version of the guidelines for human rights This is an updated version of the guidelines for human rights
considerations in [RFC8280]. considerations in [RFC8280].
This document is not an Internet Standards Track specification; it is This document is not an Internet Standards Track specification; it is
skipping to change at page 1, line 47 skipping to change at page 1, line 47
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on 29 July 2022. This Internet-Draft will expire on 29 September 2022.
Copyright Notice Copyright Notice
Copyright (c) 2022 IETF Trust and the persons identified as the Copyright (c) 2022 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/ Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document. license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights Please review these documents carefully, as they describe your rights
skipping to change at page 3, line 8 skipping to change at page 3, line 8
4.16. Outcome Transparency . . . . . . . . . . . . . . . . . . 21 4.16. Outcome Transparency . . . . . . . . . . . . . . . . . . 21
4.17. Adaptability . . . . . . . . . . . . . . . . . . . . . . 22 4.17. Adaptability . . . . . . . . . . . . . . . . . . . . . . 22
4.18. Accessibility . . . . . . . . . . . . . . . . . . . . . . 23 4.18. Accessibility . . . . . . . . . . . . . . . . . . . . . . 23
4.19. Decentralization . . . . . . . . . . . . . . . . . . . . 24 4.19. Decentralization . . . . . . . . . . . . . . . . . . . . 24
4.20. Remedy . . . . . . . . . . . . . . . . . . . . . . . . . 25 4.20. Remedy . . . . . . . . . . . . . . . . . . . . . . . . . 25
4.21. Misc. considerations . . . . . . . . . . . . . . . . . . 25 4.21. Misc. considerations . . . . . . . . . . . . . . . . . . 25
5. Document Status . . . . . . . . . . . . . . . . . . . . . . . 26 5. Document Status . . . . . . . . . . . . . . . . . . . . . . . 26
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 26 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 26
7. Security Considerations . . . . . . . . . . . . . . . . . . . 26 7. Security Considerations . . . . . . . . . . . . . . . . . . . 26
8. Research Group Information . . . . . . . . . . . . . . . . . 27 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26
9. Informative References . . . . . . . . . . . . . . . . . . . 27 9. Research Group Information . . . . . . . . . . . . . . . . . 27
10. Informative References . . . . . . . . . . . . . . . . . . . 27
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 33 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 33
1. Introduction 1. Introduction
This document outlines a set of human rights protocol considerations This document outlines a set of human rights protocol considerations
for protocol developers. It provides questions engineers should ask for protocol developers. It provides questions engineers should ask
themselves when developing or improving protocols if they want to themselves when developing or improving protocols if they want to
understand how their decisions can potentially influence the exercise understand how their decisions can potentially influence the exercise
of human rights on the Internet. It should be noted that the impact of human rights on the Internet. It should be noted that the impact
of a protocol cannot solely be deduced from its design, but its usage of a protocol cannot solely be deduced from its design, but its usage
skipping to change at page 8, line 8 skipping to change at page 8, line 8
4.1. Connectivity 4.1. Connectivity
Question(s): Does your protocol add application-specific functions to Question(s): Does your protocol add application-specific functions to
intermediary nodes? Could this functionality be added to end nodes intermediary nodes? Could this functionality be added to end nodes
instead of intermediary nodes? instead of intermediary nodes?
Is your protocol optimized for low bandwidth and high latency Is your protocol optimized for low bandwidth and high latency
connections? Could your protocol also be developed in a stateless connections? Could your protocol also be developed in a stateless
manner? manner?
Explanation: The end-to-end principle [Saltzer] holds that 'the Explanation: The end-to-end principle [Saltzer] holds that certain
intelligence is end to end rather than hidden in the network' functions can and should be performed at 'ends' of the network.
[RFC1958]. Generally speaking, it is easier to attain reliability of [RFC1958] states "that in very general terms, the community believes
data transmissions with computation at endpoints rather than at that the goal is connectivity [...] and the intelligence is end to
intermediary nodes. end rather than hidden in the network." Generally speaking, it is
easier to attain reliability of data transmissions with computation
at endpoints rather than at intermediary nodes.
Also considering the fact that network quality and conditions vary Also considering the fact that network quality and conditions vary
across geography and time, it is also important to design protocols across geography and time, it is also important to design protocols
such that they are reliable even on low bandwidth and high latency such that they are reliable even on low bandwidth and high latency
connections. connections.
Example: Encrypting connections, like done with HTTPS, can add a Example: Encrypting connections, like done with HTTPS, can add a
significant network overhead and consequently make web resources less significant network overhead and consequently make web resources less
accessible to those with low bandwidth and/or high latency accessible to those with low bandwidth and/or high latency
connections. [HTTPS-REL] Encrypting traffic is a net positive for connections. [HTTPS-REL] Encrypting traffic is a net positive for
skipping to change at page 25, line 15 skipping to change at page 25, line 15
* Right to freedom of expression * Right to freedom of expression
* Right to freedom of assembly and association * Right to freedom of assembly and association
4.20. Remedy 4.20. Remedy
Question(s): Can your protocol facilitate a negatively impacted Question(s): Can your protocol facilitate a negatively impacted
party's right to remedy without disproportionately impacting other party's right to remedy without disproportionately impacting other
parties' human rights, especially their right to privacy? parties' human rights, especially their right to privacy?
Explanation: Access to remedy may help victims of human rights Explanation: Providing access to remedy by states and corporations is
violations in seeking justice, or allow law enforcement agencies to a part of the UN Guiding Principles on Business and Human Rights
identify a possible violator. However, such mechanisms may impede [UNGP]. Access to remedy may help victims of human rights violations
the exercise of the right to privacy. The former Special Rapporteur in seeking justice, or allow law enforcement agencies to identify a
for Freedom of Expression has also argued that anonymity is an possible violator. However, mechanisms in protocols that try to
inherent part of freedom of expression [Kaye]. Considering the enable 'attribution' to individuals will impede the exercise of the
potential adverse impact of attribution on the right to privacy and right to privacy. The former Special Rapporteur for Freedom of
freedom of expression, enabling attribution on an individual level is Expression has also argued that anonymity is an inherent part of
most likely not consistent with human rights. However, providing freedom of expression [Kaye]. Considering the potential adverse
access to remedy by states and corporations is an inherent part of impact of attribution on the right to privacy and freedom of
the UN Guiding Principles on Business and Human Rights [UNGP]. expression, enabling attribution on an individual level is most
likely not consistent with human rights.
Example: Adding personal identifiable information to data streams
might help in identifying a violator of human rights and provide
access to remedy, but this would disproportionally affect all users
right to privacy, anonymous expression, and association.
Impacts: Impacts:
* Right to remedy * Right to remedy
* Right to security * Right to security
* Right to privacy * Right to privacy
4.21. Misc. considerations 4.21. Misc. considerations
skipping to change at page 26, line 19 skipping to change at page 26, line 23
architectures and other Internet-Drafts and RFCs. architectures and other Internet-Drafts and RFCs.
6. Acknowledgements 6. Acknowledgements
Thanks to: Thanks to:
* Corinne Cath-Speth for work on [RFC8280]. * Corinne Cath-Speth for work on [RFC8280].
* Theresa Engelhard, Joe Hall, Avri Doria, Joey Salazar, Corinne * Theresa Engelhard, Joe Hall, Avri Doria, Joey Salazar, Corinne
Cath-Speth, Farzaneh Badii, Sandra Braman, Colin Perkins, John Cath-Speth, Farzaneh Badii, Sandra Braman, Colin Perkins, John
Curran, Mallory Knodel, and the hrpc list for reviews and Curran, Eliot Lear, Mallory Knodel, and the hrpc list for reviews
suggestions. and suggestions.
* Individuals who conducted human rights reviews for their work and * Individuals who conducted human rights reviews for their work and
feedback: Amelia Andersdotter, Beatrice Martini, Karan Saini and feedback: Amelia Andersdotter, Beatrice Martini, Karan Saini and
Shivan Kaul Sahib. Shivan Kaul Sahib.
7. Security Considerations 7. Security Considerations
Article three of the Universal Declaration of Human Rights reads: Article three of the Universal Declaration of Human Rights reads:
"Everyone has the right to life, liberty and security of person.". "Everyone has the right to life, liberty and security of person.".
This article underlines the importance of security and its This article underlines the importance of security and its
skipping to change at page 26, line 42 skipping to change at page 26, line 46
indivisible, interrelated and interdependent, security is also indivisible, interrelated and interdependent, security is also
closely linked to other human rights and freedoms. This document closely linked to other human rights and freedoms. This document
seeks to strengthen human rights, freedoms, and security by relating seeks to strengthen human rights, freedoms, and security by relating
and translating these concepts to concepts and practices as they are and translating these concepts to concepts and practices as they are
used in Internet protocol and architecture development. The aim of used in Internet protocol and architecture development. The aim of
this is to secure human right and thereby improve the susainability, this is to secure human right and thereby improve the susainability,
usability, and effectiveness of the network. The document seeks to usability, and effectiveness of the network. The document seeks to
achieve this by providing guidelines as done in section three of this achieve this by providing guidelines as done in section three of this
document. document.
IANA Considerations ================https://github.com/IRTF- 8. IANA Considerations
HRPC/drafts/commit/5500acb24a3ddcd1bad2c474cea81f0b298e83e1=== This
document has no actions for IANA.
8. Research Group Information This document has no actions for IANA.
9. Research Group Information
The discussion list for the IRTF Human Rights Protocol Considerations The discussion list for the IRTF Human Rights Protocol Considerations
Research Group is located at the e-mail address hrpc@ietf.org Research Group is located at the e-mail address hrpc@ietf.org
(mailto:hrpc@ietf.org). Information on the group and information on (mailto:hrpc@ietf.org). Information on the group and information on
how to subscribe to the list is at how to subscribe to the list is at
https://www.irtf.org/mailman/listinfo/hrpc https://www.irtf.org/mailman/listinfo/hrpc
(https://www.irtf.org/mailman/listinfo/hrpc) (https://www.irtf.org/mailman/listinfo/hrpc)
Archives of the list can be found at: https://www.irtf.org/mail- Archives of the list can be found at: https://www.irtf.org/mail-
archive/web/hrpc/current/index.html (https://www.irtf.org/mail- archive/web/hrpc/current/index.html (https://www.irtf.org/mail-
archive/web/hrpc/current/index.html) archive/web/hrpc/current/index.html)
9. Informative References 10. Informative References
[arkkoetal] [arkkoetal]
Arkko, J., Trammell, B., Notthingham, M., Huitema, C., Arkko, J., Trammell, B., Notthingham, M., Huitema, C.,
Thomson, M., Tantsure, J., and N. ten Oever, Thomson, M., Tantsure, J., and N. ten Oever,
"Considerations on Internet Consolidation and the Internet "Considerations on Internet Consolidation and the Internet
Architecture", 2019, Architecture", 2019,
<https://datatracker.ietf.org/doc/html/draft-arkko-iab- <https://datatracker.ietf.org/doc/html/draft-arkko-iab-
internet-consolidation-02>. internet-consolidation-02>.
[BCP72] IETF, "Guidelines for Writing RFC Text on Security [BCP72] IETF, "Guidelines for Writing RFC Text on Security
 End of changes. 10 change blocks. 
28 lines changed or deleted 37 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/