Awesome. So welcome, everyone. I'll say it one more time to MediGov seminar. My name is Val, and I'm the research or sorry, community lead. And today we have a seminar called exploring the remarkable regenerative patterns and practices of the Internet engineering task force, or led by day Waterbury and kalia identity woman. So, this presentation is gonna be, yeah, I'll let the speakers I'll let the speakers do the introduction, but, I'm super excited to kind of hear about governance in practice and thank you all for being here. We'll have about fifteen, twenty minutes presentation, and we'll go into Q and A. So, as the presenters are sharing, feel free to type your questions in the chat or just type the word stack, and you'll be added to a list. We'll go in order of who sends their questions first. So if you've got a question, either raise your hand, type stack, or type it in the chat, and you'll be added to a list, and I will help facilitate the discussion after the presentation. And with that, I'll pass it to our speakers. Thanks y'all for being here.

Thanks. It's nice to be here. We're gonna share about this research we did this summer funded by some of our protocols and, come on. Let's get oh, there we go. So one of the reasons this Internet this research is important is because the Internet is perhaps the ultimate digital public infrastructure and is an active digital commons, meaning it's being co created and remade all the time. It's not static. The protocols that run the Internet have evolved, and they continue to evolve. This is just a quick shot of our research wall. And just after we spent a week at the IETF, we processed what we learned during their meeting, and we'll get into it in this research. Recipes for technology are cocreated by standards development organizations that define the protocols. And if code is law and coders follow protocols when they code, then the standards development organizations that define protocols are in effect legislative bodies. And if that's the case, then what are the legislative processes or protocols for protocol creation? And that's what we looked at with, you know, trying to understand the IETF and how it works. The IETF and its antecedents wrote the protocols that made the Internet, and it had a protocol its protocol TCPIP won a protocol war in the early nineteen nineties, this is before the web, against OSI developed by traditional ITU traditional SDOs, the ITU and ISO. And one can make the argument that they won this protocol war because their governance process or their protocols, were innovated by a community, and they embodied many of the wise democracy patterns and group works decks and social group works and social permaculture patterns. So before we dive in, people have asked us right up front what the heck is a pattern language and why are you using it. So these are the three pattern languages we used. But a pattern language is was first created to communicate about architecture and land use, and it has 350 253 patterns organized by scale, towns, neighborhoods, buildings, rooms, and details. So these patterns each pattern has a name, a challenge that it's addressing, context where it happens, a solution along with diagrams, and then the connections, which are the other patterns that this pattern is linked to. So this is an example of the first page of of one of the patterns in the pattern language. They are hyperlinked together. This is true about the first pattern language. That's those connections, like other related patterns, but it's also true about the pattern languages that we used. So they're nested both in terms of scale and relatability. So the wise democracy pattern language is focused on invoking and engaging the wisdom and resourcefulness of the whole on behalf of the whole, and it looks at power, participation, and wisdom. The group work stack is a pattern language for bringing life to meetings and other gatherings, so it's very focused on in person dynamics and qualities. And the third pattern language is from a book. It's slightly less well developed, but was quite useful for some key patterns that the IETF has, and it's focused on social permaculture. Hopefully, I can't where's the chat? Okay. There's the chat. Okay. Cool. And there's no questions so far.

