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