Welcome to Tech Talk by

what Internet governance is, we need to go a bit back, namely to 1865. That is when the International Telegraph Union was established. And that body, which is the oldest still functioning international organization, actually governs all the communication channels that we have in the world, telephone, satellite, spectrum, except for the Internet. So during the Cold War, The United States started developing this network that could withstand a nuclear strike, which is which then developed together with other networks into the Internet that we know today. And part of that for the development of the protocols, there was first this informal body, the Internet Engineering Task Force, that in the early 90s when the Internet was privatized after the fall of the Soviet Union, became the official body for the setting of voluntary standards for the Internet. And that is the Internet Engineering Task Force. It's a body where everyone can participate. You only need to have an email address and you can participate in different working groups that set the protocols, which are kind of the rules of the road, for the Internet that allow for interoperation on this network of networks.

For sure. So language is the way we think and construct. So in part, the way that we use language provides categories in which we think of the world. So also our world view is reflected in the language that we use. So we shape language, but language also shapes us. And it really shows power imbalances and forms of inclusion, exclusion, and remnants of power structures that exist in the world. So language is one way of thinking and interrogating, what are the power and opportunities that are at play in society.

Anything to add there, Mallory? Yeah. I think it's important to note why this is coming up now on why we're talking about inclusive language the the way we do in, the work Niels and I have done in the IETF, but also in the in the larger tech space and then obviously the the mainstream conversation about topics like diversity, equity, and inclusion. And so this inclusive language idea is that in order to improve, diversity and equity, we have to first be inclusive. They're all kind of intertwined, but we're really focused on this last piece in the technical community because for the most part, it is very much out of reach. It is, monoculture. It and that has effects on who participates and how robustly they participate. And, so it's one of those attempts to solve it. I would say that in the in the larger scheme of things and all the tactics that we need to use in order to get to a more equitable society, this is, you know, a subtask of a subtactic. It's so far down, the list of priorities and how impactful it is, but it's just, in this moment or in the moment we were in in 2018 all the way till now still, these small changes actually do matter. And so when folks talk about inclusive naming or inclusive language, they're just trying to erase these what were previously like invisible barriers. It was just metaphors that we used on a daily basis. Like, you know, the the metaphor of master slave for timekeeping atomic clocks or for different kinds of servers and Internet architecture. You know, now we we aren't using them and it's because that before seemed like a term of art. But then when folks started questioning it, it really doesn't have any good reason to exist. And because it did feel exclusionary and we wanna center actually how people feel, I think that's an important point that we're bringing this in. It isn't just the cold hard logic of of language. It's it's more than that. Then it hopefully is just even if it's just a gesture, of a community or institution to start using different terminology, that gesture actually goes a long way. But I think it's even deeper than that. It isn't just a gesture. Like Neil said, it's changing the way we think. Questioning the metaphors we use can be really transformative. And so I think that the there's a practical side of why we want more inclusive language, but then there's also like a real political and in community kind of outcome of this too. So that's sort of why we talk about it. And I cannot

do anything more than agree with Mallory. And perhaps I can, add a couple of examples to, illustrate this abyss because maybe for some people who are not intimately working on Internet protocols and standards, this might seem, a bit opaque. But as we'll later talk about, for a lot of people working in Internet standards and protocol, it was also a bit opaque. But I wanna go back to the to the artist engineer, Ramzi Nasr, who developed the Arabic programming language, Kalp. And when he developed that, he called it a piece of engineering performance art. And I was very surprised when he told me that because I asked him, why don't you just call this engineering? Well, then he said because every layer of the stack is gonna reject the Arabic script. And I was really shocked by that because my experiences on the Internet and before that on bulletin board systems and on Usenet for the Internet felt really free. But that was because the Internet and built bulletin board before that were built for people like me and people who use the Latin script and people who have a pretty good command of English. But if you are if your native tongue is not English and if it's not a Latin script, then you continuously feel that you're not welcome on the Internet, and then you do not experience that freedom but a sense of exclusion. And this sense of exclusion is also repeated in the governance culture, because while the door is open, there are still significant thresholds for people to participate as Corinne Kaff showed in her excellent work, Loud Men Talking Loudly, which was also the basis of her, PhD thesis in which she did ethnographic research in the engineering task, Internet Engineering Task Force, showing that there are many barriers for participation, even though the Internet Engineering Task Force use openness to legitimize its organization. And a final example is also the use of militarist language in a lot of these communication networks. And that is not a coincidence because traditionally transnational communication networks are tools of power and control to project power outside of territorial borders. So if we want to undo that and use the Internet as a fundament for, for our information societies, then we should build this public Internet in interest Internet infrastructure based on public values, and that should be reflected in its language as well. And that's the work,