Thanks. And then this is just a kind of just showing you an example of this a one of the patterns from one of the decks. This is a pattern moving toward Align It. There's an image for the pattern, a description of the pattern, and a pat category category icon. So all the patterns are divided up, into nine different clusters for the group work stack and related patterns. Both of those stacks are actually Creative Commons licensed, and if you were so inspired, you could download them for yourself. Before I dive into some storytelling about the origins of the IETF governance, I wanted to highlight these three group wise democracy patterns that we'll see see expressed in the story, constraints on concentrated power, limit collective distributed intelligence and holistic leadership and governance dynamics. So in 1969, there was graduate students who were, part of laboratories across the country, all funded by JCR Linklater and at ARPA. And they were they all had different mandates for their labs at different visions of computing. But the one thing they were required to do with their funding was figure out how their laboratories, the computers in their labs connected up together and started networking. So as part of this, they decided to document their work, and they they documented it using a format they called the request for comment. So the first request for comment was called host software, written by Steve Crocker. And the second RFC was also called host software because it was like a response to the first one. And then the third RFC is sort of where their sort of meta governance started, which is defining this document convention that they had just started. So the third RFC is called documentation conventions, and it some highlights from it are notes are encouraged to be timely rather than polished. The minimum length for a note is one sentence. We hope to promote the exchange and discussion of considerably less than authoritative ideas, and there is a natural hesitancy to publish something that is unpaused, and we hope to ease this hint of vision. So they were really trying to get people to write down in the moment what their best ideas were and share them with the community that was working on these. And in the beginning, you could get RFCs sent to you by mail. But as they built the network, they used the network itself to distribute the RFCs. And these this is obviously RFC three. The current document conventions conventions for RFC are much more sophisticated, and there's a really sort of RFC. Things with the RFC name have gone through a whole process and are kind of done completely, but they are also still open for comment. They're always updating and having new RFCs deprecate old ones. So, the network working group in 1969, there was several different iterations of this group with different names. There isn't time to go into them. But needless to say, there was a lot of history. And by 1984, this group was called the Internet Architecture Board. And they, over this time period, published hundreds of RFCs articulating their core protocols that became the Internet. And so you have the this arc Internet architecture board. And at this time in the late early eighties, the funding for computer research was shifting. The government was deprecating its funding for this network of labs, and more commercial players are coming on to participate in working to in the network. And they decided in 1986 to host a more open meeting that they called the Internet engineering task force and invite more people in. This this group grew, and so by the fifth meeting in 1987, they had working groups. By the fifteenth meeting, there was sufficient number of working groups. They divided those into areas, and they needed to have those areas be led. So the Internet architecture board appointed area directors to lead each of the areas, and together, those area directors formed the Internet engineering steering group. So this was the structure in 1989. And and it's worth noting that as they changed their structure, they they documented

