Standards and consensus
Tim: [00:00:00] Hello, this is the distributed future podcast and I'm Tim Panton
Vim: [00:00:06] And I'm Vimla Appadoo
Tim: [00:00:07] and the podcast is about helping people understand what the future might look like. And we're particularly interested in what technology is doing to, our future and. To do that. We talked to people who are shaping that future, by shaping technology and to some extent that relationship with society.
So that's, our, our thing. And, there's a whole lot of stuff that we've done in the past, which we'd encourage you to subscribe to, to, to catch up on. And we'd be, recently been alarmingly, right! So, so you should go and listen to this stuff and you'd find out what the future may hold. So, This time, we have Adam Roach with us who we're going to chat about how standards affect society and technology.
So, Adam, perhaps you could introduce
Adam: [00:00:58] yourself. Sure. my name's Adam Roach, I've been working with mostly voiceover IP and instant messaging related technologies since about 1997. a lot on the standard side and implementation as well. I spent some time in sort of traditional telecom, moved in 2012 to work mostly in the browser space.
So that's, that's kind of the trajectory. I spent like three years from 2017 to 2020, until March of this year, serving on the ISG for the IETF, which is kind of the, the management board for their standards for
Tim: [00:01:42] work. So I'm kind of interested in, in what those standard boards do. I mean, w w why would, why do we bother with standards in the tech world?
Why don't people just like innovate and be free to do whatever they want? Why do we need standards at all?
Adam: [00:01:57] So, I mean, there, there's a bunch of innovation and people doing whatever they want. what we end up with is a need at some point, for people to work different systems together. And while you can do that sort of stuff by just sort of publishing API APIs and inviting people to work.
with those it's kind of difficult to build a very large ecosystem, especially on sort of an equal footing without having sort of a more, well-defined and, and better serving a larger community.
Tim: [00:02:34] is it I'm kind of hearing is something that's almost egalitarian in that you say on an equal footing and whatever.
Are we talking about kind of pure egalitarianism? Or are we talking about kind of equal market access?
Adam: [00:02:48] I mean, in my ideal world is, is more of a pure egalitarianism. And a lot of it varies on like which standard bodies you're going into talking about, but the one that I'm. Most familiar with the IETF, a large part of it is you ended up with, various folks showing up with their varying requirements and they're given an opportunity to put forth arguments that those requirements should be accommodated in the specifications.
Whereas, you know, in, in situations where you just have to say publish APIs, those are, those are meeting the needs of the people who are publishing the API APIs. And frequently don't really take into account the use cases of a broader community of people who want to use those technologies.
Tim: [00:03:29] So, I guess we should say a little bit about the, the IETF, which is, and I think it's somewhat of an exception as a standards body, in, in some ways in that it's "internet engineering task force".
and I it's origin is kind of quite academic, I think. Is that, would that be fair?
Adam: [00:03:54] sort of, so, I mean, the IETF came out out of the, the DARPA, effort, the defense, there was a department of defense us initiative and yes, the initial bodies that were participating in this were all universities. but the notion was going with a data network, I believe originally to coordinate the defense related activities.
and then it moved forward from there, but it's been around since. I want to say the sixties it's been quite a long while we just, yeah, we just had a Centennial, sorry, like a 40 year, I think, celebration or something along those lines. and it did eventually grow into something more commercialized.
The internet itself became more commercial. So at this point, if it's the people who's participating in it, it's a pretty good mix of academics industry. And do you even have, folks who are, I think sort of more mission-driven I know there are a lot of people who work in the, yeah, you have still, who are retired or semi-retired, but just believe in moving technology forward.
And they either self-fund, which is a relatively amazing thing, given the kind of high cost of going to IETF meetings, or they go out and find people to sponsor them to move technology forward. But that's kind of the people you have, participating at least in person, the, the ITF nominally. Yeah. On mailing lists.
And there's very little barrier to entry, which is, that's the huge difference between the ITF and a lot of other standards bodies is basically anyone who wants to show up with an idea can do so you can basically come on a mailing list, participate in the discussion of technologies that are being considered.
And, you know, put forth contributions that can be incorporated into RFCs or, you know, it ended up being the basis for RFCs that were RFCs or the output of the IETF, the divine, the techno
Tim: [00:05:57] I'm
Vim: [00:05:58] sorry, we're using a lot of acronyms. What's an RFC?
Adam: [00:06:03] I'm sorry. So RFC, nominally stands for "requests for comments". And this kind of goes back to sort of the, the humble roots of, of the ITF, which is.
When the folks who originally started working on this were first creating these documents. They weren't putting them out. As you know, these are specifications. It was more, Hey, here's where I think that this technology can work. What do y'all think? And, so that, that was sort of how they got their. their an initial name it's a lot more formal nowadays where the sorts of things we put out.
Hey, what do you think about this? Are there called internet drafts? And those get refined into things that can be published as RFCs, but the process nowadays of going from sort of your initial idea and putting it on a draft all the way through to the process of publishing an RFC ends up being a fairly long road.
Nowadays, initially it was basically just sat down with a sheet of paper and a typewriter and, you know, 15 minutes later, but something out of the circulation.
Tim: [00:07:06] Yeah. I mean the output of an RFC is supposed to be something that would allow you to. Implement that protocol, that standard, without reference to pretty much anything else, it should be like, I mean, apart from potentially other RFCs.
So you should be able to take that document and sit down with a computer and enough time and implement it. and that's the kind of, it's sort of almost supposed to be complete in itself. and I mean, whether that implementation turned out to be useful, there's a whole other question, but like, It's a sort of, it's almost like a recipe in effect, of, of like how to do things.
Vim: [00:07:50] And then how, so, one of the things that I'm really passionate about, especially when my thinking around the future of the internet and the technology it is built with is how diverse is the feedback that you get? Like, is it coming from lots of people, lots of different backgrounds, or like what's the border people kind of comments in like, That
Adam: [00:08:11] depends an awful lot on the technology being developed.
So you end up with things that are like very interesting to a broad variety of folks. I'm going to hold out webRTC as an example where wherever it's used, the technology that was defined for allowing voice and video transmission in web browsers. And then you end up with things that are kind of, more esoteric.
And I'm going to keep drawing examples from the realtim communications area, which is where I be, but there's the. I mean, I've seen things even more academic in this, but when you get into things like how to define a transmission of geolocation or how to, authenticate that a caller is who they claim to be those, because they're just kind of a little more niche in terms of expertise, expertise, and knowledge.
they draw significantly less input. so like the group that defines the identity work that was talking about the asserting who's calling, those in-person meetings tend to be maybe, you know, maybe 10 people, if you're lucky, actually participating in discussion and you have the same, the same 10 people generally participating on the mailing list.
If you look back to the heyday of webRTC, where you had, you know, an awful lot of people with an awful lot of interest, you know, both people who were like. Working on web browsers and people that want to write applications for them, as well as people who are like coming up with implementations that are going to talk to those web browsers.
That was a huge crowd we would have, like at the face-to-face meetings, we would take over the largest available, well meeting room and fill it to capacity. And you would have very lively conversations in the mailing list. Sometimes you would have, you know, dozens of mail come in over the course of the day.
so again, it depends an awful lot on which technology you're talking about and, and sort of how accessible the concepts are.
Tim: [00:10:09] I think it's worth saying that a lot of these things that you, become surprising new relevant later, like you, you look at something that seems like fairly innocuous, like how do you identify a person or something?
And then. I, and it seems like a niche aspect. And then suddenly you find it's been baked into a billion browsers and it turns into a privacy matter. so there's like, you know, a lot of this stuff, although you end up, you start out with quite a small group, maybe defining it. they still have to be quite careful, I think.
And we're learning that I think still,
Adam: [00:10:45] right? Yeah. So I think probably the most, the most spectacular example of that is, There was some fairly recent work called DOH that was set up to define the DNS over HTTPS. Basically it was a mechanism by which you could retrieve IP addresses based on names, usually in a web browser context and do that over the same protocol that's used for retreiving webpages.
So basically you couldn't tell the difference between the DNS berries and the, and the content retrieval itself. And it was, you know, it was a nice optimization and allows you to do some kind of neat things, because one of the big things that web browsers are constantly trying to do is, is make page loads faster.
And this was a way to make that happen. but it also has some like, sort of anti-censorship properties and that particular aspect of it did get some people up in arms. And so after what was initially, you know, kind of a sleepy start, the protocol you ended up with, a near riot. I think we've had like a couple of follow on working groups.
That have had just extremely vigorous input. Like I said, with whoever webRTC, we had dozens of messages that there were definitely periods of time. We'd end up with several dozen messages coming in over the course of even just a few hours on, you know, how the protocol itself should be refined and, and additions to it.
So, yeah, you definitely end up with cases where things with humble beginnings end up having wide sweeping. Ramifications that are really only noticed by people seem to be significantly later.
Tim: [00:12:23] So I think one of the things that we should maybe like talk around is this is a process of kind of anticipating the future. I mean, in a lot of cases, what you're trying to do is get an experts into the room who were kind of trying to say what the future looks like or are we are codifying what already exists mostly.
Adam: [00:12:45] So I think it's fair to say there's a lot of both things happening. so you have some obvious examples, like email that had a lot of like really popular, but not interoperable and antecedents, like back before, the SMTP and we're going way back in internet history here. But back before the simple mail transport protocol was defined by the IETF.
You had things like CompuServe and AOL and whole bunch different corporate systems that implemented email, but they couldn't talk to each other. so, you know, the IETF stepped in and defined standardized protocol that allowed those sorts of things to inter-operate. You know, if we saw that happening, initially at least within some messaging, you had things like, you know, what was it, an aim and Yahoo and messenger and the whole other proprietary, you know, like non-interoperable proprietary ecosystem, that were at least momentarily displaced by Jabber XMPP.
And. then that actually ends for some fairly complex reasons that I'm not even certain. I have a grip on it, sort of devolved into a tower of Babel situation after that, where it broke apart again, and just sort of not interoperable systems, but there it's, a lot of the efforts do start out as sort of, there are some existing technologies that don't talk to each other and then you have to standardize them so that they can, And, you know, in a similar way, you know, voiceover IP video over IP, you had some provide recommendations like vocal tech, Skype, and a lot of the early work on VoIP standards was just sort of matching what was out there in the field.
But you did later on how a significant amount of forward working or we're looking work to meet the requirements of VoIP systems and, you know, new capabilities, like I'll cast back to, you know, conveying geo location information so that you can do emergency services and that sort of stuff. And then the.
Cryptographic identification of users that was never part of the existing systems. That was just something that sort of evolved as a need as the technology matured. And those were, you know, those were sort of pioneered in working groups in the IETF as opposed to coming out of existing technologies. so like, there's this fair bit of both.
I mean, the efforts, like webRTC I think probably do a lot more of the leaning forward as well. I'm not going to claim they're weren't anticedents there as well. You had, you know, like flash. Yeah. RTMP and there was the Google Hangouts plugin, but the, the big part of that effort was to make it so that you could have voice and video communications without downloading additional software.
And both of those were downloading additional software. So I would characterize that more as a, almost exclusively forward-looking, you know, building the future as opposed to codifying the past kind of effort. So you see all up and down
Tim: [00:15:25] that and what, like when you. Looking at people who are taking part in this process.
I mean, Vim kind of touched on this, but, but that's, there's a geographical spread of those people. I mean, you know, the internet is covers the world. Now how to, what extent is this kind of, American centric?
Adam: [00:15:46] so I would say at this point, at least the groups that I'm working in have a very strong participation from North America and Europe.
And I'm a North America, I'm talking about the U S and Canada. and a lot of Europe, there is a fair amount of dissipation from Asia in, other areas, not, not quite so much in the voice over IP and, in terms of, the rest of the world, it tends to be, you have some, you know, enthusiastic folks showing up and doing good work, but the overall level of anticipation, tends not to be quite as high.
I don't know what to. But to attribute this to, but that's, that's kind of where the preponderance of the participation that I've seen comes
Tim: [00:16:33] from 'cause we had, we had, a fascinating, interview, well, a couple of episodes back on the internet in Malawi and, and how. Different and similar it is. So that was, that was really revealing.
And I'm kind of wondering to what extent those folks get a say in, in, in, in the future of the internet, I guess the answer is if they turned up they could.
Adam: [00:16:59] Right. And that's, I mean, that's kind of a, that's a heavy lift as I mentioned. So the IETF of is notionally open to anyone who wants to participate.
And, the, the work does officially take. Place on mailing lists, but in practice, it is a lot easier to dissipate and make progress on your ideas. If you can show up the in person meetings, at least back when those were a thing. And I, I, I hope the IETF gets back to a point where we can meet in person again, but, while there's no membership hurdle to his participating, like there isn't a lot of other standards bodies
it's an expensive proposition like between airfare, hotel costs, registration fees, and other sundry costs. You're doing well. If you get away with paying only $3,000 to go to a face-to-face meeting they're week long events, typically not in the cheapest cities in the world, they're sort of optimized for easy air travel access.
and so what that means in practice, your core IETF participants are people whose days job they jobs are closely tied to the technology that they're working on. or, or academics who are doing research on those technologies. So it's unfortunately, yeah, it means that unless you have good sponsorship for this kind of thing, then participating at that level becomes very difficult.
Vim: [00:18:23] Yeah. It's really interesting because as much as there's a like a need and want to go back from their virtual world, I hope that kind of being online and having to do it in online spaces means that it levels the playing field a bit and kind of open up just that conversation ,
Adam: [00:18:43] yeah. I mean, it certainly would be great if, if one of the outcomes of this long year we've had is that you end up with better participation from, from the rest of the world.
Tim: [00:18:57] Yeah. I mean, I think, think that would be, that would be encouraging and although. I mean, the other side of that is the technology. We're all using to talk to each other. Was the outcome of an IETF process. So like, you know, it's kind of been to some extent, something we've relied on this this year. So that's kind of, worth thinking about maybe to some extent.
So what are the other thing I wanted to touch on? Which I think probably you. Experience most in the webRTC in your role in the webRTC discussions, is that it's achieving consensus? Cause like there were a lot of people in the room with a lot of views, and some of them diametrically opposed and some of them like had specific reasons for being, you know, having particular views and some people had experienced it.
Like it was a quite a thing. So kind of you must've been in the middle of, of, of that. How, how did we. How did that go? What was it like? What did you use as a tool?
Adam: [00:19:57] Yeah. so I want to back up real quick and just on this topic of concensus to say most of the time, honestly, it's really boring. I mean, you'll usually have just some tech decisions identified that, you know, needs to be made and, you know, someone will go off and do the analysis of what the various options are and what properties they have sort of list of pros and cons.
Come back with that, to the working group and say, you know, here's how, here's how I think it plays out. And here's my recommendation, then usually you'll have the working group look at that and say, yeah. Okay. It looks good. I mean, so from that perspective, most of the time, and achiving consensus inside protocols in, in standards, bodies is just, it's really kind of, you know, your average, almost boring engineering work.
Right. but I mean, what you refer to is, is you have, you have cases where, people with conflicting requirements or, or strongly held beliefs about how a design should work, show up and. for that, a lot of it comes down to sort of the personalities involved, how strongly they hold their positions.
and that, that requires being able to sort of thread a very tricky needle. And usually that comes down to sort of teasing out what people's actual real requirements are. and people are bad about actually stating those is most of the time in standards, bodies, the IETF in particularly you'll have folks show up with.
"Here's the solution. Let's go ahead and work on it." And there are people who look at us like, well, I don't like that because of X, Y, and Z. And the folks who showed up with the additional protocol, have a hard time explaining why those features were designed. They way they were in their, in their proposal.
And so you end up kind of having to spend a lot of time working with them, backing out what their actual requirements are and which ones are important, and which ones are just kind of, but I'm going to call it aesthetic, like in the final equation, things that they're willing to let go of. and so after you've done that, it actually ends up being a lot easier to sit down and, and work out a, an approach that satisfies the important requirements of everyone involved, you know, to a relatively great extent.
and you know, it's a matter of sort of identifying where compromises can be made that are, aren't going to make people so angry. They walk away, and getting people to agree to that. And a lot of it, a lot of that is coming, getting people to realize. That they're giving up as much as the people who they disagree with.
And, you know, at that point they're kind of like, yeah, I'm, we're all in this together. And as long as I'm getting enough of what I want and they're getting enough of what they want and then we can move forward. But as you sort of referred to this can get very acrimonious. There were a few different topics in web RTC, where this came up, where the, the big, almost famous one at this point is selection of a video codec.
and that was a huge multi-year battle even before I was really involved in web RTC heavily, they sort of asked me to come in and mediate that discussion at one of the Paris meetings, just because it had gotten so bad that like everyone in the working group was partisan. I could, I could show up and legitimately say, look, I really don't have a horse in this race, but, y'all need to come to some kind of decision here at that point.
It didn't really make much progress, but I mean, that's kind of where they were and, I mean, just to sort of put a little bit of a notion of how intractable positions were you had, uh, a group of important folks who were saying, look, VP8 one of the codecs that was developed to be ostensibly, unencumbered by IPR.
It's like the fact that that was developed outside of, uh, any sort of standards process whereby you could verify that claim. Makes it too high liability for us. We just can't deploy it out. On the other hand, you have, especially for web browsers that are distributed for free with, without, you know, any ability to really license codecs like both.
So the problem with h264 is that it's royalty bearing. If we use it, we're going to have to pay a per user license fee and that's something we just can't afford to do the margins on free or nothing. And so you can see like that, that was a complete set of loggerheads. and that it's ultimately the way that that was settled.
It sort of came down to sort of a work around for the licensing fees, which is a longer conversation that we can probably have today. But we ended up with a proposal that I brought for it whereby effectively the web browsers were required to implement both codecs. And, the reason that was kind of a winner for most folks is that, that means that if you want to inter-operate with the web browser, you only have to choose one because the web browse be guaranteed to inter-operate with the one that you selected.
and that, I mean, everyone came away from that pretty unhappy, but that's really kind of, that's sort of the sign of a good compromise and consensus process when the topic is so contentious, is that everyone leaves. Unhappy, but everyone leaves us out as unhappy as everyone else.
Tim: [00:25:01] I think I was one of the rare people who was actually happy with that decision, but then like, um, I'm in a, an odd position from that point.
It's when you view, I wanted to talk about one of the kind of oddities of the. Of the IETF and the way that it's kind of evolved. And it has some tools for which I think didn't actually help it in the codec discussion, but, but it has some tools for trying to kind of gauge the sense of a room and gauge the, get
to a conclusion. and it, and I think it's, it's kind of almost more like, like the Quakers in that respect than it is like a kind of a voting, Organization. I don't know if you want to talk about that
Adam: [00:25:43] or no. I mean, so you put your finger, it actually does. It evolves from an old Quaker tradition. The, so one of the things that will frequently happen at in-person meetings after there's been relatively long conversation where, you know, folks have gotten up and given their technical reasons for wanting a particular path to be taken, is that the chairs of a working group will ask for what's called a 'hum'.
And th the notion is they will put forth the typically two different options and ask the room is like, if you want option a hum now, and you'll get sort of a hum that's it's based on both the number of people who agree with the position, along with their level of enthusiasm. And then they''l ask , the same thing for the opposing position.
And the hums aren't really dispositive. It's more a matter of trying to figure out what to do. We need further conversation on this topic or do the people here generally think that the technical arguments have been made and we can move down a path now. So it's one of the things that's frequently said about the ITF is that there's really no voting.
And a lot of people showing up for the first time, look at these things. It's like, well, wasn't that just a vote? And the answer is no. because, like I said, it's, it's not exactly as dispositive, but it is a tool for measuring where the consensus exists. And I know that's kind of a subtle distinction, so that's
Vim: [00:27:10] really interesting.
And I think there's something really exciting about using that approach in different circumstances. I don't know how you, well, I'm excited by the opportunity. That's kind of rolled out that approach to community decision-making kind of grassroots level. Cafe or, you know, just different scenarios.
Tim: [00:27:34] The funny thing is about it.
I mean, it's that, it's also kind of quasi anonymous in the sense that like, you don't actually know if there was a hum from the other side of the room, you don't exactly know who it was. which is kind of, I mean, the chairs might be able to see, but even then, I don't think you can.
Adam: [00:27:52] It's it's pretty tricky.
I mean, I've had a number of working groups and usually when there's a hum you, yeah, there's really no way to identify unless someone is going out of their way to be sort of ostentatious about it. which, which sometimes that does happen mostly for, for comic effect. but yeah, it is pretty anonymous.
Tim: [00:28:13] I it did. I mean, the first time I experienced it, I was kind of, it is a surprise. But at that she does kind of, it seems to work. To what extent does the chair, do you find it useful tool?
Adam: [00:28:26] it's very useful again, after these long conversations, just to figure out it's like, okay, so there have been a number of arguments on both sides here, but it's not like you have rounds of applause after them.
You don't really understand. Very well who's considering the arguments being put forth is as valid and compelling until you do something like that. And yeah, so it's, it's, I think one of the more useful tools. So I, one of the reasons I think this is developed also is because as I mentioned, a couple of times, the IETF is not a member organization.
And so the notion of having, like, if there were a formal vote, It would be a very confusing kind of situation because you could end up with companies easily packing the room. Right? Large companies with large budgets could easily send like a hundred folks to a meeting with a new and decision would be made and, you know, a hundred people raising their hand against, other, other people in the room would be overwhelming,
Tim: [00:29:28] but we've been talking about consensus and it is.
It's essentially a consensus driven organization. That's the kind of the way that the IETF is supposedly operates, that it does nothing without a rough consensus. Right. And does that work like, do you, as a chair, you have to gauge whether there's a rough consensus when I play.
Adam: [00:29:58] Yeah. I mean, Does does the humming work, you mean?
Tim: [00:30:03] Well, in general, I mean, you, you know, you as the chair or I have to say, yeah, we've achieved a consensus, and write it down and then it goes like, maybe talk a little about the process of like, once you think you've reached consensus, how do you verify that and how do you, how does that move forward?
Adam: [00:30:23] Right. So, I mean, once, once you determined that sort of thing in a face to face meeting, but face to face meetings, to back up just a little bit. The goal is to sort of have a high band with exchange to make certain that, you know, when there are issues that need sort of a more rapid back and forth, and you can reason to have on a mailing list, that's an opportunity to have those things happen, but the fundamental decisions for any of these are most nominally done on mailing lists.
So after you have those sorts of discussions, And, and even when you determined in the room that there appears to be consensus for a specific position, the chairs take those back to the main list and say, we had a meeting here where the results of the conversation, this is the one that seems to be the most popular or the one that people deemed to have the most technical merit.
And we need to verify this on the list then you'll ask is like, so do you agree with or disagree with this? And you'll have input from mailing lists, participant. Frequently, the people who show up in the room are most of the folks on the mailing list or at the very least that representative of the positions that show up on a mailing list and it tends to sort of work out.
Yes, that is the way that we should move forward. there sometimes you end up with technologies where people who are using them with a specific position tends not to be. Able to show up in the meetings. there was, I think one of the biggest things that we did recently was PERC, the privacy enhanced, conferencing work, where you have a group of folks who would show up to the meetings with specific positions and sort of you, you talked through the, the options, come to a conclusion and then we've go to the mailing list.
And there were a group of also very engaged folks. Who just for various reasons weren't able to attend in person and they would have very strong dissenting opinions and that, so that's rare, but that's the kind of thing dynamic where this sort of stuff tends to kind of fall down. I think one of the, one of the reasons that we're probably not going to see deployment of that work is the fact that we have sort of that split, but that's pretty good uncommon.
Usually the people who show up in person are kind of the. At least representative of the folks that are spending the mailing list. And so when you have these conversations come to a conclusion, you end up with that being a fairly quick conversation on the mailing list to verify it. Do you remember,
Vim: [00:32:59] backlash from people that don't agree or like don't meet the consensus?
Adam: [00:33:04] I'm sorry.
Vim: [00:33:06] Do you ever get backlash from people that don't agree with the
Adam: [00:33:08] consensus? sometimes it's not, it's not that common. I mean, In this sort of in this sort of give and take, you do always end up with folks who feel like they've not been heard or that their, their requirements aren't being met in a way that they believe is unfair.
And I think fundamentally that's unavoidable when you have this many people debating and in, you know, it's such a broad spectrum of technologies. but it's not a particularly common situation.
Tim: [00:33:42] Yeah. Do you get the sense that like the fact that the internet is becoming more and more pervasive is, is raising the stakes for those meetings.
. And does that make like these meetings more tense?
Adam: [00:33:58] I mean it does for certain technologies, right? The I'll cast back to the DOH conversation we were having, which is once, once the ramifications of these technologies become apparent, you do end up with folks, especially people who have like staked their livelihood on specific behaviors. I know that some of the people who are most opposed to DOH, which does encryption of the DNS query, so that the local network can't see them.
Have built technologies and like entire companies around the prospect of being able to do analytics and interception and censorship based on the clear text DNS queries. And so the mere existence of that kind of technology can sort of threaten their company. You can threaten their livelihood and they, they get, you know, obviously very.
Excited about the prospect of these technologies being deployed. so yeah, the, the fact that you do have the internet is just sort of a huge part of society and our economies and, you know, companies, rising and falling on it definitely raises the stakes and makes people, you know, very invested in the outcomes of these.
Tim: [00:35:18] Hmm.
Vim: [00:35:18] I think that's one of my fears is the, I guess general is that we seek out the answers we want to hear. And so with communities in particular, how we avoid feeding our own selves with the kind of validation or consensus, or go ahead that we need, because we're so vested or because we've anticipated it going that way.
Adam: [00:35:45] Yeah. I mean, it's, that's one of the conundrums I'm not certain is necessarily solvable. You end up just with people who have fundamentally irreconcilable positions and, being able to like move forward in the face of that is extraordinarily difficult. I mean, the, the thing that I referred to where you end up with like encrypted communications versus clear tech communications and, and sort of the, the tension between sort of user privacy.
And, and resistance to being able to be attacked by malicious parties on the internet, because you get both of those out of, sort of the, the encryption and authentication side of things, versus the ability to, operate networks, to have visibility into what the protocols are doing and to have control over what's going on in your own network.
There's, there's sort of an irreconcilable tension between those two positions. And, that's, that's something that's caused a lot of heartburn in a lot of different areas. That's, you know, when I was on the ISG, some significant portion of the conversations that we had, and they would sometimes get heated we're on the topic of, of balancing those competing concerns.
Tim: [00:37:02] but the output of this is, is. Still only a recommendation. It's not got any kind of, legal force
Adam: [00:37:12] w with very rare exception. That's right. I mean, there are, there are some situations we end up with IETF documents being incorporated into various national laws or regulations. but by and large, yeah, it's, it's frequently said the IETF doesn't have a police branch.
It's, you know, you implement the protocol or you don't. And, and as often as not, you'll end up with, you know, large companies implementing the protocol to the extent that they find it useful, ignoring things that are even like mandatory parts of the protocol and sort of saying, yeah, you know, that's what we're doing, work with it, or don't.
Tim: [00:37:53] Do I think that's interesting to kind of maybe dig a little deeper into what the relationship is between, you know, the people who are actually making money out of this space to the large companies and the, is it actually not-for-profit, the, the, the IETF. So, which is like, has no membership has no money, well, minimal money, but somehow is kind of playing a balancing act in the middle.
You talk a little around that. That sort of, odd space?
Adam: [00:38:25] yeah, I mean, so the, the fact that the IETF is a nonprofit, it's kind of an interesting sort of situation. And when you, what's interesting, again, mentioning the high cost of going to face-to-face meetings, the price that people pay and it's, it's, you know, creeping towards a thousand dollars nowadays.
Doesn't even really fully cost cover the costs associated with hosting a meeting. the ITF has like sponsors who cover other portions of it and some significant part of it along with the overhead of, you know, publishing RFCs and, and doing other activities all comes from, Well, it comes from the internet society, which is largely funded by the proceeds of registering domain names under, which is like, if we were to think about it as like the, the ITF sort of generated this revenue stream almost by accident by defining a domain name system.
and then just some small, tiny corner of that is, is what's funding. The ongoing work there. But the, the fact that it doesn't have like commercial interests in the output and it's not controlled by a board, that is like composed of companies that are invested in the out put, I think allows it to make more, Mission driven and user focused decisions.
Then you see coming out of other standards bodies. so one of the it's early on when I was doing standards work, one of the other groups that I worked with was three GPP, which as compared to say, the IETF is a complete night and date sort of thing. it, it, it almost had the feel of working with like a model United nations where the, the formal meetings you went to.
You had representatives from companies frequently who were like associated with sort of the board of the entire organization, standing up and saying, you know, so-and-so telecom will not agree with this proposal, unless you add a proxy that all the messaging must go through or something like that.
and then that held a lot of weight and there wasn't any technical conversations to be had about that. They, they wouldn't animate many times the folks who were saying those things, couldn't explain why that was a hard requirement. It's just, that's what they were told and that's what's going to happen.
and it, it held an incredible amount of weight because like, this was one of the. This was one of the companies that basically had formed three GPP effectively. and, and so you end up with just, outsized influence from, you know, commercial interests that frequently were not aligned with the interests of your average internet or in that particular case telecom user.
the fact that the IETF is like completely on the other side of that, where it's this, you know, literal nonprofit that's run, with sort of a mission of making the internet available for users is, I think probably good from a societal perspective because it, it turns that it takes that influence out of the picture where the things that are standardized are far more focused.
On getting the technology right. And making certain that it works well for the users as opposed to works well for maximizing profit and business models. I mean, there's obviously a little bit a bit of that that shows up because you have people from companies, showing up and representing those positions, but it's not, it's not the overwhelming basis on which decisions are made.
And I think that's a huge difference. And I think that's probably one of the things that has made the internet as successful as it is.
Tim: [00:42:07] So that's interesting. So you kind of think that the nature of the IETF has specifically shaped the nature of the internet rather than the other way round.
Adam: [00:42:19] I, yes, I strongly believe that.
So, I mean, if you look, if you look back on like early data protocol developments, there were sort of competing, proposals from you had the IETF coming up with TCP and IP. And then on the ICU T side, they had a proposal for X dot 25. And in very much the way that I was describing for 3g PP, a lot of that was optimized for making certain that.
the carriers who were involved could, maximize profit and, you know, it was, there was a lot that was oriented, more towards billing than things like, you know, reliability, assessability, et cetera. And I am convinced that that distinction is what made the TCP IP, what we're using right now to have this phone call, as opposed to using some sort of X dot 25 network where we'd be paying, you know, the equivalent of 25 cents a minute to talk.
Tim: [00:43:15] Right. So, so standards bodies matter for our societal purposes is kind of the big picture from that.
Adam: [00:43:22] Absolutely. Yeah. And it's not just the standards bodies, it's, it's the makeup of those standards bodies. It's what the dominant forces that shape the output of them. I think makes a huge difference. I think, without something as, you know, Scrappy, I guess, as the IETF started out without something, ad hoc and, and again, user-focused, we would live in a very, very different world, but we would have, would be more like, you know, the.
The cable television systems of the eighties and nineties, where, you know, there were a small number of people able to sort of participate and everyone, while else ends up being passive consumers of that content. it would be a very, very tough
Tim: [00:44:09] Oh
Vim: [00:44:09] no. I was actually going to say, I love that because I think the. What the sense I'm getting, and this is me speaking this complete newb, not knowing anything about this. So you'll have to forgive my ignorance, but it is refreshing to hear that the focus is on, from what it sounds like, how many people would be able to use this, like, who is this?
Who, how could we make sure this is going to be used and open and. Easy for more people than it needs to be like. It, it just it's really, it's really great to hear, especially. Yeah. As someone who doesn't know anything about it.
Adam: [00:44:52] And I can't claim that, you know, everyone who shows up the IETF shares that vision.
Obviously you have commercial interests showing up the claim I'm making. Is that the way that the ITF is set up leaves the door open for the people who want to show up an advocate just for the users, not for any commercial reasons, but for, you know, what they think are their vision, their mission for what the
internet should be, can make those arguments, whereas in, you know, closed member organizations that are, that are owned by or otherwise beholden to, large companies. That's, and there's no one who can afford to do that. There's not, there's not processes that allow them to do that. Yeah,
Vim: [00:45:37] exactly. And so what does the future look like for you?
What do you think is going to happen? How do you think the internetis gonna continue in this vein. Oh
Adam: [00:45:47] man. So I've never considered myself much of a, you know, a good predictor of the future with these sorts of things. so I mean, they frequently say the best weather forecast. If you don't have any of the information to say tomorrow is going to be a lot like today and that's kind of that's that's, you know, the way things kind of feel right now, it's it's you end up with, People continuing to bring interesting problems to the IETF and people getting together and working on them.
now that's probably wrong because eventually, you know, November gets later and later and it gets colder and colder and things do change. I just don't, I don't have a good beat on exactly how things are likely to change in that, in that arena. Hmm.
Vim: [00:46:31] Is there anything you would like to see change?
Adam: [00:46:36] so yes.
Kind of tricky about getting involved in the ITF, even though, as I mentioned, it's nominally available to anyone who wants to show up is that it's, it's kind of a rough and tumble environment. I mean, casting back to when I very first showed up, it was, you know, it was 1999 and I was just a few years out of college, you know, sort of a young kid I've been working on the, mailing list for SIP for a while.
And I had come up with my own idea about, you know, here's something that I think is going to. To make things easier to build on top of SIP in the future. And so I, I bundled that up. I printed out a stack of transparencies and showed up in Oslo without, without a laptop. and they had overhead projectors at that time.
I mean, just to sort of set the stage for, for what the state of technology was. I get up there, I run through my transparencies and, then a gentleman comes up to the microphone and it's, it's someone, you know, relatively well-known it's like. Yeah, he's sort of famous in the geek community and he's an imposing figure.
I mean, I knew who he was and I'd like read stuff by him, but I'd never seen him in person he's he's, you know, tall speaks with the lot of gravitas gets up there and, starts asking some very difficult questions and making some very critical statements about the design decisions that I had put forth.
And it was incredibly intimidating. I mean, it was, it was just, It, it was, it would have been very easy to sort of wither and decide I'm I'm not doing this. It's just too hard. so one of the things that unfortunately is the case is that, unless you have sort of the personality to hold your ground under those sorts of circumstances, it's not necessarily easy to get into in the first place because it's a very.
It's a very blunt, and, on, on some occasions, unnecessarily rude environment to work in, and there's, there has been a lot of work over the past. I want to say four or five years to sort of improve this. there are a lot of old guard folks who find those efforts offensive and, and even claim that the, The sort of blunt and sometimes rude environment is sort of a crucible under which the standards themselves become better.
I don't think that's true. I think that you can probably have, Conversations that are far more, polite and cordial, that results in technologies that are at least as good or better than you can under sort of the slight exaggeration, but sort of the fight club rules that some of the folks who have been frustrating for a long time, believe are beneficial.
And so I it's, it's a difficult transition because it's kind of like you've got, you've got a significant portion of the IETF sort of fighting back against those efforts. And I hope it's something that can be made more welcoming to new folks, without like tearing the entire organization apart.
Because one of the things, if you look at the folks who are participating right now, is that you do have kind of it's, you don't have a lot of fresh blood showing up. Right. it's, I've been doing this for quite a while and I, I have a hard time naming. More than a handful of like active, influential participants who are significantly younger than I am.
And that doesn't, you know, that's not sustainable. It's you end up with with people retiring, and, or, you know, passing away and that, you know, eventually, unless we are more welcoming in a way that brings in new participants, that's the recipe for the IETF becoming irrelevant. And again, it's not like it's not like the ecosystem for standardization is devoid of like other people who will try to do this.
You'll have other organizations step in and do it. But as I mentioned, I think that the way the IETF does things is so much more beneficial for your average internet user than almost every other standards body out there. That that would be a pretty massive loss for the internet as a whole.
Tim: [00:50:55] Cool. Well, I want to thank you for that.
If there are, any links that you, do you think would like help people understand what we're, what we've talked about and maybe let them dig in or, or, learn more about the IETF and other standards. Then, then let me know and I'll drop them into the program notes. encourage people, as I said, to subscribe to the podcast because, you know, we, we do try and cover a lot of, lot of ground and we have been, right more than we're wrong, I think, which is nice.
and you know, hopefully. Expose people to things they didn't know. I like every, every time I learn something new and, and I have a kind of Ooh moment in these conversations and I, I kind of hope that, that the listeners do too. So anyway, thank you so much.
Adam: [00:51:44] Sure. Thanks for having me.
Vim: [00:51:45] Thank you.
Really lovely to meet you.
Adam: [00:51:48] Nice talking to you as well.