Well, I think it goes back to Neil started way back when you talked about standards, where I think it's actually a pretty appropriate place to start. But then you get to see that, you know, we're talking about communities that started in the eighteen hundreds. We're talking about, like, the International Telecommunication Union. So that's one thing. They're they're old communities, and and science, as we know, has had a really direct, not indirect at all, relationship to racism. We can think of eugenics and other kinds of practices. Those aren't computer related, but they are becoming popularized and made more rigorous around the same time. There's also another era where this starts, happening. So when we were doing research for, the document we wrote that sort of traces the history a bit of these terms, there's someone named Ron Iglash who's a scholar on this topic. In one of his papers, he talks about the atomic clocks, which for a long time was the classic example of the use of master slave as as technical term of art. It's, you know, it's not it's not offensive was the argument. And when he looked at that use case, in fact, it had been standardized or it had been in use, the use of atomic clocks, had been in use in using other terminology. And it wasn't until the fifties and sixties that master slave became adopted as the term of art across the industry. And, you know, if that were in The US, which I can't remember exactly, but my guess is it was, there were a lot of civil rights upheavals during that time that may indicate that that was an intentional shift, or at least not benign. Right? We can we can I think he makes the connection in his paper that someone used those terms on purpose? It is a choice and you ask the right question, I think one that a lot of us have been asking through this process, Why can't we just change them? Why can't we, as the deciders, make the decision? And I would say that there in in in many cases, and to the IETF's credit, the deprecation of the use of blacklist, whitelist, and master slave in the context of the domain name system, the terminology specification, happens, actually pretty immediately and without much fanfare, which is proof that it that can just be done. The other argument though that folks made was, well, standards are very integrated in the sense that, you know, if we're going to be citing if we're gonna develop a standard in this community, we are also citing a standard on the hardware layer that's written by the I triple e, and we don't have control over how the I triple e calls it. And so we have to use the terms they use because, you know, the different ways our standards interact require that. But that's also eroding because and we'll talk about this more later, this has been across the industry change. So at this point, we are, you know, really close to completely eradicating some of these terms. And it just takes time, but eventually we all kind of get there. So that argument isn't nearly as strong as it used to be. And I think, yeah, I think, we can just make the change. It doesn't always happen immediately, but it's certainly possible.

Yeah. And to what Mallory said, it is kind of prototypical for the standards community that they want standards language that they don't want to change because that's the standard. Right? So but then this community also has the opportunity to set a new standard. So with great power also comes great responsibility. And there are also already examples of things that we call different on different layer. What we on the, on the data link layer, we what we call frames, we call the network layer pack packets, and on the transport layer, we call it segments. Right? So it's also a, a term of convention that can change. As times change, language changes. And so there has been in philosophy this long trend of, a long discussion about what's the role of language. And sometimes engineers think quite naively that there is a dire that language is a direct representation of reality, but it doesn't. It drifts and it shifts and it adds order. And that's why it's important that to come with the better insights that we get, we create better language so we can actually do better science and do better engineering with more and smarter people in our communities that help diversify, who we are and how we think because that helps us get better outcome because heterogeneous communities produce better knowledge than homogeneous communities.

Well, in 2000, I think that must have been '18. Yeah. October 2018, Mallory and I got together and we saw some excellent, we we we were reading Fanon and we were looking at we were discussing it and looking at discussions in the Python community where there was a discussion about inclusive inclusive and exclusive language, and we saw changes in the field. So we thought, wow. Why don't we also bring this change to the IETF so that actually we can have a level playing field? We are part we are, we do our part, and we help promulgate this this thing. So we sat down and we wrote what, what is called an Internet draft, which is a, a draft document that when it's accepted by the IETF and its surrounding communities becomes an RFC, also known as request for comment. But if you start commenting once it's called an RFC, you're too late. So like so we we published this draft, which was called terminology, power, and oppressive language, and, we discussed about alternative language for master slave, alternative language for blacklist and white list, added some examples, and thought, well, this should not be this should not be too hard. This should probably be a relatively easy, thing to go forward with, but, that was not what we expected.