these changes using the RFC as the way to communicate their changes in their own governance. Meanwhile, in a neighboring part of the world, the International Telecommunications Union and ISO, two very old school standards bodies, developed a competing set of protocols called OSI, open systems interconnection. That will become important in a second. So the IETF structure in 1992 basically is the same as it was in 1989. You had at the bottom, the working groups where all the main work happens of the organization. You had a second level of hierarchy with area directors. You had the collection of all the area directors together, and you had this Internet architecture board, which was the sort of final decider of whether an RFC was complete or not and could be published. And the Internet architecture board as we described before was appointing area directors. Now by this time government funding was really going away and they needed an an organizational home because they actually didn't have a legal organization. So the leadership of the IAB was looking at creating the Internet Society. And in fact, they had the first meeting of the Internet Society and the Internet Architecture Board in June 1992. And it was in Kobe, Japan. And at that meeting, they they made statements coming out of the meeting that were somewhat confusing. But they were read by the Internet Engineering Steering Group and IETF as pivoting away from their work towards what is called IPB seven, which was a naming space convention that the OSI stack had been working on. And this created enormous consternation amongst the community because they were those telco guys. And they basically led a revolt. And the next Internet engineering task force meeting was a month away in July 1992. And this this was the sort of main takeaway slide that happened in this presentation by David Clark. The presentation's called a cloudy crystal ball. And he said the standards elephant of yesterday is OSI, and the standards elephant of today is right here. As the Internet and its community grows, how do we manage the process of change and growth? Open process, let all voices be heard. Closed process, make progress. Quick progress process, keep up with reality. Slow processes, leave time to think. Market driven processes, the future is commercial. Scaling driven process, the future is the Internet. And then he just added this line to the slide. I just saw him at the Project Liberty Summit, interestingly enough. And it wasn't really like he planned for this to be the big takeaway, but it became that for the community. It says, we reject King's presidents in voting, namely those other institutions that are status and have kings and presidents in voting. And we believe in Rust consensus and running code. So they also as they do when they have a problem with their own governance, they create an open like, a working group to solve the problem, and that working group spent several months. And by December 1992, they'd had worked on a new structure, which we'll share. But at the core of this new structure was an agreement that all subgroups in the ITF and ISOC that have an official role in standards process should either be open to anyone or have well documented restricted member in which the, quote, unquote, voting members are selected elected or nominated through an open process. I put voting in quotes because as you just heard, they don't believe in voting. And in fact, voting is taboo within the IETF. It's more like the people who are if there's a if there's a we'll see this in the next parts of the presentation. If there's a group that has power to decide something, that's what they mean by voting members. And this rebellion against the structure was, I think, an example of not about us without us. The engineers were determined to not let the IAB that was sort of a council of elders who hadn't been directly involved in making protocols, some of them for years, said, no. You you can't make these decisions about the direction of the organization and the Internet without us. So what was the structure afterwards? So you had, at the base level, the working groups for most of the work happens. You had area directors, and you had the IESG together. And this body became the kind of final decider of RFC standards at this point. Now what happened to the IAB? Well, the IAB moved and became a parallel institution focused on long range thinking and discernment. And you still have a governance challenge, which is how do you decide who should be an area director and who should be on the IAB if it's no longer just the elders. So they invented this process this group called the nominating committee. And we're gonna walk through, how that works because it's probably the core governance innovation that is most amazing about the IETF. So the nominations committee is at the heart of the IETF as a wise democracy, and it decides which people are area directors and the overall chair of the organization who sits on the Internet architecture board and people who sit on the boards of directors of the LLC trust and the LLC and the trust. Oh, forward. So they use sortition, that is random selection, to pick who gets to be one of the 10 deciding members. The qualifications are listed here. The easiest one to remember is that you have attended three out of the last five IETF meetings. And the last time they went through this, there was a 164 people who were willing to serve on Nomcom, and they picked 10 of those people by this quite fun and elaborate process they have for doing so. Those members deliberate on who they should appoint into these leadership positions throughout the organization. And then there's privacy guarantees. So they solicit input on all potential candidates for all positions, but that feedback is private just to the nominating committee. And the nominating committee's deliberations are also confidential. So this is one of the few places within the organization where there is not transparency but it's for good reason so they can deliberate and make a good decision. This structure has a consensual hierarchy. This is a pattern from the social permaculture pattern language. Power is earned because they are basically applying for a job and being scrutinized and interviewed, and, you know, other members of the community can share where they think they'll do a good idea. Power is shared, and we'll get to that on the next slide about how distributed the different organelles within the organization are. And communication throughout all levels of the hierarchy is really open. So there's extensive tooling, and we'll get to that in a bit as well. And all of the leadership positions, I think the the IAB and the area director positions are only two years, so those are the ones that have the most power. And I think the LLC and the trust positions are three years. So I'm showing you this is a bit overwhelming. I know. But the point was not to have you understand the IETF governance, but to get the gist that all of those all of the organelles of the IETF at in level three are parallel institutions. There's no one one part of the IETF that sits above all of them, and they have mutual accountability across them. And level one is where the working groups are, and level two is where the area areas are. Right? And even over here, there's still, like, three levels in in these other institutions and their relations. The IETF meets three times a year. And in each meeting, there is a plenary session where all entities in the map that we just shared are present, and they have the whole system in a room having a whole system conversation. It's pretty amazing. And so these are back to the the the three patterns that I started out with saying we would cover. There's constraints on concentrated power, collective distributed intelligence, and holistic leadership and governance dynamics at play.

No. The our pattern languages, the group the GroupWorks deck has 91 patterns, and I think Wise Democracy has, I wanna say, a 109. So these are different pattern languages than the original pattern language. Okay. I'll just touch on a few more things. They have process. It's very sophisticated. So maybe, Day, you can talk through the slides. It's your side.

Yeah. That's true. Oh, sorry. Go up. This is the part of the reason the tooling associates get it is this is the process for starting from an Internet draft to becoming a working group draft to going through the IES balloting IESG balloting process. Yeah. It's pretty sophisticated process, but it's all documented, so you can follow along and understand it. They ground their technical and governance protocols in rough consensus and running code, literally. So you can't get an RFC to completion unless you have two working two different code bases implementing it. And what else do we have? I think I pulled up a few. Where are we? Another thing that is really fun is, like, ITF meetings are, like, joyful communal labor festivals. They have a lot of fun doing the work they do. They really care about each other, and there are yeah. It's just a really good feeling being there, and this pattern is

