 Suzanne Wolf. It's a pleasure to have you here. We are attempting to gather the history of ICANN. I'm going to ask you two questions and then we will be up and running. The first question is the easy one. Okay. Talk about how you got involved in ICANN, what the time frames were, what your roles were, and that will give us a baseline that we can work from. From then to now? That's going to be kind of, it's going to take a few minutes. Do it. So my involvement with ICANN predates ICANN. And that always provides a unique moment when I have to introduce myself and talk about ICANN. I became involved with ICANN because I was working at the time for John Postel, University of Southern California, ISI, wonderful place. Still miss the environment there. Still have friends I made there. But when ICANN had to come about, new co, a new home for the IANA functions, there was a great deal of political and social and you know, people were talking about all kinds of things. I'm a techie. I was a system administrator and network operator in the research group, the Postel around. I worked with the networking guys out of all the groups at ISI because they were doing the cool stuff. But I was technical and I looked after name servers and did a lot of the day-to-day work that supported IANA. And at a certain point as the drama unfolded around us, I was in a conversation with him and some of the other folks that worked on IANA. And he turned to me and said, you realize that when all the yelling is over, somebody is going to have to be in the middle of things making sure that the systems actually run and people can do their work. And I thought that that sounded like an interesting task of making the operational and technical side of ICANN actually happen. So I agreed to do that. I said, okay, you know, as we're planning the offices, we're doing the mundane things that go into making sure the operation works. Time me up for that. So when ICANN started as a separate organization, they had office space that was sublet to them by USC and the building that USC is still in, you know, ISI is still in. And I was the one that did everything to make the bits flow, everything from getting the phone system installed to procuring and setting up the servers that the IANA staff needed to work on. And it was a couple of the IANA folks and me and Mike Roberts who is the CEO and in all seriousness, a couple of lawyers. And a very small number of people, very small, very shoestring resources. The board was much larger than the staff. And there was a lot, well, Mike and the board were doing all of the big picture stuff to make ICANN viable and get through those initial difficult days. There were a couple of us back at the office making sure that IANA, which is what it was all supposed to be about, was actually able to function. As you've implied, you were at ISI and as ICANN was formed and that function was moved from ISI to ICANN, you moved with it. I did, for only a couple of years it turned out, and ICANN didn't have apparel capacity at that point. In fact, I was loaned by USA. I've never been an ICANN employee. So that's an interesting detail, but let me ask, were there others who were in the same position who either moved or were loaned by ISI? Yeah, there were, wow, I would have to go look, I would have to make sure that I knew the names, but there were a couple of the IANA staff. Josh Elliott, I don't know, most clearly, I believe there was another staffer, and I am embarrassed, I've forgotten the names, but there was really a very short, it was a very small number of people, and in fact, we used to try to imagine what would happen when things were stable and we really knew what ICANN was going to be like, and, oh, not that much bigger than it was then. It was hard to see. It was hard to see it growing to be a tenth of the size it is now. Yeah, and it would be interesting to know what happened to those people just as a curiosity. And how long were you in that role and then what happened because you went off to do some other things? Well, the whole thing fell apart without me. I was there until early 2001 because I went through the Y2K, which of course was filled with great drama partly because ICANN was ICANN and partly because, you know, with all of the IANA functions and so on, but also partly because there were a great many of fears that turned out to be somewhat overblown but obviously needed attention attached to the root name servers. So there was a large ongoing project that had to do with making sure that the worldwide DNS, the root name servers, the functionality they depended on was reliable and stable through the Y2K drama. Early 2001 though, I figured I'd been doing this for a while and I went to Bay Area Networking Company and after that to ISC, which is well known as the open source company that provides a lot of network infrastructure software. So I was working on DNS again. Bind in particular. Bind many generations ago then, but I was actually at ISC for quite some years through many versions of bind, through many revolutions in how the network operates, what people expected of their software, what people expected of the structures around the software and the corporate, you know, how the industry grew and changed and so on. And I haven't been with ISC for the last couple of years, but one of the things that happened while I was at ISC was ICANN reorganized. ISC is also a root name server operator and was part of a set of events. ICANN reorganized and I believe it was 2003. You would remember better than I because I was somewhat disconnected at that point. But there was a reorganization around ICANN of how the board was structured and how governance of the corporation was structured and a great many changes around how the community was integrated with the organization. And one of the things that happened was the root server system advisory committee that I participated in was asked to send a liaison to the ICANN board of directors. And I was asked to take that on. Partly because when I was at ICANN, one of the things I did was get RSAC started. I ran the first meeting of the root server operators that became RSAC because it was considered important for ICANN to make relationships with the root server operators. It wasn't clear to anybody exactly how that should work, but it mattered to ICANN, it mattered to the community, it mattered to the US government that there be something and that was what RSAC was. Interesting. So you got RSAC started while you were at ICANN. And you went to ISC, which was a root operator, and became re-involved in some sense with ICANN. Got dragged back in. Now, if memory serves, I may be wrong, but weren't you also one of the charter members of RSAC? I was not a charter member of RSAC. I was drawn in after a particular incident involving the varicine.com wildcard. And I had been involved in ISC's response to analyzing what happened there. And quite many people were extremely angry about that incident. And one of the things that came out of it was some response by ISC as a software vendor and an operator of DNS infrastructure. And I believe that turned into some conversations because it was something RSAC was looking closely at. That turned into an invitation to participate in those conversations. I see. And from there I was invited as a member. I see. So just very quickly, of course, was a chair of RSAC from its beginning in early 2002. The event that you're referring to is extremely famous and is a pivotal point in our lives and everybody else's. September 15, 2003, just to be specific. I wouldn't even have been able to tell you in 2003. A moment that will live in my memory for quite some time. We had a pretty interesting day at ISC that day, too. It was an interesting. It was a Sunday afternoon and it was... We don't have time to even begin to... We'll go to some other day. But as you mentioned, there was a reorganization. There's another term of art that was being used. But anyway, the bylaws were changed. The advisory committees, RSAC for one, RSAC for another and so forth, positions were created on the board for liaisons from those organizations. You became the liaison from RSAC. Right. There was a lack of interest within RSAC, which I decided I should go fill for, not so much for ambition, but because it would help position RSAC more visibly inside the board. And so I double-hatted myself as both chair and liaison. So we joined the board in parallel positions at the same time. Somewhere along the way in 2003, summertime or fall or whatever that was. You were there ahead of me, but not by very long. Well, so we've had a long march together. It's been pretty interesting. So that's the sort of rough history. That's question one. It's the outline. Question two, and there's many pieces to this. Okay. What's most interesting is to get at the underlying story, the why and the how of things happen, not just the what, when, and where to pick out. And then if you have trouble picking out, I'll help you out. Particular sequences or stories that put the pieces together and relate events over a period of time that help explain and inform where we are today so that if you imagine somebody sitting in your seat today on the board or working for an ICANN, trying to figure out why is it that these things are the way they are, either relationships or structures or whatever, that there's a story to tell that says, well, it came about in the following way. I'll ask you for a prompt and then I'll decide if I'll use it or I'll use the first thing that came to mind. Well, you triggered one when you said something about the root servers and then needed to be organized, which reminded me that there was a singular event that took place a few years earlier, which you were probably part of, that led to the creation of ICANN, which was a small reorganization of the addresses for some of the root servers for which Ira Magaziner said he woke up the president. I've heard that side of the story. I can't vouch for it. No, Knork and I. There are great many people involved in these policy and political arguments over this, but what was really going on was there was an operational function of deciding updates to the root zone of the DNS, what names were valid for domain names in the DNS that had been treated up until then as a strictly operational matter, which Postel and consultation with other stakeholders, we didn't call them that then, but we had made these decisions in a very informal way because the other people involved in operational responsibility for those matters trusted IANA. He worked closely with the IETF, which is the standards body, was still his, worked closely with the root server operators and with other constituents, but it was all very informal. And as one aspect of how the political story was unfolding, people were saying, this doesn't work. This isn't going to scale. There was an occasion where, as an experiment, there was an occasion where some of the root server operators were asked to change the source they used for the root zone data. This was very alarming to the political people, the policy people because it uncovered a power structure they didn't know about and they didn't know how to deal with, which was personal relationships based on, gee, things will break if we don't play well together, so we'll play well together. But this wasn't computing. And in fairness, this had not exactly been explained to them very well. So it's no mystery to me that there was a great deal of alarm, but what came out of that was after the heart attacks were taken care of, the immediate reaction, what came out of it was an assertion by the United States government that really nobody should change the root zone of the DNS without their express permission. That was a big change. Even though at that time the root zone did not change very often. It was not dynamic. We had a few TLDs. It seemed to be working that way. The country codes were being delegated. There were a few, what's now called GTLDs. It wasn't a big operational drama to manage the root zone, but it was kind of important. And this hadn't been clearly housed in... She's a lot of visibility yet. Well, but it also hadn't been carefully housed in any kind of institutional arrangement. So there was this immediate felt pressure to create a structure which was don't change that unless the United States government says so. I'm going to say that's not going to work in the long term either. That's not going to scale to the enormous expansion of the Internet and the interest of people having the Internet. So we got to figure out something else. And that's largely how the policy side of ICANN came about. Now, something that is so obvious to you and me but needs to be said is that a large number of the parties involved were DCCTLD operators who then became very dependent upon the IANA function. But the other obvious comment is each one of them was started by Postel awarding them the letter, the code. So there was a direct personal relationship that was very positive in the sense that these were his progeny in a sense. They were. And those personal relationships both with the root server operators and with the TLD delegate operators. And it was actually extremely unfortunate. It was a formative event also when he passed because he didn't get the chance even though that was the plan, he didn't get the chance to do the personal work of turning his personal relationships into institutional ones. And there was a great deal of trouble and discomfort and distrust that followed from the fact that he wasn't able to be part of that process because there was a certain amount of ICANN, what's that? And you guys, who are you and why should I listen to you? Well, so let me ask a kind of provocative question here. So it's extremely unfortunate, no question that John passed away sort of on the eve of the formal start of ICANN. So that's an event heard around the world and everybody knows that that's not good. But I could imagine some alternate sequences. It could have happened that others could have stepped in and made the rounds to assure everybody that John-like people would be in charge and that the relationships would continue and attend to the relationships and the trust. That is a little bit provocative because from what I saw, there was a certain amount of effort to do that. Some of it was actually effective. We did end up, for example, with an agreement between ICANN and the IETF and a different set of agreements between ICANN and the regional internet registries that said, yeah, we'll continue to work with you. Which frankly, as far as I'm concerned, is a success of the work that was done of the kind you're describing because there was a while where it was not at all clear. Who were the prime movers on the ICANN side of things for that? I actually had limited visibility on that. There were a few of the senior engineering folks that had been involved with the Pustel principle through the IETF and IANA and RFC editor and so on. Fred Baker, John Clemson, I'm trying to remember who were the other contacts there. But there were several of those. I never focused on it and I wasn't around at that particular time. But the event was, I believe, instrumental in a great deal of this. But some of it was tried with some success, frankly. The whole thing didn't fly apart. And to me, that's a success. There was some of it that was tried, but the situation had arisen that there was a deliberate effort to select people to be closely involved with ICANN who did not come from the community, who were not familiar with John and his personal relationships, his institutional relationships, how the internet worked. So some people tried very earnestly to do what you described and it didn't always go very well. And there was also, for political and policy reasons, I'm not the person to speak to authoritatively, a great deal of discomfort and distrust had been generated by the process of trying to decide among all these constituents how ICANN would be set up and who would run it. The white paper process, the green paper process. And so there was, by the time we had that work to do, there were not a lot of resources available to help them. So I was carefully not participating and don't have all that, but that's certainly an area that has to be delved into very deeply as setting the context pro-WanCon for how ICANN got kicked off and what baggage came with it. Well, and for me, I look at this thing. I was distant from those processes. And my role then and frankly now has to do with saying, okay, it's important to support the policy processes and these institutional processes and so on, but what really matters is to keep things connected enough that the internet works. And it certainly would have been easy to become very confused about the relationship between some of the policy and institutional activities at that time and anything to do with keeping the internet functioning. And what about the CCTLD operators? To what extent? I mean, I'm flashing back to what little I know about the contentious process of the green paper and the white paper and all the different groups involved, but I don't have the impression that there were a lot of CCTLD operators directly involved in that process. I may be wrong. No, from what I saw of it, there weren't very many. That were involved on the policy side. For most of them, at that time, the CCTLD operators were the people that Postel had picked in many, many countries at a time when the internet was a new thing, was not to the attention of governments, certainly was not part of their sovereign heritage, that there was a TLD as part of it. This was not critical infrastructure yet. So what you had was many of the TLD operators were either technologists who happened to have access to network resources because that was what was important in Postel's criteria, or were just emerging past that. We're beginning to say this is critical infrastructure, this is commercially important, let's run it in a more institutional way. But it was very early in that process for most of the CCTLDs. I'll just note that we have two that I can think of quickly of the original CCTLD operators, closely associated with ICANN, Lito Ibera, El Salvador, and Adiel Acropogon, an African, I'm going to get it wrong, which country, Toko, I think, or... I think so. So there's deep history to still part of what we do today. It's just kind of amazing. Many of the people that were involved in building these instadies and these infrastructures then have gone on to other things. Many have become uncomfortable with how things have evolved, but many have stayed involved, and stayed committed to making the internet work better. Now that we're talking about the next billion, when then we were talking about the next million, or the next 10 million, I think we're actually very fortunate that there are so many people with the deep history. A lot of them are skeptical of ICANN, frankly. Not all of them are very comfortable with something like this meeting. But we actually have a lot of them still to draw on, and I think that's tremendous. Any more provocative questions? So that was a provocative question. I don't know whether we've plumbed the full depth of it, but we've got some interesting things out. What came to mind first, was it that, or was something else when you asked me? Well, that's an easy one from the beginning sort of days, but in many ways with the IANA transition process of the last couple of years, it's been feeling like we've come full circle. And there were a great many, I would say, community tensions around some of the history, some of the early history, frankly, that has resurfaced in the context of having to work out a shared proposal for the IANA stewardship transition. And for the most part, this is exactly how it was always supposed to be. Maybe it's taken longer than people initially thought it would. But the idea would be that the community would figure out its challenges and figure out a way to work together and would be able to move beyond the U.S. government contract and the U.S. government stewardship oversight. And in order to do that, I think people had to face some of the things that have been lingering, if you will, since that early history. And that's been fascinating to watch. So let's not leave that hanging. Say specifically, what are some of those things that were lingering? This is challenging to articulate because I've been living it so much for the last couple of years. I understand. And I know you have too. And once I get started, maybe you can help me articulate a little bit. There's always been a tension, and for some people it goes back to the way the Internet works, to some people it goes back to the policy and political history. But regardless of where it came from, there's always been a certain tension about the idea that all of these constituencies work together and that the stakeholders, if you will, are part of an interdependent system and the notion that someone's in charge. And as one formulation of the principle, the Internet is founded technologically and to a great extent institutionally on the assumption that local decisions are made locally, that what the Internet is for is inter-operation and coordination. It's not an end in itself and it's not a structure for control by itself. And that creates some real challenges around who's in charge of what and who makes decisions and how do decisions get made, particularly in situations where decisions must be made. And I think at one level, the entire history of ICANN, particularly these last couple of years, have been about figuring out how much do we need somebody to make decisions and how much do we need to make sure we don't have anybody in charge. So there's been certainly with the community proposal a great deal of the discussion about it that led to the proposal was based on working out under what circumstances, how are decisions made? Not even who makes decisions so much as how are they made. Who are the stakeholders who have to be in the room? What are the structures whereby these contentions have to be worked out? And it's been really interesting to watch. But I have to say I'm happier than I expected to be with the outcome of that entire process, as painful as it was, because I think some of those lingering discomforts about really at one level what is ICANN in charge of and what are some of the other stakeholders actually in charge of. I think we actually worked out some of them in a way that I think will be good to go forward with. Today, in addition to all the things we've talked about, you're also heavily involved with the ITF and IAB, which means you're engaged in specific technical issues that relate directly back to issues that affect ICANN, but from a technical development point of view. Say a word about that and where that's all leading and what the unsolved problems are that have required the action that's now underway. Well, what I do, I'm currently a member of the Internet Architecture Board, where part of what we do is some administrative management of the ITF's relationships with other groups. But what we're really supposed to be doing is taking the big picture view of how the Internet architecture is evolving not just in the ITF, but in other standards bodies and other ways of doing technology in the industry and so on and so forth. I also co-chair the DNS Operations Working Group of the ITF, which is where people, where DNS operators and people involved with operating DNS infrastructure bring changes they think need to be made, and most of what DNS operations does is actually best practices and documenting some of the things people are doing at the technology. Some of them are not what was originally envisioned and how it would work, and that by itself is a challenge. Sure. Evolving how stuff works. What are the current documents or designs that are active in the DNS Operations Working Group? Oh, my. It sounds like you're looking for something in particular. Can I ask you for... Well, I'm just trying to drive down the path that I described before, which is based on whatever you say, to what extent, how did that relate to what came before and why are those still open problems and how does it relate to what's happening at ICANN, and I don't have the answers in my head, so I'm... There's probably a couple... Okay, so there's a couple of things that we can talk about. For one thing, the way DNS is designed, there's this dependency on root name servers. It's a bootstrapping mechanism. It's an optimization. From a protocol perspective, it's not a very... With due respect to our good friend, Dr. Marco Petrus, that's not necessarily the best way to bootstrap any technical system, is to have preconfigured contact points with how you... It seemed like a good idea at the time. It did, and it was, but having the system work really, really well isn't necessarily a reason not to evolve past that. So we have some ongoing efforts to come up with best practices and ways of replicating the root data in a way that depends less on a specific set of servers. Interesting. And this is all purely technical practice, and it's not about the data in the root zone. It's about replicating, not changing, but on a wider basis than necessarily from the root name servers. There are many efforts to refine how DNSSEC works in practice, because the ability to authenticate DNS data because of all the things you can carry in DNS, the ability to authenticate a DNS answer is really important. It allows you to do all kinds of other things in a more trustworthy way, but it's also very difficult to do operationally. So we're still refining. Many years after the base specification was done and people have been trying to deploy. And as you know, I spent a good fraction of my life so I'm very empathetic. And part of what has to be done there is operators have to do... And this is a very internet thing, this is right, because there's all the interlocking pieces. ICANN has to help people come up with good ways of doing it, has to sort of nudge people sometimes in some of the relationships ICANN has, but also the standards and technology people have to do what they can for operators to do the right thing day to day. So it all interlocks. I believe... I never get to see... There's always a DNSAC day at ICANN meetings and I never get to see it. I initiated those and ran those and I had to gradually back out and then finally give up. So I'm very empathetic. I never get to do techie things at ICANN meetings. I'm too busy doing policy things. The sadness is your time on the board as the RCAC liaison, I gather, is coming to an end. Most likely, yes. It's been a role I've been in for a long time and I've enjoyed it. I feel like I've done some good work there, but also one of the things that's happened is that RCAC has matured. The root server operators are stepping into more of a role in the community and I'm actually pretty pleased with them. They've gotten to the point where they're willing to come up with a process and a plan for replacing them. And I hadn't quite realized your pivotal role or your seminal role in getting RCAC started, so I can well imagine that you are indeed very, very pleased to see the material, but you said most likely as opposed to certainly. So is there a glimmer of hope that the... I don't expect to be on the board past the HM. The most likely is because part of the work of RCAC at this meeting is to take the next steps towards finalizing the process and determining how to run it. The good news is that then you can go to technical meetings and do technical meetings. I look forward to that. But I wanted to swing back to the IETF working group and just flag the point that one thing you focused on was the priming process for... or the root scope process, as you said, for root servers. And I had not focused on that, but I understand that I know a lot about the details of how it currently works and what those issues are. And so there's a long, long history that's been very stable for a long time, and now you say it's being reexamined as to how to do that. What are the main drivers that are causing people to feel the need to push on that? There's a couple of pieces. There's always the drive to make the network work better. And the tension for DNS and for the root is that it's a global resource. It has to be globally available. And anything global makes network people want to optimize it down to something local. So there's the Anycast technique, the Roots of Operators, and many, many DNS operators and operators of other network services use to make sure that many, many servers can provide the same service under the same configuration. But there's also the notion that for any network operator, if you want to make a local copy of the root that is available to your users, there should be a wallet. And there are failure modes of that. It's challenging. So there was a need for best practices on how to do that effectively. And then the DNS sec was the other thing you mentioned. And there, I don't think we'd have any trouble documenting what the needs are because we've been tracking that for years. Well, it's certainly a significant challenge to get DNS sec into a signed root zone and to get all of the policy pieces and the operational pieces and the... You just said a key word. And I see we've got a couple of minutes, but not long. The root was signed in 2010. As you and I both know, it was not a trivial, easy decision or process or anything. Say something about the events leading up to the signing of the root zone from where you were sitting. There were two pieces. One was fast and one was slow. The slow part was an effort literally over several years to persuade the stakeholders that the technology was ready to deploy, that we weren't going to make DNS actually work less well for users, that there was benefit to it, that would justify the expense because there was significant expense involved in getting the security apparatus and processes in place. But the other thing that occurred and there were lengthy discussions that were leading in that direction, and it was frankly a long process of just making a significant change to how the root zone was generated and distributed. People were worried about that, frankly, justifiably. Now, where people like to sleep through the night and not be patient to in the morning because something broke. But also, there was a discovery as people were sort of taking pretty much unbounded time to decide whether this was a good idea. There was a specific issue that arose where there was basically a bug in the way DNS was deployed pretty much worldwide where it was possible, it became trivially possible, easily possible for a teenager in the basement that knew basic, a little bit of programming to create a situation where they could lie about DNS data, that they could redirect legitimate traffic by lying about DNS data, and this became the push that convinced people that we needed to use DNS data. And to fill in the blanks there, DNSSEC was invented to provide strong assurance that the data that you received is the data that was intended to be received using cryptographic signatures. From the time that that work started a decade earlier or more in the early 90s, other mitigating measures were put into place that reduced the chance and made it harder to spoof the data. And the event that you're talking about was Kaminsky discovering that those mitigating mitigations weren't actually effective and could be bypassed trivially. But it was much easier. The thing that Dan discovered was that it was much easier because he's a very smart mathematical guy that it was much easier to intercept the query and send a lie back. And what the NSSEC did was basically assured that you would at least be able to tell if you were being lied to. And all of a sudden that caused a big shift in the understanding of, yes, this is an important problem, we better get this fixed. What it changed was the perception of the cost of getting it wrong. And the cost of doing nothing. Which so many of these things come down to that though. What's really the cost of doing nothing? I see that we have come to a moment when we need to pause. But this is, I think we've got a lot of good stuff on the table so far. More to come. Thank you Suzanne. Thank you.