So the draft actually does three things. It sort of makes an argument for why this is important. It does a bit of a literature review based on some of the things Niels and I have been reading, as he said. It outlines very specifically two term pairs. We don't try to list or include every single kind of offensive term. We just focus on master slave and blacklist, whitelist. And we describe why they're a problem and we suggest replacements. And then the last thing it does is it puts in context for the IETF a way to operationalize how to fix this. Right? So we speak directly to the RFC editor in the draft and suggest some ways forward for how to migrate from better terms and away from ones that are offensive. And I think, like, you know, just to timeline this, you know, it's been five years now. It did you're right, Niels. It was it started with you sending a link about the change happening in Python. So the Python community, which is a programming language, said we're never we're not gonna use master slave anymore. And you sent that link without a lot of context actually to the IETF at IETF list, which is the whole community. It's got thousands and thousands of engineers on it. And the list just exploded. So there were pea it was not a pretty one. I I laugh now, but it's just a trauma response. There were so many folks who replied, and many, if not almost all of them, were very aggravated by the suggestion that we need to change our scientific and very neutral terminology because of feelings. And I think we engaged as best we could at that time. And we there was just a very long thread and many different posts. And I feel like the draft was an exercise in pulling together all those arguments that were happening in different pieces of the thread into one complete place so you could follow the arguments. Right? It's like we were on one side. We were just working on all these different fronts. Right? Saying, well, people's feelings do matter. And then on the other one saying, and atomic clocks weren't even using that terminology until the '50. You know, we were doing, argumentation at every layer, and it felt really, all over the place. And so that document really helped us organize our thoughts and come up with a cogent argument for why these terms need to be replaced and then operationally how we need to do that. And then I think the next important thing so in the timeline then comes it the draft just sits there for basically two years, but then George Floyd was murdered by police and The United States exploded in rage. And it really kicked up this discussion again, not in the IETF, but in the larger tech community. People were talking about inclusive language in tech and elsewhere. And just the the race conversation in The US was so robust and it gave us an opportunity to re up this draft that had been sitting there nascent for a year and a half. And more, more and more and more sort of controversy ensued, but we did get a lot more attention to this draft. It was the focus of a lot of people's attention and time, not just us this time, but like many of the leadership gave us space on the main agenda to present it, to talk about it, to improve it. And then another thing that was great is the chair, the IETF chair at the time, who's an I a CDT alum, Alyssa Cooper, she just made it happen. She just created a document that listed all the term pairs that the RFC editor was to make sure were never used, documented that, and it just happened. We just don't use these terms anymore. And I just really, you know, wanna appreciate the leadership for just making those changes. I think they, at some point, also made some statements from the leadership perspective, like, in support of this. And so that was really another great milestone. And really since then, you know, the document is still an Internet draft today. It was never RFC ed. We've, made some attempts to get that document to become an official standard of the IETF. It might not have ever made community consensus, which is what would be required for it to be considered an informational document from the IETF, but we've also tried other kinds of publishing streams where it would just be like an individual opinion of the two authors. That also hasn't worked because folks feel it's too controversial. So I don't know. It might just have to live on the Internet forever as an is an Internet draft. What do you think, Niels? Do you think there's hope for us to get it RFC ed someday?

Yeah. I I really appreciate you telling this history because it has been a very intense time. And the barrages of thousands and literally thousands of emails were really intense. And and and a part of the episodes that we just kinda skipped over is, the posting of several counter Internet drafts that try to ridicule this work with some outright very racist language that were actually removed by IETF leadership, which is very seldomly happens from, from the archive of Internet drafts. And that's very that's very seldomly happens. I think it really shows how this community that's very organized in a very bottom up manner here really was ripping at its seams and leadership felt it needed to come in. And I think that the document isn't becoming RFC. It's showing that there is no community consensus, and that is that is scary. That is really scary to see also because these are the people that produce a technology on which our information societies run. On the other hand, it's also very nice to see that this community apparently is able to select its leaders to do the right thing here. So I think it's a bit of a mixed bag, and I think this is what happens with many human rights. Right? We will never attain human rights. Human rights is not a position, but it's a goal. It's it's it's a strife. It's where we're going for. But human rights are like muscles, right? If you don't use them, you lose them. So it's continuously trying to gain them in our writing, trying to undo the systemic injustices that we also reproduce ourselves in the language and our position in society that we're in and trying to create a better world. And this process was was part of that, and and and we learned in it, but it it also it also wasn't easy. So yeah. So there there are currently now, I looked it up, 14 official versions of this document, and, maybe 14 is where it will stay. And maybe later, it will we will get also better insights and better ideas on how to approach this. Because it was never our idea or our intention to shame people. We thought, like, we're going to try to make technology better. Right? And apparently, we also haven't found the language to bring people along in the, in this process.

