idnits 2.17.00 (12 Aug 2021) /tmp/idnits49329/draft-dkg-hrpc-glossary-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (July 05, 2015) is 2512 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Looks like a reference, but probably isn't: '1' on line 341 Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Human Rights Protocol Considerations Research Group D. Gillmor 3 Internet-Draft ACLU 4 Intended status: Informational N. ten Oever 5 Expires: January 6, 2016 Article19 6 A. Doria 7 APC 8 July 05, 2015 10 Human Rights Protocol Considerations Glossary 11 draft-dkg-hrpc-glossary-00 13 Abstract 15 This document presents a glossary of terms used to map between 16 concepts common in human rights discussions and engineering 17 discussions. It is intended to facilitate work by the proposed Human 18 Rights Protocol Considerations research group, as well as other 19 authors within the IETF. 21 Status of This Memo 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current Internet- 29 Drafts is at http://datatracker.ietf.org/drafts/current/. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 This Internet-Draft will expire on January 6, 2016. 38 Copyright Notice 40 Copyright (c) 2015 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents 45 (http://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with respect 48 to this document. Code Components extracted from this document must 49 include Simplified BSD License text as described in Section 4.e of 50 the Trust Legal Provisions and are provided without warranty as 51 described in the Simplified BSD License. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 56 2. Glossary . . . . . . . . . . . . . . . . . . . . . . . . . . 3 57 3. Security Considerations . . . . . . . . . . . . . . . . . . . 6 58 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 59 5. Research Group Information . . . . . . . . . . . . . . . . . 6 60 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 61 6.1. Informative References . . . . . . . . . . . . . . . . . 6 62 6.2. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 8 64 1. Introduction 66 "There's a freedom about the Internet: As long as we accept the 67 rules of sending packets around, we can send packets containing 68 anything to anywhere." 70 [Berners-Lee] 72 The Human Rights Protocol Consideration Proposed Research Group aims 73 to research whether standards and protocols can enable, strengthen or 74 threaten human rights, as defined in the Universal Declaration of 75 Human Rights [UDHR] and the International Covenant ons Civil and 76 Political Rights [ICCPR], specifically, but not limited to the right 77 to freedom of expression and the right to freedom of assembly. 79 Comunications between people working on human rights and engineers 80 working on Internet protocols can be improved with a shared 81 vocabulary. 83 This document aims to provide a shared vocabulary to facilitate 84 understanding of the intersection between human rights and Internet 85 protocol design. 87 Discussion on this draft at: hrpc@irtf.org // 88 https://www.irtf.org/mailman/admindb/hrpc 90 This document builds on the previous IDs published within the 91 framework of the proposed hrpc research group [ID] 93 2. Glossary 95 In the analysis of existing RFCs central design and technical 96 concepts have been found which impact human rights. This is an 97 initial glossary of concepts that could bridge human rights discourse 98 and technical vocabulary. These definitions should be improved and 99 further aligned with existing RFCs. 101 Accessibility Full Internet Connectivity as described in [RFC4084] 102 to provide unfettered access to the Internet 104 The design of protocols, services or implementation that provide 105 an enabling environment for people with disabilities. 107 The ability to receive information available on the Internet 109 Anonymity The fact of not being identified 111 Authenticity The act of confirming the truth of an attribute of a 112 single piece of data or entity. 114 Confidentiality The non-disclosure of information to any unintended 115 person or host or party 117 Connectivity The extent to which a device or network is able to 118 reach other devices or networks to exchange data. The Internet is 119 the tool for providing global connectivity [RFC1958]. 121 Content-agnosticism Treating network traffic identically regardless 122 of content. 124 Debugging: Debugging is a methodical process of finding and reducing 125 the number of bugs, or defects, or malfunctions in a protocol or 126 its implementation, thus making it behave as expected and analyse 127 the consequences that might have emanated from the error. 128 Debugging tends to be harder when various subsystems are tightly 129 coupled, as changes in one may cause bugs to emerge in another. 130 [WP-Debugging] 132 The process through which people troubleshoot a technical issue, 133 which may include inspection of program source code or device 134 configurations. Can also include tracing or monitoring packet 135 flow. 137 Decentralized Opportunity for implementation or deployment of 138 standards, protocols or systems without a single point of control. 140 Distributed A distributed architecture is a system in which not all 141 processes reside in a single computer. 143 End-to-End The principal of extending characteristics of a protocol 144 or system as far as possible within the system. For example, end- 145 to-end instant message encryption would conceal communications 146 from one user's instant messaging application through any 147 intermediate devices and servers all the way to the recipient's 148 instant messaging application. If the message was decrypted at 149 any intermediate point-for example at a service provider-then the 150 property of end-to-end encryption would not be present. 152 One of the key architectural guidelines of the Internet is the 153 end-to-end principle in the papers by Saltzer, Reed, and Clark 154 [Saltzer] [Clark]. The end-to-end principle was originally 155 articulated as a question of where best not to put functions in a 156 communication system. Yet, in the ensuing years, it has evolved 157 to address concerns of maintaining openness, increasing 158 reliability and robustness, and preserving the properties of user 159 choice and ease of new service development as discussed by 160 Blumenthal and Clark in [Blumenthal]; concerns that were not part 161 of the original articulation of the end-to-end principle. 162 [RFC3724] 164 Federation The possibility of connecting autonomous systems into a 165 single distributed system. 167 Integrity Maintenance and assurance of the accuracy and consistency 168 of data to ensure it has not been (intentionally or 169 unintentionally) altered 171 Inter-operable A property of a documented standard or protocol which 172 allows different independent implementations to work with each 173 other without any restricted negotiation, access or functionality. 175 Internationalization The practice of the adaptation and facilitation 176 of protocols, standards, and implementation to different languages 177 and scripts. 179 Open standards Conform [RFC2606]: Various national and international 180 standards bodies, such as ANSI, ISO, IEEE, and ITU-T, develop a 181 variety of protocol and service specifications that are similar to 182 Technical Specifications defined here. National and international 183 groups also publish "implementors' agreements" that are analogous 184 to Applicability Statements, capturing a body of implementation- 185 specific detail concerned with the practical application of their 186 standards. All of these are considered to be "open external 187 standards" for the purposes of the Internet Standards Process. 189 Openness The quality of the unfiltered Internet that allows for free 190 access to other hosts 192 Permissionless innovation The freedom and ability of to freely 193 create and deploy new protocols on top of the communications 194 constructs that currently exist 196 Privacy Please see [RFC6973] 198 Reliable Reliability ensures that a protocol will execute its 199 function consistently and error resistant as described and 200 function without unexpected result. A system that is reliable 201 degenerates gracefully and will have a documented way to announce 202 degradation. It also has mechanisms to recover from failure 203 gracefully, and if applicable, allow for partial healing. 205 Resilience The maintaining of dependability and performance in the 206 face of unanticipated changes and circumstances. 208 Robust The resistance of protocols and their implementations to 209 errors, and to involuntary, legal or malicious attempts to disrupt 210 its mode of operations. 212 Scalable The ability to handle increased or decreased workloads 213 predictably within defined expectations. There should be a clear 214 definition of its scope and applicability. The limits of a 215 systems scalability should be defined. 217 Stateless / stateful In computing, a stateless protocol is a 218 communications protocol that treats each request as an independent 219 transaction that is unrelated to any previous request so that the 220 communication consists of independent pairs of request and 221 response. A stateless protocol does not require the server to 222 retain session information or status about each communications 223 partner for the duration of multiple requests. In contrast, a 224 protocol which requires keeping of the internal state on the 225 server is known as a stateful protocol. [WP-Stateless] 227 Transparent: "transparency" refers to the original Internet concept 228 of a single universal logical addressing scheme, and the 229 mechanisms by which packets may flow from source to destination 230 essentially unaltered. [RFC2775] 232 The combination of content agnosticism, connectivity, security, 233 privacy (as defined in [RFC6973], and open standards are the 234 technical principles that underlay freedom of expression on the 235 Internet. 237 ( ( End-to-End ) ) 238 ( ( Interoperability ) ) 239 ( ( Resilience ) Connectivity ) 240 ( ( Reliability ) ) = freedom of expression 241 ( ( Robustness ) ) 242 ( Privacy ) 243 ( Security ) 244 ( Content agnosticism ) 245 ( Open Standards ) 247 The combination of reliability, confidentiality, integrity, 248 anonymity, and authenticity is what makes up security on the Internet 250 ( Reliability ) 251 security = ( Confidentiality ) 252 ( Integrity ) 253 ( Authenticity ) 254 ( Anonymity ) 256 3. Security Considerations 258 As this draft concerns a research document, there are no security 259 considerations. 261 4. IANA Considerations 263 This document has no actions for IANA. 265 5. Research Group Information 267 The discussion list for the IRTF Human Rights Protocol Considerations 268 proposed working group is located at the e-mail address hrpc@ietf.org 269 [1]. Information on the group and information on how to subscribe to 270 the list is at https://www.irtf.org/mailman/listinfo/hrpc 272 Archives of the list can be found at: https://www.irtf.org/mail- 273 archive/web/hrpc/current/index.html 275 6. References 277 6.1. Informative References 279 [Berners-Lee] 280 Berners-Lee, T. and M. Fischetti, "Weaving the Web,", 281 HarperCollins p 208, 1999. 283 [Blumenthal] 284 Blumenthal, M. and D. Clark, "Rethinking the design of the 285 Internet: The end-to-end arguments vs. the brave new 286 world", ACM Transactions on Internet Technology, Vol. 1, 287 No. 1, August 2001, pp 70-109. , 2001. 289 [Clark] Clark, D., "The Design Philosophy of the DARPA Internet 290 Protocols", Proc SIGCOMM 88, ACM CCR Vol 18, Number 4, 291 August 1988, pp. 106-114. , 1988. 293 [ICCPR] United Nations General Assembly, "International Covenant 294 on Civil and Political Rights", 1976, 295 . 298 [ID] ten Oever, N., Doria, A., and J. Varon, "Proposal for 299 research on human rights protocol considerations", 2015, 300 . 302 [RFC1958] Carpenter, B., "Architectural Principles of the Internet", 303 RFC 1958, June 1996. 305 [RFC2606] Eastlake, D. and A. Panitz, "Reserved Top Level DNS 306 Names", BCP 32, RFC 2606, June 1999. 308 [RFC2775] Carpenter, B., "Internet Transparency", RFC 2775, February 309 2000. 311 [RFC3724] Kempf, J., Austein, R., and IAB, "The Rise of the Middle 312 and the Future of End-to-End: Reflections on the Evolution 313 of the Internet Architecture", RFC 3724, March 2004. 315 [RFC4084] Klensin, J., "Terminology for Describing Internet 316 Connectivity", BCP 104, RFC 4084, May 2005. 318 [RFC6973] Cooper, A., Tschofenig, H., Aboba, B., Peterson, J., 319 Morris, J., Hansen, M., and R. Smith, "Privacy 320 Considerations for Internet Protocols", RFC 6973, July 321 2013. 323 [Saltzer] Saltzer, J., Reed, D., and D. Clark, "End-to-End Arguments 324 in System Design", ACM TOCS, Vol 2, Number 4, November 325 1984, pp 277-288. , 1984. 327 [UDHR] United Nations General Assembly, "The Universal 328 Declaration of Human Rights", 1948, 329 . 331 [WP-Debugging] 332 "Debugging", n.d., . 335 [WP-Stateless] 336 "Stateless protocol", n.d., 337 . 339 6.2. URIs 341 [1] mailto:hrpc@ietf.org 343 Authors' Addresses 345 Daniel Kahn Gillmor 346 ACLU 348 EMail: dkg@fifthhorseman.net 350 Niels ten Oever 351 Article19 353 EMail: niels@article19.org 355 Avri Doria 356 APC 358 EMail: avri@apc.org