This is a snapshot of a one of their a week, a typical meeting. There's just a lot going on. That was the point of this. And they have really good patterns throughout their their week. Yeah. This is a part of one day. All those little buttons, those little icons on the right hand side are all to different pieces of the tooling to access the information about the event. They have a strong sense of place at their meetings. They basically replicate the same meeting, but in different hotels all around the world. They also are very good at celebrating, appreciating each other, and practicing grief together. They memorialize people who've passed between meetings, and they are just, yeah, these are all really healthy community patterns that we saw present. Their meeting diverges between the whole group and the subgroup. There's divergence and convergence happening. They balance structure and flexibility and reflection and action. So these are some of the polarities that are present that they do well, which is why things feel really good. And they cultivate a really strong group proprioception, which is a term we we we invented to talk about why you don't feel lost in an IETF meeting. Once you get the hang of it, is each little subgroup knows exactly what it's doing and how it's doing it and has a clear focus, and it has clear boundaries. And all of all of this is extensively documented. So there's always a purpose and an intention setting and and this boundary kind of management going on throughout the organization. Yeah. This is their mission. Open process, technical competence, volunteer code, rough consensus, and running code, and protocol ownership. And there's this question of how can you be so totally open so anyone in the world can join any of the working groups. And part of it is because they have such clarity and focus in what they're doing. And this openness actually makes them stronger, you know, according to I believe it, and this is sort of Meg Wheatley's analysis of these dynamics and open systems that are self organizing. And just to, I don't think this is as good as it is. Yeah. There's another one I've done that has more of these on it, actually, but I was trying to sort of document, like, that map of all the organizations. You can layer in all the RFCs about all the different pieces and, like, go read about them. And this is another example of, like, all these different roles within the organization have very clear documentation. And that feels like a good place to sort of pause and shift and move to questions if folks have them.

Yeah. Awesome. Thank you. You guys so much. This was such a great presentation. We definitely have lots of questions popping up and thank you Dave for, like, already and you too for answering some of them in the chat. But I think if I scroll, I could have been the first question here. And it was back when you were giving us the history when you were saying that, I think it was, like, back in the nineties. Maybe it was, like, the government, and I was wondering if it was The US was pulling funding from IETF. And then I was just wondering, like, why and how did the changing fund funding landscape shape the work being done at that time or still?

It wasn't yeah. So the the US government had funded these computer labs to do their computer lab stuff, and, like, part of the agreement was that they would figure out how to network themselves together. And at some critical junction, they basically phased out their funding. So it wasn't sudden, but it was very clear it was happening in a systemic way.

No. Yeah. Like, it it has it doesn't it its only funding source is the payment of the payment of attendees to be at the meetings. That that's not quite true. For a long time, that was its only funding source. And then now it has some sponsorship of the meetings, and it has a way that you can, you know, donate to it. But it's not kept alive by corporate or government money per se. It's kept alive by the people who keep showing up and paying the thousand dollars to be at the meeting. Cool. Does that yeah. That's another question.

Yeah. Great. Thank you. I think Ben was next. Benjamin. Sorry. Benjamin had a a comment. I think yeah. If you would if you would like to speak to it, basically, I think you said you're on a flight, participatory membrane seem to emerge in protocolized governance where voting or staking show up in decentralized governance. Not a question perhaps, but if you wanted to speak to that interesting comment, feel free.

Yeah. Cool.

And there's there's a

Oh, sorry. I was just keeping track of the stack. I think next is Lydia's question. Lydia, did you wanna speak to your question? I can also read it.

Yeah. And there there is one actually, there's another constraint we didn't mention, which is cannot have two people more than two people who work for the same organization on Nomcom. So there's a kind of limit on, like, how many people can work for an org. Yeah. So that's a that's a constraint on power too. And like they said, because it's it's constantly rotating. Like, terms of area directors and IAB members are only two years, and there's a new random group of people doing that deciding every year. It's there's a reason that there isn't, like, charismatic leaders of the IETF beyond the elders, you know, like, Vint Cerf and Dave Crocker, Dave Steve Crocker and Dave Clark, who I saw this week at Project Liberty. Like, they they're the people who invented this process and supported the community coming to these governance innovations.

Well, so the next question I have, our person is, Charles. To what extent are these org charts and other visuals newly created? I think I saw you answer that in the chat. Right?

Yeah. It's one that they they made Their their chart, I was so grateful when I found it because I was like, I don't wanna have to draw it. It was like the the crazy orginal chart, that's them. But everything else you saw, I created to explain the organization.