exercise, and I think that is kind of a good way of putting it, like, you know, what our intentions were and what actually happened, you know, it's neither here nor there, but has really dusted up a lot of these issues, right? And that has been hard for Niels and me. I know it was really hard for leadership at the time but it's also been really hard obviously for the people who feel excluded in this community that, yeah, maybe they had some awareness that it's not the most inclusive space. It's pretty homogeneous, very attracts very white western male. But this whole argument and it being so volatile and so protracted, I think has had an effect on inclusivity in in a negative way because now it's been a kind of it's been a little bit more exposed now in the open. And so there has been some damage to having the conversation. It hasn't been a full, like, toxic cleanse so far. I think there's still and people's and this, you know, evidenced by the fact that, our ID isn't going to be our seed anytime soon is there's still some tenderness around that. I really wanna care and center the people who still feel excluded. I think we need to think about how this draft or other initiatives are either helping or hurting that, and that's where we should be thinking about, and less so on, you know, overall health of the community because I think it is a resilient community. We need to worry about the folks that are most marginalized.

Yeah. And I cannot agree more, with Mallory. And we also cannot have a healthy community if we do not have more people involved. And that is because the community of the IETF produces an infrastructure that is used all across the world. So we're entangled with these communities that are currently not represented in the people that set the standards. So that's what we that's what we should strive for and that's what we should work for and uncomfortable conversations should are definitely part of that. And I think that's part of the work that Mallory and I and many other great, civil society advocates are doing and have been doing since 2015, 2016, where we've been participating in the IETF and trying to maintain public interest topics and societal impact of standards, protocols, and the Internet architecture. And try to front that in the design process and try to make the Internet a better place by front loading these societal considerations to ask what do we want the Internet to do for the world. So that we don't need to shape the world after the Internet, but we can shape the Internet after the world we want and so direly need.

So to go to your really, the best part of your question, Jamal, about the the positive things that have come out of it, so the IETF is now alone in this. There have been a lot of different parts of the community that have addressed inclusive language, and it's been great for me to try to be as involved in those other efforts as possible to sort of compare, how it's gone in the IETF versus elsewhere, to create some solidarity between the folks trying to make changes elsewhere. And so that's been wonderful. So some of the places where this is changing, and we are in overall a much better position than we were in 2020, like hugely changed. So one was, almost right away, and this is actually what kind of sparked our draft to get re upped the 2020, was the Inclusive Naming Initiative was founded. They're like a sub grant or a subgroup of the Linux Foundation, but they're tech wide, and they really are developing this super comprehensive language guidance that includes everything from, like, sexist terminology to ableist terminology, military terms, like Neil's mentioned, all of them. They're trying to be as thorough as possible. And that group has been great and, you know, they cite our draft and I've been involved in their work, from the beginning. Another great win was, NIST and this is a US standards body, adopted and cited well, not adopted. NIST cited our draft in their guidance about, eradicating these terms. So that was very affirming. And by by extension or or as a result, the official adopted guidance that the IETF does have for this cites the NIST document that cites our document. So in a way, you know, we've sort of had an impact on the IETF directly. I and so zooming up to today, I know that the IEEE, this is the Institute for Electrical and Electronics Engineers, they do a lot of hardware stuff, they're known for the Wi Fi standard. Two things are happening there pretty imminently. One is that the last vestiges of the use of master slave, which was timekeeping in, Internet connected clocks in the, Wi Fi standard has been removed. And that has been balloted, and I believe that ballot closes very soon. And I I don't see any indication that it wouldn't pass. And so it will now the the excuse that we cannot eradicate it because it's still in use in some existing standards, that argument will disappear. So that's a really big win. And then the second one is that the I triple E's standard association at large from the very tip top of the organization stood up a working group to create language guidelines for all IEEE standards. And it is like the Inclusive Naming Initiative. It's everything in the kitchen sink. Every single possible offensive term is being in there, and that has been balloted. It's it's it's not initially passed, but there have been comments. So we're working on integrating those comments with another group of folks in that group. And so eventually the essay will will adopt that document, and that'll be a really big win too. And then lastly, in the last, actually, call we had on this IEEE document, I heard that ISO, the International Standards Organization, is also going to be adopting a top level language guidance document. So at this point, I feel like we've made collectively across the tech industry pretty big strides on this language piece and I just want to say it's a relief to be able to move on from this because I think I said earlier on it's like this feels like the smallest possible change and we have much bigger things to do in terms of improving diversity, equity, inclusion. It's like it'll be great to kind of feel like this work has achieved its goals, and we can move on to other tactics now. Again, I think you I think you touched on it, but I just wanna hear just a little bit more about where the work is now in the IETF.

