idnits 2.17.1 draft-doria-hrpc-report-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 : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([HRPC-Research]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (March 21, 2016) is 2957 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'Blumenthal' is defined on line 646, but no explicit reference was found in the text == Unused Reference: 'Cath' is defined on line 652, but no explicit reference was found in the text == Unused Reference: 'Clark' is defined on line 654, but no explicit reference was found in the text == Unused Reference: 'Denardis14' is defined on line 661, but no explicit reference was found in the text == Unused Reference: 'HRPC-Method' is defined on line 670, but no explicit reference was found in the text == Unused Reference: 'RFC2026' is defined on line 706, but no explicit reference was found in the text == Unused Reference: 'RFC2639' is defined on line 710, but no explicit reference was found in the text == Unused Reference: 'RFC2919' is defined on line 715, but no explicit reference was found in the text == Unused Reference: 'RFC5890' is defined on line 725, but no explicit reference was found in the text == Unused Reference: 'RFC5891' is defined on line 730, but no explicit reference was found in the text == Unused Reference: 'RFC5892' is defined on line 735, but no explicit reference was found in the text == Unused Reference: 'RFC5893' is defined on line 740, but no explicit reference was found in the text == Unused Reference: 'RFC6162' is defined on line 745, but no explicit reference was found in the text == Unused Reference: 'RFC6783' is defined on line 750, but no explicit reference was found in the text == Unused Reference: 'RFC7230' is defined on line 760, but no explicit reference was found in the text == Unused Reference: 'RFC7231' is defined on line 765, but no explicit reference was found in the text == Unused Reference: 'RFC7232' is defined on line 770, but no explicit reference was found in the text == Unused Reference: 'RFC7234' is defined on line 775, but no explicit reference was found in the text == Unused Reference: 'RFC7235' is defined on line 780, but no explicit reference was found in the text == Unused Reference: 'RFC7236' is defined on line 785, but no explicit reference was found in the text == Unused Reference: 'RFC7237' is defined on line 790, but no explicit reference was found in the text -- Obsolete informational reference (is this intentional?): RFC 2639 (Obsoleted by RFC 3196) -- Obsolete informational reference (is this intentional?): RFC 7230 (Obsoleted by RFC 9110, RFC 9112) -- Obsolete informational reference (is this intentional?): RFC 7231 (Obsoleted by RFC 9110) -- Obsolete informational reference (is this intentional?): RFC 7232 (Obsoleted by RFC 9110) -- Obsolete informational reference (is this intentional?): RFC 7234 (Obsoleted by RFC 9111) -- Obsolete informational reference (is this intentional?): RFC 7235 (Obsoleted by RFC 9110) Summary: 1 error (**), 0 flaws (~~), 22 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Human Rights Protocol Considerations Research Group A. Doria (ed) 3 Internet-Draft APC 4 Intended status: Informational March 21, 2016 5 Expires: September 22, 2016 7 HRPC - Report 8 draft-doria-hrpc-report-01 10 Abstract 12 This document presents an overview snapshot of the HRPC project to 13 map engineering concepts at the protocol level that may be related to 14 human rights, with a focus on the promotion and protection of the 15 freedom of expression and of association. 17 It provides a framework while reporting on the study including: 18 theoretical background, results and basic considerations. It will 19 reference the detailed work being done on terminlogy and case studies 20 documented in the research draft. It also folds in discussions from 21 the research literature. The documents, [HRPC-Research] and this 22 document, form an interrelated set that may later be combined into a 23 single document. 25 This draft is still in very early stages and welcomes further 26 contribution. Text is solicited. 28 Discussion on this draft at: hrpc@irtf.org // 29 https://www.irtf.org/mailman/admindb/hrpc 31 Status of This Memo 33 This Internet-Draft is submitted in full conformance with the 34 provisions of BCP 78 and BCP 79. 36 Internet-Drafts are working documents of the Internet Engineering 37 Task Force (IETF). Note that other groups may also distribute 38 working documents as Internet-Drafts. The list of current Internet- 39 Drafts is at http://datatracker.ietf.org/drafts/current/. 41 Internet-Drafts are draft documents valid for a maximum of six months 42 and may be updated, replaced, or obsoleted by other documents at any 43 time. It is inappropriate to use Internet-Drafts as reference 44 material or to cite them other than as "work in progress." 46 This Internet-Draft will expire on September 22, 2016. 48 Copyright Notice 50 Copyright (c) 2016 IETF Trust and the persons identified as the 51 document authors. All rights reserved. 53 This document is subject to BCP 78 and the IETF Trust's Legal 54 Provisions Relating to IETF Documents 55 (http://trustee.ietf.org/license-info) in effect on the date of 56 publication of this document. Please review these documents 57 carefully, as they describe your rights and restrictions with respect 58 to this document. Code Components extracted from this document must 59 include Simplified BSD License text as described in Section 4.e of 60 the Trust Legal Provisions and are provided without warranty as 61 described in the Simplified BSD License. 63 Table of Contents 65 1. Background . . . . . . . . . . . . . . . . . . . . . . . . . 3 66 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 67 3. Theory . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 68 3.1. Universal Declaration of Human Rights (UDHR) and Internet 69 Architecture . . . . . . . . . . . . . . . . . . . . . . 5 70 3.2. Link between protocols and human rights . . . . . . . . . 5 71 3.3. Related research . . . . . . . . . . . . . . . . . . . . 7 72 3.3.1. David Clark . . . . . . . . . . . . . . . . . . . . . 7 73 3.3.2. Laura Denardis . . . . . . . . . . . . . . . . . . . 7 74 3.3.3. David Post . . . . . . . . . . . . . . . . . . . . . 8 75 3.3.4. Jonathan Zittrain . . . . . . . . . . . . . . . . . . 8 76 3.4. Related theoretical discussions from the research group . 8 77 3.4.1. Principles from NetMundial Multistakeholder Statement 8 78 3.4.2. "Values and Networks" work by Roland Bless . . . . . 9 79 3.4.3. Value laden engineering as discussed in A case study 80 of codeing rights by Cath . . . . . . . . . . . . . . 9 81 3.5. Internet protocols as a public good . . . . . . . . . . . 10 82 4. Methodology . . . . . . . . . . . . . . . . . . . . . . . . . 11 83 4.1. Case Studies . . . . . . . . . . . . . . . . . . . . . . 12 84 4.2. Methodological Issues . . . . . . . . . . . . . . . . . . 12 85 5. Possible areas for protocol considerations . . . . . . . . . 13 86 5.1. Emergent Issues/Questions . . . . . . . . . . . . . . . . 13 87 6. Next Steps . . . . . . . . . . . . . . . . . . . . . . . . . 13 88 6.1. Next steps for this document . . . . . . . . . . . . . . 14 89 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14 90 8. IANA considerations . . . . . . . . . . . . . . . . . . . . . 14 91 9. Security Considerations . . . . . . . . . . . . . . . . . . . 14 92 10. Informative References . . . . . . . . . . . . . . . . . . . 14 93 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 18 95 1. Background 97 Several reports from former United Nations (UN) Special Rapporteur on 98 the promotion and protection of the right to freedom of opinion and 99 expression, Frank La Rue, have made the relationship between the 100 Internet and human rights explicit and led to the approval of the 101 resolution "on the promotion, protection and enjoyment of human 102 rights on the Internet" at the UN Human Rights Council (HRC). More 103 recently, it led to the resolution "The right to privacy in the 104 digital age" at the UN General Assembly. The NETmundial outcome 105 document [Netmundial] affirms that human rights, as reflected in the 106 Universal Declaration of Human Rights [UDHR], should underpin 107 Internet governance principles. 109 Although the application of human rights to Internet policy 110 consideratons has a firm rights' basis, a direct relation between 111 Internet architecture and protocols and human rights needs to be 112 established and requires both exploration and description. As the 113 full range of the interdependent and interrelated human rights would 114 be challenging as a starting place for discussions, the research 115 group has decided to start with the the rights of freedom of 116 expression and freedom of association and assembly. 118 An additional challenge in bringing the discussion of human rights 119 into Internet engineering discussions is the absence of an agreed 120 upon vocabulary for such discussions. Developing a vocabulary for 121 this discussion is a first requirement for the HRPC research effort. 123 It has been argued in [Liddicoat] that concerns for freedom of 124 expression and association were a strong part of the world-view of 125 the community involved in developing the first Internet protocols. 126 Whether by intention or by historical coincidence, the Internet was 127 designed with freedom and openness of communications as core values. 128 But as the scale, as well as internationalization and 129 commercialization of the Internet have grown, the influence of such 130 world-views has had to compete with other values, such as ease and 131 cost of development as well as the costs and difficulties in 132 maintaining and upgrading the network and network elements. The 133 purpose of this research is to discover and to document possible 134 considerations, that is issues to be considered, involved in taking 135 human rights into account when creating protocols. 137 Following the lead of work done for RFC 6973 [RFC6973] on Privacy 138 Consideration Guidelines, the premise of this research is that some 139 standards and protocols can either enable or threaten human rights on 140 the Internet. 142 As stated in RFC 1958 [RFC1958], the Internet aims to be the global 143 network of networks that provides unfettered connectivity to all 144 users at all times and for any content. Open, secure and reliable 145 connectivity is essential for rights such as freedom of expression 146 and freedom of association, as defined in the Universal Declaration 147 of Human Rights [UDHR]. Therefore, considering connectivity as the 148 ultimate objective of the Internet makes a case that human rights are 149 core values of the architecture of the network. 151 The IETF has determined that an essential part of maintaining the 152 Internet as a tool for communication and connectivity is security. 153 Indeed, "development of security mechanisms is seen as a key factor 154 in the future growth of the Internet as a motor for international 155 commerce and communication" RFC 1984 [RFC1984] and according to the 156 Danvers Doctrine RFC 3365 [RFC3365], there is an overwhelming 157 consensus in the IETF that the best security should be used and 158 standardized. 160 In RFC 1984 [RFC1984], the Internet Architecture Board (IAB) and the 161 Internet Engineering Steering Group (IESG), the bodies which oversee 162 architecture and standards for the Internet, expressed: "concern by 163 the need for increased protection of international commercial 164 transactions on the Internet, and by the need to offer all Internet 165 users an adequate degree of privacy." Indeed, the IETF has been 166 doing a significant job in this area [RFC6973] and [RFC7258], 167 considering privacy concerns as a subset of security concerns. 168 [RFC6973] 170 The premise of this work is that it is possible to establish human 171 rights consideratons for other human rights, beyond just privacy. 172 This research builds on the the idea that protecting all rights is as 173 much a security concern in the Internet as is the protection of 174 privacy. The research also intends to document other bases for 175 consideration of human rights as core values in Internet 176 architectures and protocols. 178 This first phase of research focuses on freedom of expression and the 179 right to association and assembly online. In doing so, given the 180 interrelationship of all rights, other rights may be touched upon in 181 the discussion, but the primary emphasis will be to discover where 182 there are considerations that relate specicially to the freedoms of 183 expression and of association and assembly. In the first phase there 184 will also be a reliance on arguments based on security 185 considerations, though the effect of other values will be considered. 187 2. Terminology 189 The terminology being used in this project was defined in 190 [HRPC-GLOSSARY] and is applied in [HRPC-Research]. 192 The process of developing a glossary has involved taking the variety 193 of glossaries defined by the IETF in its various RFCs, comparing the 194 terms both among the various RFC definitions and with terminology 195 used in human rights field to produce a synthesized set of 196 definitions after discussion in the research group. The goal is to 197 produce a set of terms, using existing terminology, that can assist 198 clear discussion among engineering experts and human rights experts. 199 At this point in the research this vocabulary has been provisionally 200 accepted in the research group. 202 The glossary also includes the definitions of some complex terms, 203 such as Freedom of Expression and Freedom of Association, that relies 204 of several of the other defined terms. Some of these complex 205 defintions are still under discussion. 207 3. Theory 209 3.1. Universal Declaration of Human Rights (UDHR) and Internet 210 Architecture 212 This project is focused on two rights defined in the UDHR [UDHR], 213 Article 19 on Freedom of Expression and Article 20 of Freedom of 214 Association. 216 Article 19 Everyone has the right to freedom of opinion and 217 expression; this right includes freedom to hold opinions without 218 interference and to seek, receive and impart information and ideas 219 through any media and regardless of frontiers. 221 Article 20 1 Everyone has the right to freedom of peaceful assembly 222 and association. 224 2 No one may be compelled to belong to an association. 226 3.2. Link between protocols and human rights 228 [HRPC-Research] includes defintions of the basic human rights in 229 terms of the engineering terminology. For example: 231 - Right to Freedom of Expression builds on definitions of 233 - Connectivity 234 - Privacy 236 - Security 238 - Content Agnosticism 240 - Internationalization 242 - Censorship resistance 244 - Open Standards 246 - Heterogeneity support 248 - Right to Association builds on the defintions of 250 - Connectivity 252 - Decentralization 254 - Censorship resistance 256 - Pseudonymity 258 - Anonymity 260 Detailed defintions of the included terms can be found in 261 [HRPC-Research] 263 When looking at protocols the considerations can apply from several 264 perspectives. 266 - The protocol's direct effects on human rights on the Internet. 268 - The protocol's direct effect on human rights in combination with 269 other protocols 271 - The effect of specific protocol elements, separately or in 272 combination with other protocol elements on human rights on the 273 Internet 275 - The ability to determine when various effects are occurring, i.e. 276 transparency 278 - The effect of deployment or non deployment of protocol features. 279 While this may be may seem beyond the protocol itself, often the 280 design of protocol, its difficulty in implementation and the 281 degree to which it contains required elements, poison pills or 282 other protocol artifacts that either encourage or discourse 283 implementation or deployment, can be significant in the overall 284 human rights affect of a protocol. 286 (Editor's note: Several key pieces of research are discussed in this 287 section. Readers/reviewers of the draft who have other recommended 288 sources for relevant research that should be discussed in this 289 document are invited to submit such for inclusion.) 291 3.3. Related research 293 This section will look at the theoretical work that has been done in 294 the are of rights and protocols. It will include the academic 295 research on the topic including the work of David Post [Post], 296 Jonathan Zittrain [Zittrain] and David Clark, among others. 298 3.3.1. David Clark 300 TBD 302 3.3.2. Laura Denardis 304 In Protocol Politics [Denardis09] Denardis discusses "how values 305 enter, or should enter, Internet protocol design." She describes the 306 "IETF process itself self-consciously expresses certain values." The 307 discussion goes on to define some examples of of IETF values, 308 including: 310 - "Universality and competitive openness - one objective of 311 developing a standard is for it to become widely used in the 312 marketplace; 314 - "participatory openness in the standards=setting process; 316 - "the end-to-end architectural design principle specifying that 317 intelligence should be located at network end points rather than 318 in media res." 320 To demonstrate the point, she presents a case study where engineers 321 at the IETF "identified privacy as a value pertinent to IPv6 address 322 design and embedded this design into design choices" with a detailed 323 description of the issue of including Ethernet Addresses as part of 324 the IPv6 address culminating in the design of IPv6 privacy features 325 and changes. Interestingly she also describes how the IETF 326 engineering community was aware of the privacy challenges, the rights 327 challenges, before media and government discovered the problem and 328 were working on the problem before the fire firestorm began. 330 The description ended with the following: "this episode is a reminder 331 that some of the most critical Internet governance questions concern 332 individual civil liberties and that design decisions can present an 333 opportunity to advance libertarian and democratic values or to 334 contain these values. IPv6 privacy design implications and value- 335 conscious design choices reinforce the notion that Internet 336 architecture and virtual resources cannot be understood only through 337 the lens of technical efficiency, scarcity, or economic competition 338 but as an embodiment of human values with social and cultural 339 effects." 341 3.3.3. David Post 343 TBD 345 3.3.4. Jonathan Zittrain 347 TBD 349 3.4. Related theoretical discussions from the research group 351 3.4.1. Principles from NetMundial Multistakeholder Statement 353 NETmundial was a bell-weather event held in October 2014, where 354 stakeholders from academia, business, civil society, governments and 355 the technical community came together to discuss Principles and a 356 Roadmap for Internet governance. While the Principles did not 357 address protocol development specifically, they did include a 358 principle on Open Standards: 360 "Internet governance should promote open standards, informed by 361 individual and collective expertise and decisions made by rough 362 consensus, that allow for a global, interoperable, resilient, stable, 363 decentralized, secure, and interconnected network, available to all. 364 Standards must be consistent with human rights and allow development 365 and innovation." [Netmundial] 367 The NETmundial Roadmap on the other hand was a bit more specific on 368 certain topics including digital security and arbitrary surveillance: 370 - "Initiatives to improve cybersecurity and address digital security 371 threats should involve appropriate collaboration among 372 governments, private sector, civil society, academia and technical 373 community. There are stakeholders that still need to become more 374 involved with cybersecurity, for example, network operators and 375 software developers." 377 - "Mass and arbitrary surveillance undermines trust in the Internet 378 and trust in the Internet governance ecosystem. Collection and 379 processing of personal data by state and non-state actors should 380 be conducted in accordance with international human rights law. 381 More dialogue is needed on this topic at the international level 382 using forums like the Human Rights Council and IGF aiming to 383 develop a common understanding on all the related aspects." 384 [Netmundial] 386 3.4.2. "Values and Networks" work by Roland Bless 388 TBD 390 3.4.3. Value laden engineering as discussed in A case study of codeing 391 rights by Cath 393 This work discusses four basic architectural principles that are 394 encoded in Internet Technology: 396 - Openness, Permissionless Innovation, and Content Agnosticism 398 - Interoperability 400 - Redundancy and the Distributed Architecture 402 - The End-to-End Principle 404 The work by Cath explores the relationship of the architectural 405 principles to the human right of freedom of expression and asks 406 whether the IETF has a repsonsiblity toward human rights. The paper 407 shows that that there are numerous references to normative principles 408 among the body of work of the IETF. It argues that this provides the 409 necessary indication that ethics are within the purview of IETF 410 considerations. The research question asked by the work is: "Should 411 the right to freedom of speech be instantiated in the protocols and 412 standards of the Internet Engineering Task Force?" This quetion is 413 similar to the questions being asked in this research group. 415 Despite this ethical basis in Internet potocols, in Cath's work the 416 threat of fragmentation by countries that do not accept human rights 417 suggests that an answer to the normative research question is 418 negative: support for human rights should not be intitiated in the 419 Internet in order to avoid fragmentation. This can be understood to 420 mean that care must be taken to turning protocols into political 421 targets. On the other hand the principles that are encoded in the 422 Internet do make it better at enabling rights. This encourages work 423 such as the work done for privacy consideration in the IETF and the 424 research being done on protocol consideration for the freedoms of 425 expression and association, as long as these are just considerations 426 and not requirements. The paper cautions against using protocols to 427 achieve advocacy goals. 429 3.5. Internet protocols as a public good 431 While not specifically part of the research, a background theoretical 432 discussion in Internet rights involves discussion of whether the 433 Internet is a public good. The economic definitons of a public good 434 includes requirements that it be non-excludable, in that it is a good 435 that cannot be withheld from any individual, and that it be non- 436 rivalous, meaning that its use by some does not preclude its use by 437 others. 439 Strictily speaking, the Internet does not meet these requirements. 440 The fact that much of the world still does not have Internet access 441 shows that it is excludable, as many are still excluded. Addtionally 442 the fact that service providers charge for Internet access point to 443 access not being a public good. In terms of rivalry, bandwidth and 444 scalability issues give another indication that the Internet does not 445 qualify as a public good, one person's usage can interefe with 446 another person's usage. Some have argued that the Internet is a 447 Common Pool Resource (CPR), as defined by Ostrum [Ostrum]. This 448 claim has yet to be substantiated, as the Interent needs to satisfy 449 various design principles to qualify as a CPR. Discussion of this 450 issue is beyond the scope of this draft. (Editor's note: Though it 451 could be included it people felt it would be useful content for 452 references' sake.) 454 While the discussion on whether the Internet itself, as an 455 infrastrucure, is either a public good or CPR, is open and 456 contentious, it may be simpler to establish whether the set of core 457 Internet protocols is a public good. This is relavant to the 458 research in this group dealing with protocol considerations. It can 459 be argued that for Internet protocols to be non-excludable, it has to 460 be possible for everyone to use them. It is. Through the use of the 461 core Internet protocols, anyone can create a network that connects 462 into the Internet. While some protocols are encumbered by property 463 rights and licensing requirements, a core set of protocols that are 464 not encumberd, and thus freely avaialble to all, can be described as 465 non-excludable. It also seems clear that one party's proper use of 466 the core set of Internet protocols does not have the effect of 467 precluding use by others, so protocols can also be called non- 468 rivalrous. One question relevant to the question of Internet 469 protocols as a common good will involve determining whether a 470 sufficient set of the core protocols essential to the Internet, are 471 fully unencumbered. 473 Establising that Internet protocols are a public good adds an 474 economic development consideration to the discussions and provides 475 possible avenues for basing human rights protocol consideraton on 476 more that just security, allowing other bases for discussion of the 477 trades off in considerations when designing or deploying a protocol. 478 The question still needs further exploriation to determine whether 479 Internet protocols as a public good has any effect on the protocol 480 considerations to be recommended by this group. 482 4. Methodology 484 Some compnents of the methodology are defined in detail in Research 485 into Human Rights Protocol Considerations [HRPC-Research]. 487 The purpose of the work is to map the potential relations between 488 human rights and protocols so that considerations can be derived. 490 - the first step involved scoping the research problem 492 - Translating Human Rights Concept into Technical Definitions 494 o Mapping protocols and standards related to Freedom of 495 Expression and Freedom of Assembly as defined in human rights 496 covenants and agreements 498 o Extracting concepts from any and all RFCs that use and define 499 these terms 501 o Building the common glossary to be used linking engineering and 502 human rights concepts 504 - Discovering cases of protocols that have an effect on human rights 506 o Enablers of rights 508 o Enablers of abuse 510 - Working though the cases to determine and describe the issues that 511 affect human rights 513 - Applying the human rights technical definitions to the cases 515 - Derivation of possible considerations 517 4.1. Case Studies 519 The case studies and their initial status is being documented in 520 [HRPC-Research]. 522 In each of the case studies, the behavior of the protocols is 523 analysed for its positive and negative effects. In some case these 524 effects are due to the design of the protocol itself, in others they 525 may be due to existing or absent features. In protocls with optional 526 features, whether a feature is implemented or deployed, can be a 527 factor in the protocol's impact on human rights. 529 The analysis on the following protocols are currently being discussed 530 on HRPC list and being described in [HRPC-Research]. 532 - IP 534 Covering issues concerning the network visibility of source and 535 destination, address translation and mobility 537 - DNS 539 - HTTP 541 o HTTP code 451 543 - XMPP 545 - Peer to peer 547 - VPN 549 - Middleboxes 551 - DDOS 553 4.2. Methodological Issues 555 The current methodology is based on discourse analysis and 556 ethnographic research methods. This method is explained in 557 [HRPC-Research]. While this is a good basis for initial discovery, 558 further analysis is needed on whether the hypotheses formed as a 559 result of the case studies can be abstracted to general consideration 560 statements. Study is also needed to determine whether evidence for 561 similar effects can be shown as a result of applying the general 562 considerations to a wider set of protocols. A full analysis also 563 requires that some attempt be made to test any candidate 564 considerations for other effects and for unintended consequences. 566 5. Possible areas for protocol considerations 568 Using the definitions derived for the rights of freedom of expression 569 and freedom of association and assembly, and the protocol attributes 570 discovered in the use cases, a set of questions is being developed 571 that enable a protocol designer to consider whether their design has 572 any positive or negative effects on the human rights in question. 573 The questions should also give guidance in terms of protocol 574 atributes that can aid in creating new protocols that enable as 575 opposed to hinder human rights. 577 [HRPC-Research] includes a first take on such questions. This work 578 is still at an early stage. There have been recommendations in the 579 list that the form of the questions be based on best practices for 580 questionnaire development. The questions will need to be tested as 581 outlined above in the section on methodological issues, to determine 582 whether they are fit for general purpose in an engineering context. 584 5.1. Emergent Issues/Questions 586 This section records some of the question opened in discussion of the 587 group that open broader questions that those centered on protocol 588 considerations. Often the question involved the manner in which the 589 protocols are deployed or used. 591 - Can DDOS be considered freedom of expression when used for 592 advocacy? Even if it does, does this matter? Is interruption of 593 communication in the Internet such a negative aspect that it is 594 never acceptable? Is DDOS a moral equivalent to "capital" 595 infractions in that its use is never permitted by Human Rights 596 under any situation. Or is it a valid method that can be used for 597 advocacy? 599 - How do we differentiate between protocol effects that are inherent 600 to the protocol and those that arise from implementation, misuse 601 or from avoidance of non mandatory features. This includes 602 factoring for lack of proper maintenance or software updating. 603 Differentiating these effects from each other is important in 604 designing the considerations. 606 6. Next Steps 608 As discussed in the methodoloy section, a set of tests needs to be 609 undertaken to determine whether the protocol attributes that have 610 been isolated from the various use cases can be abstracted and tested 611 in situation other than in those test cases. 613 Once this is done, the set of considerations can be drafted and 614 discussed by the research group. 616 The current revision of [HRPC-Research] includes a first set of 617 possible considerations. 619 6.1. Next steps for this document 621 - Continue to add discussions of various threortical work related to 622 the issue 624 - Continue to report on the state of research. 626 The document will next be udated after IETF 95. 628 7. Acknowledgements 630 A section that include the many contributors of text as as commenters 631 and those who are assisitng this project in existing. Some of the 632 names: Niels ten Oever, Joana Varon, Catherine Cath, Daniel Kahn 633 Gillmor, ... more to be added ... and the all the particpants in the 634 research group. 636 8. IANA considerations 638 There shouldn't be any. 640 9. Security Considerations 642 There shouldn't be any. 644 10. Informative References 646 [Blumenthal] 647 Blumenthal, M. and D. Clark, "Rethinking the design of the 648 Internet The end-to-end arguments vs. the brave new 649 world", ACM Transactions on Internet Technology, Vol. 1, 650 No. 1, August 2001, pp 70-109. , 2001. 652 [Cath] Cath, C., "A case study of codeing rights", 2015. 654 [Clark] Clark, D., "The Design Philosophy of the DARPA Internet 655 Protocols", Proc SIGCOMM 88, ACM CCR Vol 18, Number 4, 656 August 1988, pp. 106-114. , 1988. 658 [Denardis09] 659 Denardis, L., "Protocol Politics", 2013. 661 [Denardis14] 662 Denardis, L., "The Global War for Internet Goverance", 663 2014. 665 [HRPC-GLOSSARY] 666 ten Oever, N., Doria, A., and D. Gillmor, "Human Rights 667 Protocol Considerations Glossary", 2015, 668 . 670 [HRPC-Method] 671 Varon, J. and C. Cath, "Human Rights Protocol 672 Considerations Methodology", 2015, 673 . 676 [HRPC-Research] 677 ten Oever, N. and C. Cath, "Research into Human Rights 678 Protocol Considerations", 2015, . 681 [Liddicoat] 682 Liddicoat, J. and A. Doria, "Human Rights and Internet 683 Protocols", n.d., . 686 [Netmundial] 687 "NETmundial Multistakeholder Statement", 2014, 688 . 691 [Ostrum] Ostrum,, E., "Governing the Commons", 1990. 693 [Post] Post, D., "Internet Infrastructure and IP Censorship", 694 2015, . 697 [RFC1958] Carpenter, B., Ed., "Architectural Principles of the 698 Internet", RFC 1958, DOI 10.17487/RFC1958, June 1996, 699 . 701 [RFC1984] IAB and , "IAB and IESG Statement on Cryptographic 702 Technology and the Internet", BCP 200, RFC 1984, 703 DOI 10.17487/RFC1984, August 1996, 704 . 706 [RFC2026] Bradner, S., "The Internet Standards Process -- Revision 707 3", BCP 9, RFC 2026, DOI 10.17487/RFC2026, October 1996, 708 . 710 [RFC2639] Hastings, T. and C. Manros, "Internet Printing 711 Protocol/1.0: Implementer's Guide", RFC 2639, 712 DOI 10.17487/RFC2639, July 1999, 713 . 715 [RFC2919] Chandhok, R. and G. Wenger, "List-Id: A Structured Field 716 and Namespace for the Identification of Mailing Lists", 717 RFC 2919, DOI 10.17487/RFC2919, March 2001, 718 . 720 [RFC3365] Schiller, J., "Strong Security Requirements for Internet 721 Engineering Task Force Standard Protocols", BCP 61, 722 RFC 3365, DOI 10.17487/RFC3365, August 2002, 723 . 725 [RFC5890] Klensin, J., "Internationalized Domain Names for 726 Applications (IDNA): Definitions and Document Framework", 727 RFC 5890, DOI 10.17487/RFC5890, August 2010, 728 . 730 [RFC5891] Klensin, J., "Internationalized Domain Names in 731 Applications (IDNA): Protocol", RFC 5891, 732 DOI 10.17487/RFC5891, August 2010, 733 . 735 [RFC5892] Faltstrom, P., Ed., "The Unicode Code Points and 736 Internationalized Domain Names for Applications (IDNA)", 737 RFC 5892, DOI 10.17487/RFC5892, August 2010, 738 . 740 [RFC5893] Alvestrand, H., Ed. and C. Karp, "Right-to-Left Scripts 741 for Internationalized Domain Names for Applications 742 (IDNA)", RFC 5893, DOI 10.17487/RFC5893, August 2010, 743 . 745 [RFC6162] Turner, S., "Elliptic Curve Algorithms for Cryptographic 746 Message Syntax (CMS) Asymmetric Key Package Content Type", 747 RFC 6162, DOI 10.17487/RFC6162, April 2011, 748 . 750 [RFC6783] Levine, J. and R. Gellens, "Mailing Lists and Non-ASCII 751 Addresses", RFC 6783, DOI 10.17487/RFC6783, November 2012, 752 . 754 [RFC6973] Cooper, A., Tschofenig, H., Aboba, B., Peterson, J., 755 Morris, J., Hansen, M., and R. Smith, "Privacy 756 Considerations for Internet Protocols", RFC 6973, 757 DOI 10.17487/RFC6973, July 2013, 758 . 760 [RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 761 Protocol (HTTP/1.1): Message Syntax and Routing", 762 RFC 7230, DOI 10.17487/RFC7230, June 2014, 763 . 765 [RFC7231] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 766 Protocol (HTTP/1.1): Semantics and Content", RFC 7231, 767 DOI 10.17487/RFC7231, June 2014, 768 . 770 [RFC7232] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 771 Protocol (HTTP/1.1): Conditional Requests", RFC 7232, 772 DOI 10.17487/RFC7232, June 2014, 773 . 775 [RFC7234] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke, 776 Ed., "Hypertext Transfer Protocol (HTTP/1.1): Caching", 777 RFC 7234, DOI 10.17487/RFC7234, June 2014, 778 . 780 [RFC7235] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 781 Protocol (HTTP/1.1): Authentication", RFC 7235, 782 DOI 10.17487/RFC7235, June 2014, 783 . 785 [RFC7236] Reschke, J., "Initial Hypertext Transfer Protocol (HTTP) 786 Authentication Scheme Registrations", RFC 7236, 787 DOI 10.17487/RFC7236, June 2014, 788 . 790 [RFC7237] Reschke, J., "Initial Hypertext Transfer Protocol (HTTP) 791 Method Registrations", RFC 7237, DOI 10.17487/RFC7237, 792 June 2014, . 794 [RFC7258] Farrell, S. and H. Tschofenig, "Pervasive Monitoring Is an 795 Attack", BCP 188, RFC 7258, DOI 10.17487/RFC7258, May 796 2014, . 798 [UDHR] United Nations General Assembly, "The Universal 799 Declaration of Human Rights", 1948, 800 . 802 [Zittrain] 803 Zittrain, J., "The Future of the Internet And How to Stop 804 It", 2008. 806 Author's Address 808 Avri Doria 809 APC 811 EMail: avri@apc.org