idnits 2.17.1 draft-knodel-terminology-09.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 (9 February 2022) is 779 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Obsolete informational reference (is this intentional?): RFC 8499 (Obsoleted by RFC 9499) Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group M. Knodel 3 Internet-Draft Center for Democracy & Technology 4 Intended status: Informational N. ten Oever 5 Expires: 13 August 2022 University of Amsterdam 6 9 February 2022 8 Terminology, Power, and Exclusionary Language in Internet-Drafts and 9 RFCs 10 draft-knodel-terminology-09 12 Abstract 14 This document argues for more inclusive language conventions 15 sometimes used by RFC authors and the RFC Production Centre in 16 Internet-Drafts that are work in progress, and in new RFCs that may 17 be published in any of the RFC series, in order to foster greater 18 knowledge transfer and improve diversity of participation in the 19 IETF. 21 This document represents the opinion of the authors and does not have 22 IETF consensus. 24 Status of This Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF). Note that other groups may also distribute 31 working documents as Internet-Drafts. The list of current Internet- 32 Drafts is at https://datatracker.ietf.org/drafts/current/. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 This Internet-Draft will expire on 13 August 2022. 41 Copyright Notice 43 Copyright (c) 2022 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 48 license-info) in effect on the date of publication of this document. 49 Please review these documents carefully, as they describe your rights 50 and restrictions with respect to this document. Code Components 51 extracted from this document must include Revised BSD License text as 52 described in Section 4.e of the Trust Legal Provisions and are 53 provided without warranty as described in the Revised BSD License. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 58 2. Terminology and Power in Internet-Drafts and RFCs . . . . . . 3 59 2.1. Master-Slave . . . . . . . . . . . . . . . . . . . . . . 5 60 2.2. Blacklist-Whitelist . . . . . . . . . . . . . . . . . . . 6 61 2.3. Other Considerations . . . . . . . . . . . . . . . . . . 7 62 3. Summary of Recommendations . . . . . . . . . . . . . . . . . 8 63 4. Further Reading . . . . . . . . . . . . . . . . . . . . . . . 9 64 5. Security Considerations . . . . . . . . . . . . . . . . . . . 10 65 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 66 7. Informative References . . . . . . . . . . . . . . . . . . . 10 67 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13 69 1. Introduction 71 According to [RFC7322], "The ultimate goal of the RFC publication 72 process is to produce documents that are readable, clear, consistent, 73 and reasonably uniform," and one function of the RFC Editor is to 74 "[c]orrect larger content/clarity issues; flag any unclear passages 75 for author review." Documents that are published as RFCs are first 76 worked on as Internet-Drafts. 78 Given the importance of communication between people developing RFCs, 79 Internet-Drafts (I-Ds), and related documents, it is worth 80 considering the effects of terminology that has been identified as 81 exclusionary. This document argues that certain obviously 82 exclusionary terms should be avoided and replaced with alternatives. 83 We propose nothing more than care in the choice of language just as 84 care is taken in defining standards and protocols themselves. 86 The point of the piece is to lift up the voices of those who choose 87 not to engage because of harmful dynamics such as exclusionary 88 language. 90 This document presents arguments for why exclusionary terms should be 91 avoided in Internet-Drafts and RFCs and, as an exercise, describes 92 the problems introduced by some specific terms and why their proposed 93 alternatives improve technical documentation. The example terms 94 discussed in this document are "master-slave" and "whitelist- 95 blacklist". There is a section on additional considerations and 96 general action points to address future RFCs and I-Ds. Lastly, a 97 summary of recommendations is presented. 99 2. Terminology and Power in Internet-Drafts and RFCs 101 This analysis is presented as the authors' commentary on the IETF 102 process and does not represent the opinion of the IETF. 104 According to the work of Heather Brodie Graves from 1993, "One goal 105 of the application of rhetorical theory in the technical 106 communication classroom is to assess the appropriateness of 107 particular terms and to evaluate whether these terms will facilitate 108 or hinder the readers' understanding of the technical material" 109 [BrodieGravesGraves]. This implies that in order to effectively 110 communicate the content of I-Ds and RFCs to all readers, it is 111 important for Authors to consider the kinds of terms or language 112 conventions that may inadvertently get in the way of effective 113 communication. She continues, "Complex and subtle configurations of 114 sexist, racist, or ethnocentric language use in technical documents 115 can derail or interfere with readers' ability and desire to 116 comprehend and follow important information." 118 Indeed, problems of language are problems of everyday speech. Racist 119 and sexist language is rampant and similarly counter-productive in 120 other sectors, notably social work [Burgest]. The terms "master- 121 slave" (treated in detail below) are present in other realms of 122 technology, notably, "Automotive clutch and brake systems, clocks, 123 flip-flop circuits, computer drives, and radio transmitters" 124 [Eglash]. 126 However, it is not too late for these terms to be replaced with 127 alternative metaphors that are more accurate, clearer, less 128 distracting, and that do not offend their readers. Language matters 129 and metaphors matter. Indeed, metaphors can be incredibly useful 130 devices to make more human the complex technical concepts presented 131 in RFCs. Metaphors should not be avoided, but rather taken 132 seriously. Renowned linguist George Lakoff argued in 1980 that the 133 ubiquitous use of metaphors in our everyday speech indicates a 134 fundamental instinct to "structure our most basic understandings of 135 experience" [Lakoff]. Metaphors structure relationships, and they 136 frame possibilities and impossibilities [Wyatt]. 138 The role of language is to describe the world and maintain social 139 relationships. The way in which the world, people, and institutions 140 are described provides a particular ordering to the world. This 141 ordering function of language is what makes it a potential instrument 142 for power and control. The understanding of power in relation to 143 language, as used in this document, is the way in which language 144 reflects, influences, and shapes social relations. 146 Like Graves, this document recognises the monumental challenge of 147 addressing linguistics and power, and attempts to promote awareness 148 that may lead to eventual wide-spread change and suggests first steps 149 for actions that may remedy the inadvertent use of undesirable terms. 150 To that end, the list below is a tersely written set of IETF-specific 151 arguments as to why the RFC Editor should be encouraged to remedy 152 issues with respect to exclusionary language and metaphors: 154 1. The RFC series is intended to remain online in perpetuity. 155 Societal attitudes to offensive and exclusionary language shift 156 over time in the direction of more empathy, not less. 158 2. That exclusionary terms in RFCs are largely hidden from the wider 159 public, or read only by engineers, is no excuse to ignore social- 160 level reactions to the terms. If the terms would be a poor 161 choice for user-facing application features, the terms should be 162 avoided in technical documentation and specifications, too. 164 3. At the time of writing, the digital technology community has a 165 problem with monoculture [RFC7704] [Cath]. And because the lack 166 of diversity of the technical community is a problem, a key 167 strategy to breaking monoculture is to ensure that technical 168 documentation is addressed to a wider audience and more readers. 170 4. The technical community already includes members who take offense 171 to these terms. Eradicating the use of exclusionary terminology 172 in technology recognises the presence of and acknowledges the 173 requests from black and brown engineers and from women and 174 gender-non-conforming engineers to avoid the use of exclusionary 175 terminology [Wired] [Seele]. RFCs and I-Ds are some of the 176 primary technical specifications in the Internet and should 177 follow this principle. 179 This document does not try to prescribe terminology shifts for any 180 and all language that could be deemed exclusionary. Instead we 181 illustrate an overall approach through the following two most 182 eggregious examples of specific term pairs "master-slave" and "white- 183 blacklist" and the rationale for the use of suggested alternatives. 184 Suggested actions for handling additional considerations are 185 presented in a subsequent section. 187 2.1. Master-Slave 189 Master-slave is an offensive and exclusionary metaphor that will and 190 should never become fully detached from history. Aside from being 191 unprofessional and exclusionary it stifled the participation of 192 students whom Eglash interviewed for his research. He asks: "If the 193 master-slave metaphor affected these tough-minded engineers who had 194 the gumption to make it through a technical career back in the days 195 when they may have been the only black persons in their classes, what 196 impact might it have on black students who are debating whether or 197 not to enter science and technology careers at all?" [Eglash] 199 Aside from the arguably most important reason outlined above, these 200 terms are becoming less used and therefore increasingly less 201 compatible as more communities move away from their use (e.g. 202 [NIST], [Python], [Drupal], [Github] and [Django] ). The usage of 203 'master' and 'slave' in hardware and software has been halted by the 204 Los Angeles County Office of Affirmative Action, the Django 205 community, the Python community and several other programming 206 languages. This was done because the language is offensive and hurts 207 people in the community [Django2]. Root operator Internet Systems 208 Consortium recognised that the terms 'master' and 'slave' are very 209 value-laden and responded to multiple requests from users by offering 210 an inoffensive alternative [ISC]. 212 In addition to being inappropriate, the master-slave metaphor is both 213 technically and historically inaccurate. For instance, in DNS the 214 'slave' is able to refuse zone transfers on the ground that they are 215 malformed. The metaphor is incorrect historically given the most 216 recent centuries during which "the role of the master was to abdicate 217 and the role of the slave was to revolt" [McClelland]. Yet "slavery" 218 is not just a historic term: whereas freedom from slavery is a human- 219 rights issue [UDHR], slavery continues to exist in the present day 220 [Wikipedia]. Furthermore, this term set wasn't revived until 221 recently, after WWII, and after many of the technologies that adopted 222 it were already in use with different terminology [Eglash]. 224 Ultimately master-slave is a poor choice since: 226 1. it is being used less frequently already in a variety of 227 applications, 229 2. it has perceived exclusionary effects, 231 3. concerned members of the technical community have requested that 232 its use be ceased. 234 Eglash's research calls into question the accuracy of the master- 235 slave metaphor. To find alternatives to master-slave, one can look 236 to many existing implementations of technology. There are also many 237 other relationships that can be used as metaphors. An alternative 238 should be chosen based on the pairing that is most clear in context: 240 * Primary-secondary based on authority. See for example [RFC8499]. 242 * Primary-replica based originality. 244 * Active-standby based on state. 246 * Writer-reader based on function. 248 2.2. Blacklist-Whitelist 250 The metaphorical use of white-black to connote good-evil is 251 exclusive. While master-slave might seem like a more egregious 252 example of racism, white-black is arguably worse because it is more 253 pervasive and therefore more insidious. While recent headlines have 254 decried the technical community's use of master-slave, there is far 255 less discussion about white-black despite its importance. There is 256 even a name for this pervasive language pitfall: the association of 257 white with good and black with evil is known as the "bad is black 258 effect" [Grewal]. 260 Indeed, there is an entire book on the subject, written by renowned 261 authority on race, Frantz Fanon. In his book "Black Skin, White 262 Masks," Fanon makes several persuasive arguments that standard 263 language encodes subconscious in-group, out-group preferences 264 [Fanon]. 266 In the case of blacklist-whitelist in the technical documentation of 267 I-Ds and RFCs, it is entirely a term of art and an arbitrary 268 metaphorical construct with no technical merit. There are scientific 269 uses of black that are related to light - black holes are black 270 because light cannot escape them. Blacklist-whitelist is not a 271 metaphor for lightness or darkness, it is a good-evil metaphor and 272 therefore this trope has significant impact on how people are seen 273 and treated. As we've seen with metaphors, its use is pervasive and, 274 though not necessarily conscious, perceptions do get promulgated 275 through culture and repetition. 277 As with master-slave, we save our technical argument for last, 278 referencing and presenting first the reasons for the use of non- 279 offensive, alternative terminology for the sake of our humanity. 280 Indeed, our technical argument is succinct: Why use a metaphor when a 281 direct description is both succinct and clear? There can be 282 absolutely no ambiguity if one uses the terms, as suggested below, 283 allow-block rather than white-black. 285 There are alternatives to this terminology set that vastly improve 286 clarity because they are not even metaphors, they're descriptions. 287 The alternatives proposed here say exactly what they mean. 289 * Accept-list and Drop-list for threat signaling. See for example 290 [RFC8612], [RFC9132], and [RFC8783]). 292 * Blocklist-allowlist, deny-allow, exempt-allowlist or block-permit 293 for permissions. 295 2.3. Other Considerations 297 As described in the preceding sections, the language used in 298 technical documentation, like all written text, creates and 299 reinforces expectations and stereotypes. We propose nothing more 300 than additional care in the choice of language just as care is taken 301 in defining standards and protocols themselves. The two examples 302 provided above are not the only cases of exclusionary language to be 303 avoided, and many more can be collected. We use this section to 304 broaden the context of other offensive and exclusionary terminologies 305 to encompass additional concerns, why spotting and eradicating 306 problematic terminologies is a valid endeavour for authors and 307 editors of technical documentation and how this might be 308 systematised. 310 There are many other metaphors present in technical documentation 311 that are "terms of art" but that have no technical basis whatsoever. 312 If any of these metaphors is offensive there is no excuse for its 313 continued use. A term like "man-in-the-middle" is not technically 314 useful. It is not a standard term, not as clear as its alternative 315 "on-path attacker", and should therefore be avoided. When presented 316 with the opportunity to employ the use of metaphors or to 317 unthinkingly repeat terms of art that connote gender or race, Authors 318 should simply find a better way to explain themselves. A fun read on 319 the politics of colloquial speech by George Orwell should dissuade 320 any Author from using tired explanatory metaphors [Orwell]. 322 The unnecessary use of gendered pronouns is a sexist practise that is 323 common but easy to spot and replace. Without a neutral singular 324 pronoun, "he" is assumed as the default singular pronoun when the 325 gender of the person is unknown or ambiguous. However, that has 326 changed, and it is now widely accepted that "they" can be used as a 327 neutral singular pronoun. Since it is unlikely that all implementers 328 and infrastructure operators are of any particular gender, "he" 329 should never be used to refer to a person in I-Ds and RFCs. An 330 Author who uses male examples sets male-ness as a standard. 332 Besides race and gender, our world is full of metaphors rooted in 333 oppression, ableism, and colonialism. Militarised metaphors are also 334 a pervasive problem in language, perhaps even more so in technical 335 communities because of the historical and actual relationship between 336 technology and war. Authors of RFCs need to be especially on their 337 guard against all manner of metaphors that may carry unwanted 338 overtones. 340 While it is not our intention to be exhaustive we hope to have made a 341 persuasive case for authors and editors to pay attention to the finer 342 details of metaphor, and the ways power is replicated in technical 343 documentation unless detailed attention is paid. The example terms 344 above "master-slave" and "blacklist-whitelist" are already less 345 common. If the IETF community has learned anything from the debate 346 over the use of these terms, and this document, it is that language 347 matters to us deeply as members of society and as engineers. And 348 because language, and society, change over time, we must approach 349 future concerns with some degree of dispassion when the arguments 350 presented in the first section can be clearly applied. 352 There is harm in protracted discussion about the validity of the 353 experience of IETF participants with exclusionary terminology because 354 it invalidates this people's experiences. Behavior that, some of 355 which labeled IESG as racist and disrepectful and therefore removed 356 [White1] [White2] surfaced in the community as a result of this 357 larger debate among technologists pushed away participants and 358 observers [Conger]. This illustrates the need to, as Graves is cited 359 above as saying, continue to raise awareness within our community for 360 eventual, lasting change on the continued front of struggle against 361 the racists amongst us. Yet we recommend a living stylesheet, rather 362 than repeated RFCs, be used as a mechanism for monitoring 363 exclusionary language in IETF documents [inclusiveterminology]. 365 It is there that we welcome additional examples of terminology that 366 might be avoided through more awareness and thoughtfulness. 368 3. Summary of Recommendations 370 To summarise, we have listed some concrete action points that can be 371 taken by Editors, reviewers and Authors, both present and future as 372 they develop and publish Internet-Drafts and new RFCs. 374 The authors think that document authors should: 376 * Replace and avoid the exclusionary terms "master-slave" and 377 "blacklist-whitelist" with more accurate alternatives. 379 * Read and reflect upon the repository of exclusionary terminology 380 maintained by the community [inclusiveterminology]. 382 * As the IESG has recommended [IESG], follow the NIST guidance on 383 the use of inclusive language in standards [NIST0]. 385 * Reflect on their use of metaphors generally. 387 * Consider changing existing exclusionary language in current 388 (reference) implementations [socketwench]. 390 * Consult the RFC Editor Style Guide. 392 The authors think that the RFC editor should: 394 * Offer alternatives for exclusionary terminology as an important 395 act of correcting larger editorial issues and clarifying technical 396 concepts. 398 * Consult the IETF community and other sources to build and maintain 399 a style sheet that collects reconsidered terminology relevant to 400 the IETF. 402 * Suggest to Authors that even when referencing other specifications 403 that have not replaced offensive terminology, the Authors could 404 use another term in their document and include a note to say that 405 they have used the new term as a replacement for the term used in 406 the referenced document. 408 4. Further Reading 410 For more information on this topic we suggest reading: 412 Ford, Heather., Wajcman, Judy. 2017. "'Anyone can edit', not 413 everyone does: Wikipedia and the gender gap" Social Studies of 414 Science. ISSN 0306-3127 416 Grant, Barbara M. 2008. "Master-slave dialogues in humanities 417 supervision" Arts and Humanities in Higher Education, Volume: 7 418 issue: 1, page(s): 9-27 https://doi.org/10.1177/1474022207084880 420 Miller, Carolyn, R. 1979. "A Humanistic Rationale for Technical 421 Writing" College English, Vol. 40, No. 6, pp. 610-617 423 5. Security Considerations 425 Security is dependent on a wide range of actors that are implementing 426 technical documentation. Therefore it is crucial that language is 427 clear, and understood by all that need to implement this 428 documentation. Correct and inclusive language is therefore conducive 429 for secure implementations of technical documentation. 431 Changing terminology that is common in use can be leveraged as 432 security risk because it may lead people to misunderstand what is 433 being talked about. It is therefore recommended that when language 434 is changed because of the reasons described in this document, it 435 should be documented as such. 437 6. IANA Considerations 439 This document has no actions for IANA. 441 7. Informative References 443 [RFC7322] Flanagan, H. and S. Ginoza, "RFC Style Guide", RFC 7322, 444 DOI 10.17487/RFC7322, September 2014, 445 . 447 [RFC7704] Crocker, D. and N. Clark, "An IETF with Much Diversity and 448 Professional Conduct", RFC 7704, DOI 10.17487/RFC7704, 449 November 2015, . 451 [RFC8499] Hoffman, P., Sullivan, A., and K. Fujiwara, "DNS 452 Terminology", BCP 219, RFC 8499, DOI 10.17487/RFC8499, 453 January 2019, . 455 [RFC9132] Boucadair, M., Ed., Shallow, J., and T. Reddy.K, 456 "Distributed Denial-of-Service Open Threat Signaling 457 (DOTS) Signal Channel Specification", RFC 9132, 458 DOI 10.17487/RFC9132, September 2021, 459 . 461 [RFC8783] Boucadair, M., Ed. and T. Reddy.K, Ed., "Distributed 462 Denial-of-Service Open Threat Signaling (DOTS) Data 463 Channel Specification", RFC 8783, DOI 10.17487/RFC8783, 464 May 2020, . 466 [RFC8612] Mortensen, A., Reddy, T., and R. Moskowitz, "DDoS Open 467 Threat Signaling (DOTS) Requirements", RFC 8612, 468 DOI 10.17487/RFC8612, May 2019, 469 . 471 [Burgest] Burgest, David R., "Racism in Everyday Speech and Social 472 Work Jargon.", Social Work, vol. 18, no. 4, 1973, pp. 473 20-25 , 1973, . 475 [Eglash] Ron Eglash, ., "Broken Metaphor: The Master-Slave Analogy 476 in Technical Literature.", Technology and Culture, vol. 48 477 no. 2, 2007, pp. 360-369. , 2007, 478 . 483 [BrodieGravesGraves] 484 Heather Brodie Graves, . and . Roger Graves, "Masters, 485 slaves, and infant mortality: Language challenges for 486 technical editing", Technical Communication Quarterly, 487 7:4, 389-414 , 1998, 488 . 490 [Wyatt] Sally Wyatt, ., "Danger! Metaphors at Work in Economics, 491 Geophysiology, and the Internet", Science, Technology, and 492 Human Values, Volume: 29 issue: 2, page(s): 242-261 , 493 2004, 494 . 498 [Lakoff] George Lakoff, . and . Mark Johnson, "Metaphors We Live 499 By", U of Chicago P, 1980. , n.d.. 501 [Orwell] George Orwell, ., "Politics and the English Language", 502 1946, 503 . 506 [McClelland] 507 McClelland, J., "We need better metaphors", 2011, 508 . 511 [UDHR] United Nations General Assembly, "The Universal 512 Declaration of Human Rights", 1948, 513 . 515 [Fanon] Fanon, F., "Black skin, white masks", 1952. 517 [Python] Daniel Oberhaus, ., "'master-slave' Terminology Was 518 Removed from Python Programming Language", 2018, 519 . 523 [Django] fcurella, ., "#22667 replaced occurrences of master-slave 524 terminology with leader/follower #2692", 2014, 525 . 527 [Django2] lynncyrin, ., "comment on #22667 replaced occurrences of 528 master-slave terminology with leader/follower #2692", 529 2014, . 532 [Wikipedia] 533 Wikipedia, "Slavery in the 21st century", 2018, 534 . 537 [Drupal] Xano, ., "Replace 'master-slave' terminology with 538 'primary/replica'", 2014, 539 . 541 [Grewal] Grewal, D., "The 'Bad Is Black' Effect", 2017, 542 . 545 [socketwench] 546 socketwench, ., "Even in tech, words matter", 2018, 547 . 550 [ISC] Internet Systems Consortium, ., "@ISCdotORG reply tweet", 551 2017, 552 . 554 [Github] Kevin Truong, . and VICE, "Github to Remove 'Master/Slave' 555 Terminology From its Platform", June 2020, 556 . 559 [NIST] Eric Geller, . and Politico, "Agency to end use of 560 technology terms such as 'master' and 'slave' over racist 561 associations", June 2020, 562 . 565 [inclusiveterminology] 566 IETF, "Inclusive terminology in IETF Documents", August 567 2020, . 569 [Cath] Corinne Cath, ., "The Technology We Choose to Create: 570 Human Rights Advocacy in the Internet Engineering Task 571 Force", Telecommunications Policy 45, no. 6 (July 1, 572 2021): 102144. , 2021, 573 . 575 [Wired] Elizabeth Landau, . and Wired, "Tech Confronts Its Use of 576 the Labels 'Master' and 'Slave'", 2020, 577 . 580 [Seele] Mike Seele, ., "Striking Out Racist Terminology in 581 Engineering", 2020, . 584 [Conger] Kate Conger, . and New York Times, "'Master,' 'Slave' and 585 the Fight Over Offensive Terms in Computing", 2021, 586 . 589 [IESG] Internet Engineering Steering Group, "IESG Statement on 590 Inclusive Language", 2021, 591 . 594 [NIST0] National Institute of Standards and Technology, "Guidance 595 for NIST Staff on Using Inclusive Language in Documentary 596 Standards", 2021, . 598 [White1] Les White, ., "TLS Preferred Pronouns", 2021, 599 . 602 [White2] Les White, ., "Intersectional Dots", 2021, 603 . 606 Authors' Addresses 608 Mallory Knodel 609 Center for Democracy & Technology 611 Email: mknodel@cdt.org 612 Niels ten Oever 613 University of Amsterdam 615 Email: mail@nielstenoever.net