idnits 2.17.1 draft-dkg-hrpc-glossary-01.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 (October 16, 2015) is 3108 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Looks like a reference, but probably isn't: '1' on line 446 -- Obsolete informational reference (is this intentional?): RFC 226 (Obsoleted by RFC 247) -- Obsolete informational reference (is this intentional?): RFC 760 (Obsoleted by RFC 791) -- Obsolete informational reference (is this intentional?): RFC 793 (Obsoleted by RFC 9293) Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 5 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: April 18, 2016 Article19 6 A. Doria 7 APC 8 October 16, 2015 10 Human Rights Protocol Considerations Glossary 11 draft-dkg-hrpc-glossary-01 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 April 18, 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 . . . . . . . . . . . . . . . . . . . 7 58 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 59 5. Research Group Information . . . . . . . . . . . . . . . . . 8 60 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 61 6.1. Informative References . . . . . . . . . . . . . . . . . 8 62 6.2. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 10 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 condition of an identity being unknown or concealed. 110 [RFC4949] 112 Anonymous A state of an individual in which an observer or attacker 113 cannot identify the individual within a set of other individuals 114 (the anonymity set). [RFC6973] 116 Authenticity The act of confirming the truth of an attribute of a 117 single piece of data or entity. 119 Censorship resistance Methods and measures to prevent Internet 120 censorship. 122 Confidentiality The non-disclosure of information to any unintended 123 person or host or party 125 Connectivity The extent to which a device or network is able to 126 reach other devices or networks to exchange data. The Internet is 127 the tool for providing global connectivity [RFC1958]. 129 Content-agnosticism Treating network traffic identically regardless 130 of content. 132 Debugging Debugging is a methodical process of finding and reducing 133 the number of bugs, or defects, or malfunctions in a protocol or 134 its implementation, thus making it behave as expected and analyse 135 the consequences that might have emanated from the error. 136 Debugging tends to be harder when various subsystems are tightly 137 coupled, as changes in one may cause bugs to emerge in another. 138 [WP-Debugging] 139 The process through which people troubleshoot a technical issue, 140 which may include inspection of program source code or device 141 configurations. Can also include tracing or monitoring packet 142 flow. 144 Decentralized Opportunity for implementation or deployment of 145 standards, protocols or systems without one single point of 146 control. 148 End-to-End The principal of extending characteristics of a protocol 149 or system as far as possible within the system. For example, end- 150 to-end instant message encryption would conceal communications 151 from one user's instant messaging application through any 152 intermediate devices and servers all the way to the recipient's 153 instant messaging application. If the message was decrypted at 154 any intermediate point-for example at a service provider-then the 155 property of end-to-end encryption would not be present. 157 One of the key architectural guidelines of the Internet is the 158 end-to-end principle in the papers by Saltzer, Reed, and Clark 159 [Saltzer] [Clark]. The end-to-end principle was originally 160 articulated as a question of where best not to put functions in a 161 communication system. Yet, in the ensuing years, it has evolved 162 to address concerns of maintaining openness, increasing 163 reliability and robustness, and preserving the properties of user 164 choice and ease of new service development as discussed by 165 Blumenthal and Clark in [Blumenthal]; concerns that were not part 166 of the original articulation of the end-to-end principle. 167 [RFC3724] 169 communication that takes place between communication end-points of 170 the same physical or logical functional level 172 Federation The possibility of connecting autonomous systems into a 173 single distributed system. 175 Heterogenity The Internet is characterized by heterogeneity on many 176 levels: devices and nodes, router scheduling algorithms and queue 177 management mechanisms, routing protocols, levels of multiplexing, 178 protocol versions and implementations, underlying link layers 179 (e.g., point-to-point, multi-access links, wireless, FDDI, etc.), 180 in the traffic mix and in the levels of congestion at different 181 times and places. Moreover, as the Internet is composed of 182 autonomous organizations and internet service providers, each with 183 their own separate policy concerns, there is a large heterogeneity 184 of administrative domains and pricing structures. As a result, 185 heterogeneity principle is proposed in [RFC1958] to be supported 186 by design. [FIArch] 188 Integrity Maintenance and assurance of the accuracy and consistency 189 of data to ensure it has not been (intentionally or 190 unintentionally) altered 192 Internet censorship Internet censorship is the intentional 193 suppression of information originating, flowing or stored on 194 systems connected to the Internet where that information is 195 relevant for decision making to some entity. [Elahi] 197 Inter-operable A property of a documented standard or protocol which 198 allows different independent implementations to work with each 199 other without any restricted negotiation, access or functionality. 201 Internet Standards as an Arena for Conflict Pursuant to the 202 principle of constant change, since the function and scope of the 203 Internet evolves, so does the role of the IETF in developing 204 standards. Internet standards are adopted on the basis of a 205 series of criteria, including high technical quality, support by 206 community consensus, and their overall benefit to the Internet. 207 The latter calls for an assessment of the interests of all 208 affected parties and the specifications' impact on the Internet's 209 users. In this respect, the effective exercise of the human 210 rights of the Internet users is a relevant consideration that 211 needs to be appreciated in the standardization process insofar as 212 it is directly linked to the reliability and core values of the 213 Internet. [RFC1958] [RFC0226] [RFC3724] 215 Internationalization (i13n) The practice of the adaptation and 216 facilitation of protocols, standards, and implementation to 217 different languages and scripts. 219 Open standards Conform [RFC2606]: Various national and international 220 standards bodies, such as ANSI, ISO, IEEE, and ITU-T, develop a 221 variety of protocol and service specifications that are similar to 222 Technical Specifications defined here. National and international 223 groups also publish "implementors' agreements" that are analogous 224 to Applicability Statements, capturing a body of implementation- 225 specific detail concerned with the practical application of their 226 standards. All of these are considered to be "open external 227 standards" for the purposes of the Internet Standards Process. 229 Openness The quality of the unfiltered Internet that allows for free 230 access to other hosts 232 Permissionless innovation The freedom and ability of to freely 233 create and deploy new protocols on top of the communications 234 constructs that currently exist 236 Privacy The right of an entity (normally a person), acting in its 237 own behalf, to determine the degree to which it will interact with 238 its environment, including the degree to which the entity is 239 willing to share its personal information with others. [RFC4949] 241 The right of individuals to control or influence what information 242 related to them may be collected and stored and by whom and to 243 whom that information may be disclosed. 245 Privacy is a broad concept relating to the protection of 246 individual autonomy and the relationship between an individual and 247 society, including government, companies and private individuals. 248 It is often summarized as "the right to be left alone" but it 249 encompasses a wide range of rights including protections from 250 intrusions into family and home life, control of sexual and 251 reproductive rights, and communications secrecy. It is commonly 252 recognized as a core right that underpins human dignity and other 253 values such as freedom of association and freedom of speech. 255 The right to privacy is also recognized in nearly every national 256 constitution and in most international human rights treaties. It has 257 been adjudicated upon both by international and regional bodies. The 258 right to privacy is also legally protected at the national level 259 through provisions in civil and/or criminal codes. 261 Reliable Reliability ensures that a protocol will execute its 262 function consistently and error resistant as described and 263 function without unexpected result. A system that is reliable 264 degenerates gracefully and will have a documented way to announce 265 degradation. It also has mechanisms to recover from failure 266 gracefully, and if applicable, allow for partial healing. 268 Resilience The maintaining of dependability and performance in the 269 face of unanticipated changes and circumstances. 271 Robustness The resistance of protocols and their implementations to 272 errors, and to involuntary, legal or malicious attempts to disrupt 273 its mode of operations. [RFC0760] [RFC0791] [RFC0793] [RFC1122] 275 Scalable The ability to handle increased or decreased workloads 276 predictably within defined expectations. There should be a clear 277 definition of its scope and applicability. The limits of a 278 systems scalability should be defined. 280 Stateless / stateful In computing, a stateless protocol is a 281 communications protocol that treats each request as an independent 282 transaction that is unrelated to any previous request so that the 283 communication consists of independent pairs of request and 284 response. A stateless protocol does not require the server to 285 retain session information or status about each communications 286 partner for the duration of multiple requests. In contrast, a 287 protocol which requires keeping of the internal state on the 288 server is known as a stateful protocol. [WP-Stateless] 290 Strong encryption / cryptography Used to describe a cryptographic 291 algorithm that would require a large amount of computational power 292 to defeat it. [RFC4949] 294 Transparent: "transparency" refers to the original Internet concept 295 of a single universal logical addressing scheme, and the 296 mechanisms by which packets may flow from source to destination 297 essentially unaltered. [RFC2775] 299 The combination of reliability, confidentiality, integrity, 300 anonymity, and authenticity is what makes up security on the Internet 302 ( Reliability ) 303 ( Confidentiality ) 304 ( Integrity ) = communication and information 305 ( Authenticity ) security (technical) 306 ( Anonymity ) 308 The combination of End-to-End, Interoperability, resilience, 309 reliability and robustness is what makes us connectivity on the 310 Internet 312 ( End-to-End ) 313 connectivity = ( Interoperability ) 314 ( Resilience ) 315 ( Reliability ) 316 ( Robustness ) 317 ( Autonomy ) 318 ( Simplicity ) 320 3. Security Considerations 322 As this draft concerns a research document, there are no security 323 considerations. 325 4. IANA Considerations 327 This document has no actions for IANA. 329 5. Research Group Information 331 The discussion list for the IRTF Human Rights Protocol Considerations 332 proposed working group is located at the e-mail address hrpc@ietf.org 333 [1]. Information on the group and information on how to subscribe to 334 the list is at https://www.irtf.org/mailman/listinfo/hrpc 336 Archives of the list can be found at: https://www.irtf.org/mail- 337 archive/web/hrpc/current/index.html 339 6. References 341 6.1. Informative References 343 [Berners-Lee] 344 Berners-Lee, T. and M. Fischetti, "Weaving the Web,", 345 HarperCollins p 208, 1999. 347 [Blumenthal] 348 Blumenthal, M. and D. Clark, "Rethinking the design of the 349 Internet: The end-to-end arguments vs. the brave new 350 world", ACM Transactions on Internet Technology, Vol. 1, 351 No. 1, August 2001, pp 70-109. , 2001. 353 [Clark] Clark, D., "The Design Philosophy of the DARPA Internet 354 Protocols", Proc SIGCOMM 88, ACM CCR Vol 18, Number 4, 355 August 1988, pp. 106-114. , 1988. 357 [Elahi] Elahi, T. and I. Goldberg, "CORDON - A taxonomy of 358 Internet Censorship Resistance Strategies", 2012, 359 . 362 [FIArch] "Future Internet Design Principles", January 2012, 363 . 366 [ICCPR] United Nations General Assembly, "International Covenant 367 on Civil and Political Rights", 1976, 368 . 371 [ID] ten Oever, N., Doria, A., and J. Varon, "Proposal for 372 research on human rights protocol considerations", 2015, 373 . 375 [RFC0226] Karp, P., "Standardization of host mnemonics", RFC 226, 376 DOI 10.17487/RFC0226, September 1971, 377 . 379 [RFC0760] Postel, J., "DoD standard Internet Protocol", RFC 760, DOI 380 10.17487/RFC0760, January 1980, 381 . 383 [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, DOI 384 10.17487/RFC0791, September 1981, 385 . 387 [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, RFC 388 793, DOI 10.17487/RFC0793, September 1981, 389 . 391 [RFC1122] Braden, R., Ed., "Requirements for Internet Hosts - 392 Communication Layers", STD 3, RFC 1122, DOI 10.17487/ 393 RFC1122, October 1989, 394 . 396 [RFC1958] Carpenter, B., Ed., "Architectural Principles of the 397 Internet", RFC 1958, DOI 10.17487/RFC1958, June 1996, 398 . 400 [RFC2606] Eastlake 3rd, D. and A. Panitz, "Reserved Top Level DNS 401 Names", BCP 32, RFC 2606, DOI 10.17487/RFC2606, June 1999, 402 . 404 [RFC2775] Carpenter, B., "Internet Transparency", RFC 2775, DOI 405 10.17487/RFC2775, February 2000, 406 . 408 [RFC3724] Kempf, J., Austein., R., Ed., and IAB, "The Rise of the 409 Middle and the Future of End-to-End: Reflections on the 410 Evolution of the Internet Architecture", RFC 3724, DOI 411 10.17487/RFC3724, March 2004, 412 . 414 [RFC4084] Klensin, J., "Terminology for Describing Internet 415 Connectivity", BCP 104, RFC 4084, DOI 10.17487/RFC4084, 416 May 2005, . 418 [RFC4949] Shirey, R., "Internet Security Glossary, Version 2", FYI 419 36, RFC 4949, DOI 10.17487/RFC4949, August 2007, 420 . 422 [RFC6973] Cooper, A., Tschofenig, H., Aboba, B., Peterson, J., 423 Morris, J., Hansen, M., and R. Smith, "Privacy 424 Considerations for Internet Protocols", RFC 6973, DOI 425 10.17487/RFC6973, July 2013, 426 . 428 [Saltzer] Saltzer, J., Reed, D., and D. Clark, "End-to-End Arguments 429 in System Design", ACM TOCS, Vol 2, Number 4, November 430 1984, pp 277-288. , 1984. 432 [UDHR] United Nations General Assembly, "The Universal 433 Declaration of Human Rights", 1948, 434 . 436 [WP-Debugging] 437 "Debugging", n.d., . 440 [WP-Stateless] 441 "Stateless protocol", n.d., 442 . 444 6.2. URIs 446 [1] mailto:hrpc@ietf.org 448 Authors' Addresses 450 Daniel Kahn Gillmor 451 ACLU 453 EMail: dkg@fifthhorseman.net 455 Niels ten Oever 456 Article19 458 EMail: niels@article19.org 460 Avri Doria 461 APC 463 EMail: avri@apc.org