Cool. And Benjamin asks, what would you say are the generalizable patterns you noticed in your research that might be relevant for contemporary groups working towards open sociotechnical protocols?

Yeah. So I'm just sharing this. This is my drawing of that crazy drawing. The other this is more like the IAB and the IESG and their direct sort of universe of things they're responsible for. Generalizable patterns.

No. Holistic leadership and governance dynamics.

Called out consensual hierarchies as kind of, like, a understand. I think part of it is, like, patterns can be expressed in many different ways. Right? So part of part of why we found these three pattern languages had explanatory power is because of how many of the patterns are present, which is why the institution is so vibrant and alive and high performance. And they didn't have the pattern languages to figure out what to do. Right? They invented this, and we're sort of using, like, using the pattern languages as as one, like, a way to document and see what's going on, but for their own explanatory power of why what they're doing works. Right? So I think, to me, the thing that is most interesting about what they did is they kept they have such a strong feedback loop listening to their own sense of what is and isn't working. And you can watch this is active process within the organization today. They are always asking, is our process working? What if we did it this way? Okay. Let's do

And if it doesn't work, go back to 122 coming up. They've had a 122 meetings of iteration to figure out how it works. Right? And they they keep returning not what they should do or what some corporation is telling them, but what they think is good. The other thing we found is there is there is no external locust of control in the way the IETF talks about itself and the way it operates. There is really a strong sense of we and and a we that is has agency. And if you're in a particular group, you understand what the we of that group is capable of doing because like I like we pointed out before, there's all this documentation about how things how things work. So I think strong documentation, strong sort of capacity to iterate and update and change and grow, like, those are all things that I would take away from from the IETF.

Also And

Well okay. Big question incoming. How has this governance structure fared as corporate capture of the Internet has accelerated?

So I it's it's interesting because all people who work for all those corporations show up the ITF and make it work. I think there's a challenge because the platformization of the Internet is different than the Internet. And the so called corporate capture is more about business models and usability. And, also, like, I think a generation of people who instead of making protocols out in the open made products that were designed to capture people. Right? And I think part of how we address corporate capture is getting back to protocols and an insistence that we use protocols to communicate, not platforms, and that we educate deciders of platforms no. Deciders of tooling that they need to decide to write into their contract that they are using protocols and that they're behind protocols. But we don't we don't tell this we don't educate people enough about these choices. And, you know, I think there's also an opportunity to bring protocols into the IETF. I've been talking with someone about you know, there actually are a bunch of social protocols at the IETF, and it could be its own area, and it could be a place that more of us go to do work if we choose to. It's not, like, only for quick and routing protocols. There's message layer security and more more instant message interoperability, Mimi, and there could be more.

I mean, arguably, it costs about $5,000 in tangible costs to get to a meeting, and there's three of them a year. So that's 15,000 a year plus, you know, time to participate actively in cocreation of things, you know, like, time for the whoever that person is. But I think these costs relative to other choices, I think there's a profound futility in this so called Internet governance forum,

the ITU created to try and convince civil society that it should govern the Internet, not the IETF. So there's there's still, like you know, the people who lost the protocol war are mad they lost the protocol war and are still trying to figure out how to avenge this loss, and they have convinced civil society that they are on their side. What's the anything that

Someone was saying something.

I I

Well, so, unfortunately, we're out of time, but I love these lively discussions that go right up till the end. And we are more than happy to bring this over to Medigap Slack or perhaps continue a discussion on another call, community call or somewhere else. So, definitely, folks, if you'd like to continue the discussion, we always post the link to this recording in the Medigob Slack, and we can start the thread, basically, following up on the final questions. We had an interesting one about kind of this stuff with at protocol that Chad posted. And there was one more question in there that I I grabbed from the chat. So I'll bring those over to Slack, and we can continue this discussion. I'll send a link to join our Slack in case you're not there already. But, yeah, thank you all so much for joining us today. If y'all don't mind unmuting, let's give our speakers a big round of applause. Thank them for being here. So when you're ready Woo. Lots of love. Thank you, Dave. Thank you, Kalia, so much. Posted the link to join our Slack, and let's continue discussions there. Have a beautiful rest of your day, y'all. Thanks for coming. See you soon.

Thank you.