So where we are now in the IETF is that when you, write a document, it is automatically being checked in a process whether you're using any of the known existing exclusionary language, and then you're asked to change it or to at least consider using different language. And then subsequently, in IESG, in in in reviews of the document, if it gets past the working group stage, people will also look at it and ask you, could you change this language? And and via that way, via community discussion, the language will get filtered out, and we haven't seen use of that language since. So practically, it has been, it has been significantly addressed. But as said, language changes. Right? So we need to be vigilant and keep on interrogating and understanding our role in society and our roles in reproducing systems of exclusion, inclusion, because we are not aware of many things. Right? And we cannot be, and that's why we need other people. So in a sense, we have worked on a thing, but that is just one step to just keep on getting better. But there is also no end to those steps. But it's been great that we have done one step, and we're working on many different fronts and we'll we'll continue. And some of some of the things can and will be addressed in the IETF and others not so much, But that's not a with no reason to not keep on working on them because the IETF is an institution with real power and we with real, influence. So that's also the reason why we are there and why we also stick around and do the work. To wrap us up, just any final thoughts from either of you? So among your audience, you probably have really great engineers, tech minded people, but also people who have very deep thoughts about technology. You are and even policy experts or maybe especially policy experts. We really hope that you can help us think us through the interrelations and the complexities of the interrelation between protocol and systems developments and human rights and policy implications. And if you wanna think about that and engage with the people who actually concretely build that, The Human Rights Protocol Considerations Research Group or HRPC is a very good landing place to do that, discuss it with us, to hear talks. If you look at the on YouTube, there are a lot of great past talks of the years that we've been doing this. We're also working on documents with which we try to analyze, Internet protocols. So a new document is about to be published on that that, Grover and I, edited, and that has been shepherded by, Mallory. And, in that document, we try to analyze Internet protocols, and we always need people to do analysis of new protocols to see and understand how they change. And in the past, we've seen that that this methodology has impacted changes in the standard setting process. So we need people to help us think through this because this is not something that this is not a solved research question. It's not that compliance between, between human rights and the Internet infrastructure has been achieved because the translation of these social technical and social legal concepts are, are not done, especially since both the understanding of human rights and the understanding of technology progresses very quickly. So if you're interested in it, come join us, else follow the work, but also you're very welcome, of course, to do your work where you're doing it. And that's the only way we can form a broad movement that works on social justice on all sides of society.

Yeah. Great pitch, Niels. I think HRPC is a really good place for this. I think there's still just to manage expectations, I I think that while we're really happy with, all of these different technical communities making these positive changes, there's still actually a long way to go. And it's a long game though. Like you were saying earlier, these these are exercises. We're strengthening muscles. We need more people to have more impact, and it's not gonna happen right away, but it's we're laying foundations so that we can do this sustainably and over the long term because that's the kind of change that's needed if we want the Internet to remain for people. Because I think, yeah, there is this counter trend or counterforce that's really difficult to come up against, which is just massive consolidation and corporatization of these spaces. It does, a lot of times, just feel so robotic and like we're surrounded by automatons, and it's hard sometimes to break past that, like, real dedication to sort of logic and neutrality and things like that when the stakes are really high, in the ways that these technologies have real world impacts on people. So, yeah, let's, move on and keep

moving on. Yeah. And if you feel like you wanna study this more or think about this, the initiative that I'm mostly involved in now is the called the critical infrastructure lab. And the critical infrastructure lab has two biweekly reading groups on alternating weeks. So every week, you can discuss books and read them together. The one focuses on the interrelation between, infrastructure rights and freedoms, and the other one is focusing on the interrelation between infrastructure and the environment. So if you're interested in that, go to the critical infrastructure lab website, criticalinfralab.net, and, look up the details. You don't need to register. You can just join. And,