The following are the outputs of the real-time captioning taken during the Eleventh Annual Meeting of the Internet Governance Forum (IGF) in Jalisco, Mexico, from 5 to 9 December 2016. Although it is largely accurate, in some cases it may be incomplete or inaccurate due to inaudible passages or transcription errors. It is posted as an aid to understanding the proceedings at the event, but should not be treated as an authoritative record.
***
>> MILTON MUELLER: Welcome, everybody. Welcome, everybody. Thank you. Take your seats, and let's start going. So, welcome to the workshop. The title of this workshop is DNS Fragmentation, Risks, and Realities. DNS, if you didn't know, means the Domain Name System and because it's one of the most critical parts of the Internet that creates global compatibility, there has always been an interest in the risk of some kind of fragmentation or some of the mechanisms and policies by which we maintain that global compatibility. There have been a number of interesting issues related to splitting the DNS root, going back to the early 2000s and even to 1995. Before ICANN, there were some risks of alternate roots. But somehow, the DNS has managed to hold itself together all these years, and there are a number of possible risks and technical realities that people need to be aware of regarding the future evolution of DNS in the post‑transitional environment, and this panel has assembled a very international group of people, who bridge the technical and policy aspects of DNS, to discuss this problem.
We're going to break our discussion into three different parts. The first is, kind of, about the geopolitics of DNS fragmentation. The second is about the YETI project, which is, a sort of, quasi‑alternate root, but run for experimental purpose, for the purposes of technical reach.
And in connection with that, we're going to have a discussion of innovation, in naming. And finally, we will have a discussion about special naming and the relationship between the Internet Engineering Task Force, and ICANN in terms of controlling the naming system on the Internet.
So, I'm going to begin by introducing our speakers and panelists, and each of them has the option to, first of all, supplement their introduction because I'm just going to give a name and a title.
And secondary, give us a very short, two‑minute, at most, introductory comment in terms of your perspective on what this panel is about. Is that okay?
So, let's begin. We have two remote participants here. One of them is Oleg ‑‑ three remote participants now. We're joining and adding on as we go.
The first one is Oleg Demidov from the PIR Center in Russia. Oleg, are you with us? Can you say hello?
>> OLEG DEMIDOV: Hello. How you can say more than that? Hello. Yeah. Can you hear me now?
>> MILTON MUELLER: Yes. We can hear you very well.
>> OLEG DEMIDOV: Okay. Good. Good day, everyone. Thank you for the opportunity to join the discussion. So, I have now my two minutes for summarizing my views on the topic, right?
>> MILTON MUELLER: Yes.
>> OLEG DEMIDOV: Okay. So, since we have to divide this in three parts, I would mostly focus my own contribution on the first part. It's about national policies and governmental approaches to development of the DNS and its national segments, and is there any connection between those policies and the possible danger or the possible risk of fragmentation.
So, since I represent the Russian academia and part of the Internet community, I would mostly focus on summarizing the developments in Russia, in that field, because they provide a, kind of, illustration of the situation we might have, not only in Russia, but in a number of countries where governments are concerned with the possible risks to stability of the national segment of the Domain Name System.
So, what we have in recent years, is the growing attention of the government of what's the stability of the Russian segment of the Internet, including the Russian segment of the global DNS system. It started in 2014, where the first cybertraining conducted, and then was to test the resilience and stability of the Russian segment of the Internet.
It included different scenarios, and one of the scenarios, was notification or deletion of data on Russian CCTLE DRU and 1.rf from the roots on file, so as a consequence, the threat to Russian segments of the Internet was the vulnerability of the Global DNS services to Russian users, to Russian operators. What the conclusions made from this cybertraining?
>> MILTON MUELLER: Oleg. Oleg. Can you hold on for a second?
>> OLEG DEMIDOV: Yeah. Sure.
>> MILTON MUELLER: I think you're getting too deeply into what we want to do in the first section. I think you made your introduction and I'll go on to the next speakers now. Okay?
>> OLEG DEMIDOV: Yes.
>> MILTON MUELLER: Thank you. So, the next speaker, panelist, or another remote participant is the renowned Paul Vixie of Farsight Security, someone who has been key contributor to the development of the DNS. Paul, are you with us?
>> PAUL VIXIE: Yes, I am.
>> MILTON MUELLER: Okay. Would you like to give us a really quick overview of your perspective on this and where you fit into the discussion?
>> PAUL VIXIE: Yes, sir. So, it's always been interesting for various parts of the community to decide which part of the Internet has to be centralized, and which part does not have to be centralized. I, myself, have done research into this.
We've seen a number of attempts, usually commercial in nature, to create an alternative naming system that is based on the IANA system but has various added features. They've all failed. And I think that's good, because if any of them succeed, they're going to encourage an awful lot of competitors. We're going to end up with ‑‑ and fragmentation. In other words, has a tipping point of the first success.
So, I am happy that there seems to be no danger of that. That's my perspective on the overall topic. I'll speak about YETI during Q2.
>> MILTON MUELLER: Great. Thank you, Paul. Next, I'd like to introduce. Zheng Song of the Internet Group or BII group.
>> ZHENG SONG: You can call me Davey, and, okay. Yeah. I am on behalf of BI as a coordinator of YETI group, or YETI‑DNS project, and for the past more than one years, we have a lot of communications in technical community, so it's our first time to join, not only technical guys here, to discuss. And want to hear more about the policy concerns, and I think communication is very good to get things done or to have awareness of the situation here. So, that's why I'm here. All right. Thank you.
>> MILTON MUELLER: Thank you, Zheng. Next is Brenden Kuerbis, with the Internet Project at Georgia Tech Institute of Technology in Atlanta.
>> BRENDEN KUERBIS: I think that while the policies are of a concern, I think they're understated. I think it's important on getting stability of the DNS, while at the same time, continuing to foster innovation at the Internet's core infrastructure, and that innovation may include creation of complementary or competing naming systems.
>> MILTON MUELLER: Great. Next, we have Andrew Sullivan, who is the chair of the Internet Architecture Board, and with Dine.
>> ANDREW SULLIVAN: Thank you. I'm Andrew, and I guess, I will be arguing today ‑‑ I should say, the Internet Architecture Board is a bunch of geeks that all get together and talk about the overall architecture of how the Internet works together.
The IIB put out a statement a number of years ‑‑ I always forget the number, I have to look it up ‑‑ about the unique DNS root, 2826, there it is. RFC2826 is the IAB statement on the unique DNS root. It's a technical comment. And there is a critical point in there that sometimes gets lost in some of these discussions, so I just want to make that right now. And that is that, in the DNS, or in any hierarchical name system of the sort that the DNS represents, the unique root is not a political fact. It's a fact of mathematics. This is not something we can negotiate about. If, what you want to do is get rid of the unique root of a hierarchical naming system, what you have to do is throw away the hierarchical naming system. That's how they work.
So, this is a thing that, I think, often gets lost in some of these policy discussions, we could get rid of it. I agree that we could replace it or complement the DNS with alternate things, and I have some ideas about that, but that's part for a later discussion.
>> MILTON MUELLER: Excellent. Thank you, Andrew. And now we have Kaveh Pangbar and a member of the ICANN Board, and is responsible, in effect, one of the 18 members responsible for overseeing the DNS root.
>> KAVEH PANJBAR: Thank you, Milton. Hello. Yes, I'm a CIO in charge of representing K‑root, one of the 13 members. I think, yes, there is a risk of fragmentation, but I don't think it's any more important than any other fragmentation risk in any other layer. I think Internet, by design, is fragmented. IRP is fragmented. Higher than DNS, we are already fragmented. I don't think it's a risk that needs special attention, that would be my point.
My additional point, which you will argue at the last question, I guess, is I think the main thing we all adhere to, what IETF says, and the main risk is actually fragmentation at IETF. If there is another organization that can gain enough critical mass to be able to, basically, set the standards and then they come up with ideas about naming or addressing or any of these core Internet technology, that would be a real risk. But not DNS fragmentation, doesn't need any special attention.
>> MILTON MUELLER: Next, we have Farzaneh Badiei. She is working for the Internet governance project also in Atlanta, and she has a policy perspective.
>> FARZANEH BADIEI: Thank you, Milton. So, I'm just going to briefly talk about a court case that happened in the U.S. about .ir, a country‑level type domain name. And, I'm going to speak about how, how the court addressed DNS fragmentation in its argument and discussion. I don't really have a position on DNS fragmentation. I allow you guys to do it.
>> MILTON MUELLER: Last but not least, we have Ryan of Blockstack, who, I think, is representing some kind of alternate technology that might be relevant to this debate. Ryan, are you with us?
>> RYAN SHEA: Yes. I'm here with Muneeb. We are both working at Blockstack, both co‑developers of a company that is pushing this technology forward. And we have a decentralized domain name system with a built in equivalent of DNS F, and it runs on top of the big client blockchain, but can run on top of any blockchain. And it's similar, if anyone is familiar with NEON, there is some similarities there, but it's essentially a nonhierarchical naming system. In a sense, the root is the blockchain itself. Thank you all for having us here.
>> MILTON MUELLER: Great. Okay. So now let's get into the specifics. As I said, we're going to begin with the geopolitical aspect, so let's just pose the question. What is the possibility of a major split in DNS caused by geopolitical differences? Could the DNS actually be split as a result of these differences, and what is the probability of such a scenario?
In this segment, the lead is going to be taken by Farzaneh and by Oleg, so why don't I start with Oleg, and he can continue the speech that he was giving during the introduction and tell us more about what's happening in Russia.
>> OLEG DEMIDOV: Thank you so much, Milton. Sorry for jumping into the substance without the proper introduction. I'll just continue, as you suggested.
Just several points on that issue. First, the probability of a major split in the existing global DNS seems to be extremely low, even as a result of some purposeful actions taken by any governments.
Actually, there was some studies and discussions on the probability of a DNS split as a result of governmental actions or some geopolitical decisions, while the major scenario seems to be more or less relevant, is that in some very, very unprobable cases, the technical organizations maintaining the global root are forced, somehow, to alter, to modify data on some of the top‑level domains, and disseminate that data from its file to the operators of the DNS root servers.
For example, well, one of the theoretical hypothetical scenarios might be releasing the information on CCTLDs of some nation state from the updated root zone and file and get it disseminated from the servers of their design.
So, even in that situation, as was stated in the study, including the one made by Dr. Klanwater. The operators of the root servers have their own choices for the actions for what they could do with the updated root zone file. And option one is they could just ignore it and use the previous version containing information on all CCTLDs, and just continue doing it like that, continue using the old version of the root zone file, do not accept the changes.
However, if some of the operators of the root servers are also forced to update their data to accept that dated version of the root zone file, and others are not, then it could trigger some technical split within the existing global DNS.
However, the consequences would not be limited to the necessities of the nation state that are supposed to be delated from that root zone file. Instead, the consequences would involve, would affect all the existing global domain names, so this is an interesting solution, and this is the major reason it is highly unprobable because the decision‑makers in each country, in each jurisdiction, understand how possible negative effects of this action, of this scenario.
And actually, going back, if I have a minute or so more. Going back to the Russian experience on that build, the cybertraining conducted in Russia in 2014, actually, included the scenario, some fail our or modification related to Russian CCTLDs in the global root zone file, but all that were tested or exercised during the training were included in the training scenario based on two criteria.
The first criteria was probably, the YETI of any particular threat scenario. The second criteria was the threat, the potential threat, the potential damage that could be inflicted by ‑‑ in case of that scenario that takes place and happens.
So, among all the threat vectors, all threat models, the threat model of major bleed or major failure in the global DNS system had the lowest probability. It was extremely low.
However, even with that extremely low probability, this had very high, very critical potential consequence. That's why it was still included in the training scenario.
That doesn't mean that it is or that it was regarded as one of the prime most probable and most realistic threats, just on the contrary. And actually, the later actions taken by Russian government, by Russian bodies, show that they are realistic in the assessment of the possibility of this threat.
Because what was done in the two years after that, after the training, is a set of policies, a set of actions and decisions, that were made and taken. And their purpose is not to ensure or to create some, I don't know, alternative root or alternative DNS infrastructure for Russian, none of that.
Instead, the purpose is very practical and it is not directly related to the risk of fragmentation. It is just to provide so backup to duplicate the information related to all the domains, all the names, in the Russian Domain Name Systems, just to have them, copy, replicate it on some local server, and to be able to use them, to use that information in case some major failure or some major crisis, disruption, would happen with the global DNS. Just to create an opportunity for the Russian user temporarily during this crisis to be able to still reach Russian Domain Name System resources, so that's all.
That's why my assessment is that Russia's government of action, Russian policy, and Russian assessment of the situation does not make the fragmentation of the Global DNS a reality or work on that, so I do not see it as a major threat.
>> MILTON MUELLER: Thank. Thank you. Very good. So, before we turn to Farzaneh, you have a question?
>> I have a quick comment because the first answer mentioned by Oleg, is actually that root operators do not publish a change. It's actually not possible, technically, because roots aren't assigned and there are multiple TTOs and key validities that focus on the validity that hold the records or sign. It's 10 days right now, root zone, and the other one is case, which is 15 days. So, worst case scenario, depends what is being changed. After 15 days, that policy is useless. In reality, it's more like one or two days. That's not a real scenario that you can publish an alternate root zone, which some operators publish different zone than others.
>> MILTON MUELLER: Good. Very useful observation. I think what Oleg was saying is that if the U.S. government, under the old scenario, when they controlled the content of the root zone, suddenly ordered ICANN, let's say, to take Russia out. He was implying the root zone operators had the autonomy to refuse to follow the new root zone. You're understanding with DNS Sec, they can't do that. Interesting. All right.
So, next, let's turn to Farzaneh, and she'll be talking about another aspect of the geopolitical risk, and that is the, sort of, legal issues related to U.S. jurisdiction.
>> FARZANEH BADIEI: Thanks. So, I'm just going to give a brief overview of our case, which is the country top‑level domain for Islamic republic of Iran, and the fact of the case, just bear with me in the beginning, because I will lead you to how this is related to the DNS fragmentation.
So, the case was about a group of terrorists, terrorism victims, had a monetary judgment against the state of Iran. Iran does not have recognizable assets and properly in the United States. They wanted to create ways to see where they can find Iranian asset, so they argued that .ir is, in fact, a property, and it should be attached to them because this monetary judgment against the Islamic Republic of Iran.
>> MILTON MUELLER: Attaches is a legal term that some people may not understand. Basically means, seize or grab.
>> FARZANEH BADIEI: Yes. So, they should own it. So, and for that, they actually received a writ of attachment from a court in the U.S., and then they went to ICANN and asked ICANN to enforce this writ of attachment. ICANN said, no, and filed a motion to quash that writ of attachment.
And it argued several things, and one of them was that, ccTLD is not property. I'm not going to get into that discussion. We have written a paper about it with Professor Mueller.
So, in the end, that Court said that, in fact, ccTLD might be property, but they cannot be attached. And so, the Court ‑‑ the Court actually upheld the motion of the of the terrorist victims.
Then the plaintiff, of course, appealed the decision. And this time, this is where we can see, in this decision, how DNS fragmentation can play a role.
So, the Court of Appeals, departed from the legal precedence previously that always focused on the matter of whether ccTLDs or top‑level domain are property or not. And this time, actually, made an argument that was more ‑‑ had a geopolitical Internet governance rational behind it.
And using the U.S. government amicus brief as well, the courts argued that even if there is a forced delegation and we attach this ‑‑ we can attach this ccTLD to the group of ‑‑ to the plaintiff, this will impair ICANN's interest in protecting the stability and interoperability of the Domain Name System. So, the Court actually considered the third-party interest in this other than going into whether it's property or not. It's also considering interoperability must be damaged. However, it did not say exactly why, but that the rights of the third party might be impaired, but we can interpret from what it says about the stability and interoperability, that if they actually attach this, that ir to a group of terrorism victims then, and even if they run it really well, the country that is affected by this might look for other alternative roots, and that this might, actually, end up with fragmentation. And, well, yeah. That's about it.
>> MILTON MUELLER: Very good. So clearly, the issue of a geopolitical fragmentation of the root seems to have played a role in the court decision, denying the ability of the Israeli victims to seize the domain name. So, that was the result. Do we have any comments or questions about this case at this time, or go the geopolitical issues before we move on to the next segment?
All right. So, I would say, that the consensus is that we have a very low risk of a geopolitical fragmentation. We've discussed a case of a country that is very sovereignty oriented, and very not in the greatest relationship with the U.S., where ICANN is incorporated, but according to Oleg, we mainly have backup and redundancy issues going on there and not really an attempt to fragment the U.S. root. We've seen a U.S. court consider ICANN's interest in interoperability to be a divisive factor in a top‑level case about the Caesar of a top‑level domain.
Second, we turn to the YETI project, and here I'd like to turn it over to Paul Vixie to make a short presentation about the essence of what he's doing. He could be supplemented by Mr. Song, if he cares to jump in, and we will probably also hear from Kaveh or Andrew on this topic. Yes.
>> PAUL VIXIE: Thank you, Milton. I'll keep my remarks as brief and as self‑evident as possible so that we can make progress rather than debate the facts as they are.
First, let me say that YETI has three coordinators. Sony, the Y in Japan is another, and I'm the third. I'll be speaking in my personal capacity, and I'll try not to say anything that I know the others would disagree with, and if I do, that is an error, but cannot speak to the project as a whole.
So, these are my observations. YETI is not going to fork the INANA space. We will not be amending it other than in some small way to network science that we add a TLTD that has a bar or some other necessary thing that is needed to test certain effectiveness. We're not a production system anyway, so if we did amend the IANA space, it would have real commercial ‑‑ and the commitment to following the IANA absolute, and there is just no responsibility that we will be one of the ultimate root providers that I have spoken against over the years.
YETI‑DNS does prove that the IANA space can be forked, and so it is politically interesting for that reason. We thought that this would not be possible because of DNS Sec, but it turns out that the Internet, as we used to see when I was on the Erin board of trustees, is powered by cooperation. It's set rare to be able to unilaterally impose terms of other people on the Internet because they have the option to not talk to you. If you want to create and it's not interesting to them, they probably just won't fetch it from you and so forth.
So, whatever you're going to do on the Internet, in order that it be relevant and successful, has got to be in cooperation with the other people on the Internet.
But, within that umbrella, there is absolutely a way that certain population of ISP, universities, whatever, companies, your domain name operator, to assume that someone else's key, and someone else's name servers, instead of the 12 of us who operate the 13 IANA servers, and you could create a parallel system that was powered completely by the optimum cooperation of the people who were publishing and subscribing.
And this is interesting, politically speaking, not that we intend to do it, but we demonstrated how it can be done and how it will work and it will scale.
I want to say that many enterprise networks have already amended their internal DNS space. They use a feature called Views which we put into 9, 15 or 20 years ago, and just do it that way. Or they do pretty much what YETI is doing, but they do it on an internal basis. Your own employees and your own internal servers have no reasonable expectation of autonomy if you want them to see a certain view of the DNS. You can impose that, and that has been done, and that's why .corps was such a name invasion feature and .home because a lot of people were amending the name space they saw to include those domain names, which complicated ICANN's ability to assign those names on a practical unique basis to anyone else.
But as it turns out, that in the YETI effort, if shown how that enterprise level DNS amendment process can be extended to include DNS Sec. And in fact, that will make it work better. It will make it more resilient and stronger, so this is a small burden for a big payoff.
Let me continue. So, in Q1, Russia's experiment and their live fire exercise was mentioned, and I want to point out that another thing demonstrated by YETI is that any region, any economy, any sovereign nation could fork the name space in order to do one of two things. Possibly, so they can maintain a non‑controversial view of the name space after a controversial change, such as, I don't know, yanking .ru out of the root zone because a war just started. I don't think a war is going to start. I don't think it would include yanking .ru, so I just want to say if that happened, any national or any sovereign nation could, at their discretion, do what YETI has done. Simply tell the name operators in that country or that region or economy, that here is an alternative way to view the Internet name space and it still has .ru in it. That would be a lot more work than just asking the main server operators to autonomously stop and reject a certain change. It probably is quite correct that won't work, but if you fork the name space, then you would have infinite power in this regard.
Let me say that, IANA could embrace this approach. They could say, we're going to sign a root zone ‑‑ we're going to sign a second root zone that has the same name space but a different set of name servers, thus facilitating the ability of various regions, various economies, maybe a region as small as a single house or a single laptop to become their own root name service. And, I'm going to propose this to them, and you know, it's been pondered. Any time you talk about it, it's a dangerous topic and usually ends by everybody saying, no, let's not touch it.
Finally, let me say that the reason that every alternate root system to date has failed is because IANA has been cooperative. We have worked with the community. When there was a lot of interest in new gTLD, ICANN found a way to allow it to happen. They didn't say, no, we're purists, and we're not going to do it.
And before IANA, the other IANA operators, have also been as cooperative as possible. We follow the ETF, which is a completely open process that is not dominated by any company or nation. And as long as IANA continues to cooperate in the way that it always has, I don't think there will ever be a need for an alternate root name space where that need comes within an order of magnitude, it's the cost of producing it.
So, I view all of the dangers that are demonstrated now by YETI to be possible, are still well out of reach. I'm excited to see innovation in naming. I would like to see things that don't look like DNS added that. I think there is room for many different namespaces, but I think that the unique universal DNS namespace that we have today is a jewel of the world, and I'm glad that it is structurally defended by its very nature against the, kind of, crumbling that a lot of other infrastructure would otherwise see. So, thank you. Those are my remarks.
>> MILTON MUELLER: Thank you, Paul. Yes. You make a very interesting case about the actual science behind these efforts that might lead to proliferation of the root. As I understand it, you're telling us that even with DNS Sec, it can happen, and indeed, there are possibilities, I guess, because of the hierarchical and recursive nature of the namespace for this to, actually, go very far, down to the regional level and not just the national level. So, Mr. Song, did you want to supplement anything that Paul said?
>> ZHENG SONG: Yes. How long can I have?
>> MILTON MUELLER: A few minutes.
>> ZHENG SONG: A few minutes. Okay. One is that, we're not three coordinators in this project. Currently, we have 16 participants to serve ‑‑ to donate some servers over VPS, and they're joining the discussions. We have to engage more input, so I would like to say that the project is a pure community and consensus driven, it's not just decided by one person. Okay.
The second, the second point that I want to add is that, this project would like to encourage more permissionless innovations in the DNS field because many people say that in DNS fields, especially DNS OP working group, that people compare it as a place that are after the proposal dies. So, it's very hard to promote any new ideas, or try, especially in this system, the diversity feature of the system, it's very important. So, it's very hard to set up a very small scale testbed to try new ideas, so that's why we set up a global and a live testbed for the purpose.
Currently, there are a lot of discussions on the technical, so I don't want to repeat them here, so I don't want to emphasize on that two points again. Thank you.
>> MILTON MUELLER: Excellent. Now, we have two people that want to get in here. I'm not sure of the proper sequence. Does it matter? So, let's start with you, Kaveh.
>> KAVEH PANJBAR: Thank you, thank you Paul and David for your comments.
I have two comments. One is, yes, Paul explained the possibilities and technological possibilities of having an ultimate root, but to be honest, it's much more complex with that. Without assigning keys, people have to trust the key, but the other complex part is the resolver use. A lot of people use Google Public DNS, and it depends how much that government or that economy has control over the ISPs, for example, to direct them to specific resolvers and things like that. So, I'm not saying it's impossible, but it's really complex.
The second thing I ‑‑ and in a view that I stated at the very beginning, if I interpret what Paul said in that view, I agree with him, but it won't be part of the Internet. Because for me, what is the Internet, is what is coming from IETF. And IETF says that's single root. As soon as IETF might actually come up some day with an RFC and say after resolvers, after looking up the first namespace, when they don't get a result, you have to look into the second namespace, and if there is a result, you have to use that. I don't know. It's possible. As soon as IETF says that, I will advise my organizations to definitely implement that and use that because that's IETF.
So, the glue that keeps this thing together is IETF. Internet is often platform and that's the great power of it. People can try and test anything they want, and they should be able to do that. And if there is anything stopping them from doing that, we should remove that obstacle.
But at the end, what I call Internet is what is coming from IETF. And anything outside of that, that might be done over Internet or any other network or phone or whatever. If it's within IETF, I call it Internet, and if there is fragmentation there, I would be worried. If it's outside of that, I don't call it Internet. And yes, this is using that network for some other experiment or whatever it is, which is fine, and I fully support that.
>> MILTON MUELLER: Great.
>> PAUL VIXIE: I wish to follow up.
>> MILTON MUELLER: Yeah. Go ahead, Paul.
>> PAUL VIXIE: So, I agree in the technical sense with Kaveh. The technology I'm describing is not the Internet. It would, at best, intranet technologies which are usually applied on a wider scale, but it would still, technically, not be the Internet. So, I agree with Kaveh's distinction, and I thank him for it.
>> MILTON MUELLER: Okay. So, Andrew, Kaveh has just said that it's IETF that has ultimate authority and you're the critical position of IETF, so it's going to be interesting to hear your perspective.
>> ANDREW SULLIVAN: So, first of all, once again, I want to make it perfectly clear I'm the Chair. I do not speak for them, and if they heard I spoke for them, they would come and hit me with pitch forks and so on. This is not a position that I'm expressing on behalf of the IAB or anyone.
But, I do want to quibble a little bit with this description of the IETF as being somehow in control of this. The Internet, from my point of view, is something of a shared hallucination, it's a collaborative effort, and it emerges by the fact that all of these different individual networks share some common paths so that they work together.
And they work together because it's in the interests of every single network to work with all of the other networks. So, the magic of the Internet is that there is no central authority, not the IETF, not ICANN, not the IGF, not the UN, not any particular government, not me, not you, not the hacker in the basement. There is really nobody in the middle.
And that key feature is one of the things that makes the Internet the kind of magical thing that it is. Because what it does, what the protocols allow you to do, is to make arbitrary connections between people who don't have pre‑existing contractual relationships to one another. And can you do that without anybody's permission. This is precisely Davie's point, about the permissionless innovation. That's the key trick.
Given that, we have a couple of distinctions that we can make that, I think, are useful, and I think Paul makes these in his remark, implicitly, but I want to draw them out to be clear because not everybody here has the technical background.
And that is the distinction between the namespace, that is the space of hierarchical names that we use, part of which, shows up in the DNS, and the DNS itself, which is an expression of some piece of that hierarchical namespace.
So, there are pieces of the namespace that you use that aren't actually part of the Internet namespace. That is, they're not part of the one that is expressed in the DNS.
The DNS, for instance, doesn't contain dot local but anybody in the room using an Apple device uses dot local all the time because it's part of a mechanism that you use for local only, like immediately on your LAN, resolution of stuff.
So, when you set up your home router, often you use this thing. It's part of the namespace, right. It's part of that big giant hierarchical namespace, but it's not in the DNS.
And this distinction is useful because it allows, precisely the point that Paul was making about YETI and Kaveh was making about YETI being, you know, sort of involved with the Internet without being part of that Internet expression of the namespace.
It's parallel to it. And it's a parallel name implementation of it within the same namespace. So, the way you would fork the DNS is, in effect, to go off intranet and go on to another intranet that would not be the capital Internet with an I, the one we have shared, it would be a different Internet, networks of networks that were connected that couldn't talk to the first one. And this is the mathematical point I was making earlier, that if you wanted to do that, and you wanted to have these parallel things, then essentially what you would be doing is creating a new root before the root that would tell you, well, am I in the left‑hand one or the right‑hand one? And if you want to do that again, you could keep doing it. But actually, you still have a common root, because that's a fact of math.
Any time you've got a hierarchy, it has to resolve to a common root, that's the nature of directed graphs.
And so, I think this fact means that, you know, there is a technical resistance to fragmenting, and there is also a practical resistance to fragmenting.
The practical resistance, I agree with Paul, that the reason the DNS hasn't fragmented in these terrible ways is partly because IANA has been cooperative. But it's also because everybody's self‑interest is in having a common namespace, because if you break it, you can no longer go to those websites that you wanted to in order to view the cat videos or whatever it was that you wanted to do.
And I think that's a key piece of this. Each of us has an incentive to promote this, and we have to remember that it's not because of somebody's authority that we get the Internet, but because everyone's self‑interest promotes it.
>> I wish to follow up.
>> MILTON MUELLER: Go ahead.
>> PAUL VIXIE: So, I agree with everything Andrew just said, but I wish to amplify a distinction. While it's true that if you wanted to create another Internet‑like directed graph, you could certainly do so, and that is done in test labs all the time that. Is done, in a sense, by a lot of large enterprises I mentioned in my remarks, but that does not necessarily mean that you will not be able to reach the first Internet. Because, if for example, your policy for a namespace fork is that you will exactly hear everything that IANA says, but you will add one pseudo‑top‑level domain called .corps to identify resources that are only reachable inside the enterprise network itself. Then you will, in fact, still be able to reach what Andrew referred to as the other Internet, but you will have the additional ability to reach, by name, some assets that the rest of the world cannot see.
And so, I just want to make sure it's clear that for YETI, for example, we do not amend the namespace, and any participant in the YETI science fair is able to reach the entire Internet exactly as they would through the IANA service with one of the differences for us being that they will have to be speaking on ITV6 because that's all we support, but other than that, the content is intended to be the same.
So not all forks are completely unique, and many forks will have reachability into the big I, Internet. Thank you.
>> MILTON MUELLER: Just want to supplement what Andrew said also with the observation that, again, it is true that it is not the cooperativeness of IANA by itself, although, the policy adjustments Paul described were significant for stalling threats of a root. In economics, we call this a Nash equilibrium in which no party is to deviate. It's similar to driving on opposite sides of the root in the automobile, you can do it, but why would you want to.
So, with that, now we go on to our next segment, and that has to do with innovation in naming space, and, I think, we're also putting the issue of special naming into that category now.
So, here we're going to hear mostly from Brenden and Ryan, so we'll start with Brenden and then turn to Ryan to talk about the issue of whether this convergence, on a single namespace, which by its nature encourages a single hierarchy, has stifled innovation in naming, or how do you reconcile innovation with this convergence?
>> BRENDEN KUERBIS: Thanks Milton. So, I think, probably Andrew and the business folks are in a better place to comment about specific innovation going on in the naming area and how the DNS impacts them, but from my perspective, whether or not you converge on the DNS and whether that stifles innovation is largely dependent on how the DNS is governed.
As I mentioned in the opening, in my opinion, if we focus on security and stability of the DNS, while at the same time continuing to foster innovation at the core infrastructure, we're going to be in a good spot.
If we assume that that's a reasonable objective, the question becomes, well, do we have adequate governance structures in place to accomplish that? And what are governance structures? I'm an academic, so we'll take a short detour into theory, but it comes from transaction cost economics, and more broadly, institutional economics. And in that field, a governance structure is a shorthand expression for an institutional framework in which contracts are initiated, negotiated, enforced, terminated.
And there are three broad categories of governance structures, markets, hierarchy, and networks. In the prior work in that field, established that the cost associated with particular types of transactions depends on that governance structure in which they take place. And well‑designed governance structures reduce the transaction costs and enable parties to cooperate with one another in mutually beneficial ways.
Arguably, it's this networked governance structure, not pure markets, nor top‑down in position of order that works best to protect innovation in naming systems and prevent fragmentation of the DNS.
And we see that in the institutional innovations that we most recently just had in the public technical identifiers organization, the legally separate affiliate of ICANN that is responsible for providing the IANA functions, and also the set of agreements that the PTI maintains with the name, numbers, and protocols communities.
You know, more specifically, if you drill down the bylaws and the PTI, give it a specific purpose to perform the IANA function, that is maintain the registries on behalf of ICANN, it has no policy role. It has no role in determining who gets what identifier for a specific naming system. It's simply the decisions of its customers, names, numbers, and protocol communities.
More importantly, in my opinion, in the bylaw, it states it shall treat the IANA functions with equal priority, that all of the customers will be treated in nondiscriminatory manner. That is in an IETF request comes in for the creation of a special use name. It won't be treated any differently than an ICANN request for the creation of a new GTLD.
And also, importantly, the bylaws stipulate that it shall provide service to its customers in conformance with the technical norms, and in support of a global, secure, stable, and resilient DNS.
So, there are some other aspects of the PTI, like a code of conduct, also a conflict of interest policy, which are very important, but it's those bylaws, the governing, the creation of the PTI, and also the agreements between PTI and the communities that ensure that PTI meets the respective objectives of the communities.
So, in other words, it's this institutionalization of a networked governance structure that involves all the communities that leads to a mutually beneficial outcome. It reduces the transaction costs for actors that want to innovate in the naming space like blockspace and the tour project. They can create protocols for complementary or even competing naming systems, and can be assured that their request for globally compatibility identifiers will be satisfied by the PTI.
And the transaction cost for DNS actors are also reduced because they can be assured that innovation in naming won't inhibit the stability or the security of the global DNS.
>> MILTON MUELLER: Thank you, Brenden. So essentially, you're saying that PTI has been set up as, kind of, a nondiscriminatory way of coordinating the namespace, and you're characterizing it as network governance between IETF, ICANN, and any other naming infrastructure that might develop?
>> BRENDEN KUERBIS: Correct. Yeah. I would say, it's a networked form of governance, and in fact, the very mechanisms that were used to actually go through the exercise of creating the PTI were a networked form of governance, as well.
>> MILTON MUELLER: All right. Now, let's hear from Ryan. Ryan is working with Blockstack, and I think here we're looking at a significant technical change in the way a naming infrastructure is set up. It's not your traditional DNS, and so it will be interesting to consider the implications of this for the existing naming hierarchy. Ryan?
>> RYAN SHEA: Yeah. Thanks. I'm here again. We're both here to talk about Blockstack. You asked earlier whether the current structure ‑‑ whether we feel the current structure is conducive to innovation space and conducive to additional types of systems.
And you know, we can talk you through what we've been thinking. We have ‑‑ we have our own system which runs on top of a blockchain tech, and there are many nodes that work together to maintain the system.
I will say that it's an important distinction to make, because let's say you have 1,000 nodes, there is no ‑‑ it's not like a federation, or it's not like a hierarchical system where each one of them has a jurisdiction over a certain vertical slice of the system. It's more like all of them together maintain the entirety of the system.
And so, in our system, so Blockstack actually runs on top of ‑‑ there is one network, one block that runs on a single blockchain, called the big blockchain, but it's inherently blockchain, so you can run different, you can even fork the blockchain network that are running on different areas.
You also have Namepoint, which is a very early blockchain which some of you may be familiar with, which has its own namespaces. So, there are namespaces within Namepoint, and namespaces within Blockstack, and actually Blockstack provides an interface for someone to go into the command line and create their own namespace within Blockstack. And within there, they can actually set their configuration and parameters when they go in. They can, for example, create set pricing rules that are automatically integrated into the system, so maybe a two‑letter name is really expensive, but they want eight‑letter names with numerical characters to be cheaper, and they can have the pricing function, and they can also set how long they want to take the names to expire.
So, what we're really trying to do is create this area, where then other people can create their own namespaces within Blockstack. And one thing that we thought about, is okay. We're trying to bring this to consumers. We're trying to allow consumers to access and resolve these domains in their web browser, and so they need to ‑‑ but we also want them to have access to the traditional namespaces and the Internet that's under IANA and ICANN, and so we have to figure out a way to reconcile that. So, when they type something in the browser, the browser knows how to, or knows how to resolve, either to our system or to, you know, the traditional hierarchical DNS system.
One challenge, of course, is that, what we could do is we could buy, we could bid on a TLD, and this is what we would like to do, and say, you know, this TLD is, at least, reserved. Or we could work with organizations to say, reserve this for Blockstack, just like you have .local. The latter makes sense, but it requires a lot of work on our part.
The former doesn't actually exist because there are restrictions how to operate namespaces and our system doesn't work like that space.
>> MUNEEB ALI: And I'm going to, basically, compare DNS with Blockstack a little bit, where you guys have a little bit more background. As Ryan mentioned, there is a flat namespace, so there are no groups of servers, so you can, basically, think of this as an alternate root where the security and the integrity of the data is actually backed by blockchain. It's decentralized and because the data written in the blockchain gets more and more secure over time, right.
And the way that we implemented this, like we already have one TLD. It's .id. It's operational. We've been running it for more than two years now. There are around 70,000 names registered in that TLD today.
And just from an operational point of view, one thing that we have noticed, which is very interesting, is that we don't have a cache and validation problem in our system. Only the blockchain is the medium where new updates can come in. So, all of our DNS resolvers are, actually, going to keep things in memory and give you very high performance for these lockups.
Another interesting feature is that all of the names are owned by public keys. So, if you, kind of, like collapse the PKI and DNS into a single layer where everyone gets a public key by default, you don't have to go and get security certificates separately.
So, and then, all of this is Open Source and you can actually find out more on Blockstack.org.
>> MILTON MUELLER: Thank you. And I'm sorry I never got the name of the second member. I just had Ryan's name so I apologize for not introducing you.
>> MUNEEB ALI: Don't worry.
>> MILTON MUELLER: This is very fascinating. So, not only are you promoting an alternate technology, which seems to be kind of an IANA of blockchain, in a sense, that it tries to bring them all together and make them all compatible, but you are also interlinking with the existing DNS through a TLD, and let me draw on my own experience in telecommunications competition to draw an analogy here. Let me see if you think it's valid.
In the early days of telephony, you had competing and non‑intercompeting telephone systems. And, one of the members of the systems would want to buy a private line into the other system in order to interconnect them. And this was resisted, at the time, because it diminished the advantage that one of the competitors had through the aforementioned network externality, that if you could just start a little, tiny network and then connect to the bigger one, you would get all the advantages of the scale of scope without actually having to build a large network.
So, what you're saying with a TLD linkage into the DNS, you can have the global compatibility of the DNS, but you don't have to have the massive infrastructure of the Legacy domain name system. Is that correct?
>> RYAN SHEA: Yes. That's correct.
>> MILTON MUELLER: That was good. (Laughing). All right. So, one of the policy implications of that is, that typically, when institutional and policy mechanisms are built on top of a bottleneck, such as a DNS root, then when a competing technology comes along, it can undermine that policy leverage. So, for example, the people who want to control what names you can get for law enforcement or trademark purposes might be very opposed to a technology that gets you out from under the ICANN regulations, and that would start creating political and legal pressure to maybe regulate or control or even prohibit the new technology. So, do we see any risk here? I'm getting some desire to intervene here from Andrew.
>> ANDREW SULLIVAN: Thank you. So, I think, I mean, the first thing I want to say is that I think this and other comparable technologies are really interesting ones. And, I think that, think the key thing is that this isn't really an alternate root in the ordinary sense of being, you know, a split of the DNS or even the Internet namespace, but it's instead, a different naming system. But it's a different naming system that is intended to scale to Internet scale or maybe not, because of its flatness, but it's not clear. But that's part of the way you learn these things, is to try them out and deploy them.
But, I think that there is a key thing here about the compatibility between this and the existing Internet naming system that we should pay attention to, and that is, a lot of people come along and they want to introduce these things. What they say is, well, we need a TLD. But in fact, you don't need that. Right. You could insert this thing anywhere in the DNS tree. And the reason that people want to do a TLD, is usually, because of limitations of the DNS itself.
So, the DNS has this built‑in limitation that has to do with implementation details decided in 1983, and because of that, we have this heritage that we've got to stick to.
And, I think that, historically, the way this happened is people just picked a TLD because the root was very stable and didn't change much, so it wasn't a big risk to just add something there.
That was always a risky project, and it was just the people who figured it wasn't a big risk, sort of like, you know, in Western Canada, like, a lot of people live in Vancouver and think there is no risk of an earthquake because we haven't had one in a really long time.
But what's happened, of course, is there is now this risk because there is seismic tension, and similarly here, there was seismic tension in the root and so that gave and then they decided, well, we'll expand the root a lot. And we don't know the limits of that expansion anymore.
What that means is that picking a random string and putting it as a TLD is now a dangerous activity, and we don't know how that's going to interact with the rest of the Internet, so I think that's where some of the tension comes.
>> I think Andrew, basically, mentioned what I wanted to mention. But going a little bit back, about the self‑interest factor, because I think that's a very important driver for the whole thing and the special names part.
So, I fully agree that the interest is the main driver for actually not driving in the opposite direction on the road, but I have a question. Do you ‑‑ because Andrew mentioned that that mathematical, that you need the root. My question is, do you see root difference in, let's say, routing? Root is hierarchical, so in that sense, it's different. But is it more critical than routing or numbering.
>> No.
>> Okay. So then if the answer is no, then this applies to all of the whole Internet, so do we have to give it special attention to root fragmentation or having an alternate root where we don't care about if people run a network in parallel GBP, for example, or use their own schemes. Because we don't have panels on addressing fragmentation, for example, or VCP, and I'm saying ‑‑ I'm not saying it's not important, but I'm saying that this is all similar, of similar importance, and you're not giving ‑‑ Internet is open innovation platform, and people can try any of this. And I will go back to what I say, what I call Internet is IETF Internet because that was my main point, and ‑‑
>> MILTON MUELLER: So the new technologies in routing are just as much of a risk of some kind of a forking DNS. It's not that there is something unique about DNS.
>> Yeah.
>> MILTON MUELLER: Very good.
>> And I just ‑‑
>> MILTON MUELLER: I just want to ask if the Blockstack guys want to intervene here in response to anything they've heard so far?
>> RYAN SHEA: Yeah. Yeah. I was going to mention, I think building up to what Andrew was saying, he's saying that we don't necessarily need a TLD, where we could use anywhere, we could use an existing domain that we already own and then put everything, like, subdomains at Blockstack.org, for example. The issue there is it just defeats the purpose of the system because then every resolution depends on trust that is placed with our domain. Right. And it also, significantly hampers feasibility of the system because now everyone has to type in, you know, like two additional levels there.
So actually, having a ‑‑ having some equivalent like .local would be huge. I would say, a prerequisite in order for both security and usability.
And then the second thing I'd like to point out, is that while, you know, it's absolutely right that you need, like, logically you need a root. You need a logical root, but you don't necessarily need an organizational root. And our system is one like that. In our system, we have a directory of namespaces with no ‑‑ with a logical root, which is the blockchain itself, but no organization or single entity that is maintaining that root.
>> Yeah. And for the question about policy issues and what level of control organizations or governments can have over this, I would say that both stems from having a centralized root. I think, in my mind, even if it's federated, it's kind of centralized. There is a target, and we see this in attacks where people have a clear target of what to go after.
If you don't have that centralized place at all, on the one hand, it becomes harder to control it; but on the other hand, it's actually much more secure as well, right, because you don't have this party that is easy to take out by a malicious act, or for example, DDOS attacks which we have seen recently, a major outage reason.
So, in terms of like long‑term security of the infrastructure, I feel like this is something that we have to reconsider that should we have a DNS system that actually doesn't have a root that can be taken down or attacked, which is one of the reasons.
>> MILTON MUELLER: Very good. Yeah. So, the point is that the status quo does have a root, and you're trying to bridge into a non‑root system. I can think of maybe six people, right off the bat, who would move to deny you a TLD application because they think you're going to undermine the ICANN system.
And unfortunately, the TLD application process is absurdly discretional and regulatory, and I'm just warning you to watch out for that.
Now, Kaveh, we're going to go to you, and then I really want to open it up. There is a lot of really smart people in the audience. I want to give them a chance. We'll have about 15 minutes for that.
>> KAVEH PANJBAR: I will be very quick. I just don't remember if I did the disclaimer that I'm representing myself, so I just want to mention that.
Second, I disagree with the first point that was mentioned about the need for the roots, the reasons, but I saw Andy wrote a lot of comments so ‑‑
>> ANDREW SULLIVAN: Go ahead.
>> KAVEH PANJBAR: Please, I'll leave it to you.
>> ANDREW SULLIVAN: All right. We're the Mutt and Jeff show here. I think the key point is that there is this trick, and I guess, we were going to talk about this anyway, so I might as well mention them. There is a distension between the root of the DNS and the special use names in the DNS. Special use names in the namespace, which are not necessarily in the DNS. An example of this is local, and another one is onion. They do not have to be at the root or at the top level. They don't have to be at the top‑most level, and they can function, actually, in your resolution process as a, kind of, switch to the system. So, they're an in‑band signal. Some of you remember the old‑fashion telephone, you remember in-band versus out-of-band singling. When you dropped coins in the coin box, you hear the beep, that's in‑band singling. Adding local to a name, that's the same kind of singling. Hey, wait a minute, this is a local name, it doesn't go on the Internet, it stays with this other kind of resolver. So, putting a name lower in the DNS tree that was under your control, or that had a special name entry in the special names registry, without necessarily being at the top level, would still work for that purpose because it would signal to the computer, oh, you don't want to go out in through the DNS, you go this other way, and that will work well.
So, that's a good way in which we can support this kind of innovation, but I've talked enough, so I want to open it up to somebody else.
>> MILTON MUELLER: All right. Any other comments from the panelists? Doesn't look like it, so let's open it up ‑‑
>> MILTON MUELLER: Okay. One more. Yep?
>> AUDIENCE MEMBER: Okay. Just to clarify, there would still need to be a reservation so that nobody is able to ‑‑ or to register a .onion or a .local. Correct? That's really what we've been referring to. I think we're on the same page.
>> ANDREW SULLIVAN: Yeah. That's right. There is a special registry maintained as part of the IANA protocol registries that lists these things, and there is a whole bunch of them, right. That's what local host is. That's what all of the special values for the RFC 19, 18, addresses, and so on. But I think that, you know, if you want to follow up on the details of this mechanism, this would be a great conversation to have offline so we can open up on the wider topic, but definitely contact me, and I can explain it more.
>> AUDIENCE MEMBER: Thank you.
>> MILTON MUELLER: All right. We have 10 minute, so I'm opening it up to questions from the floor. I see the gentlemen here raising his hand. Be aware that there are only 10 minute, and there may be others who want to speak also.
>> AUDIENCE MEMBER: Okay. Thank you, Milton, and I also thank the panelists for a very enlightening discussion. Since we're talking about possible threats to DNS, I want to find out from the panelists whether the concentration for the possible threat of DOA, Digital Object Architecture? Thank you.
>> MILTON MUELLER: Brenden, you're somewhat familiar with DOA, the Digital Object Architecture, can you see that as a threat to the DNS?
>> BRENDEN KUERBIS: No. I see it as two things ‑‑
>> MILTON MUELLER: We're not that pressed for time, you can say a bit more.
>> BRENDEN KUERBIS: (Laughing). The DOA is interesting. I think that presents an instance of institutional competition. The DOA is for people who don't know what DOA is, it's the Digital Object Architecture. It provides persistent locaters for digital objects as opposed to domain names that blend location and resources.
So, you know, when you actually look at what the DOA system does, it's complementary to what the DNS does. It may raise some interesting conversations, I guess, about ‑‑ particularly around intellectual property interests, I think, who may want to use the DOA system but are heavily invested in the DNS system. But I would say, no, it's not.
>> MILTON MUELLER: Very good question. I'm glad you brought that up. We probably should have discussed that in our innovation section. Any other questions from the audience? Yes, Kaveh wants to address the DOA question also. It doesn't mean dead on arrival, does it?
>> KAVEH PANJBAR: No. So, I agree with Brenden that the answer is, no. But actually, back in my own view, if they continue pushing for that, and if they can attract a critical mass of people who actually like, let's say million or billions of IOT user who use this as a naming system, and then they decide to run this whole thing outside of IETF, never standardize within IETF, then there might be risk. I don't know because it depends how they promote or use it. But if it starts conflicting with what we have in DNS and then keep pushing for that and never bring it back to IETF, then yes, I see a big risk.
But that has these two prerequisite. First of all, they will be able to bring the critical mass of users to the system. And second, having insisting on, like, competing with IETF, then it comes to standardization.
>> MILTON MUELLER: So in effect, you are reinforcing Brenden's point that this is about institutional competition between the IETF complex and the IETU complex so that some people are concerned that if the IETU seizes upon a new and useful technology that it might come to overcome the IETF, is that right?
>> KAVEH PANJBAR: Close enough. Yes.
>> MILTON MUELLER: Andrew?
>> ANDREW SULLIVAN: Well, I really have to disagree with this. I'll be very quick so that you can ask. Because, you know, while I was sitting here trying to keep track of the time, several tweets came by, and Twitter handles are another namespace, and nothing to do with the IETF. But I think it's weird to say they're not part of the Internet. I don't think the IETF is the special boss of the Internet, and I reject that characterization.
>> MILTON MUELLER: Yes? Identify yourself so people know how distinguished you are.
>> AUDIENCE MEMBER: Sure. This is Jorge Ganzo from the Swiss government, for the record. I was very interested in the conversation we had, or you had, on the blockchain application to the DNS, and I found the observation by Andrew Sullivan very, very precise that we are talking about a different system and not an alternate system.
And while, from a policy level, it comes to your mind, and I think that Milton already touched upon that, that this has the potential of a disruptive innovation because it's not an alternative with the same kind of setting as the current root, but it's a system where you have efficiency gains because you get away with a center. That's a gain in itself, potentially. And, you also have all of these trusts and security gains, which go with a system in itself.
So, my question to you, you know much better than I do, are we at the beginning of a possible extension of this first DNS, or is this something that will go by and will be perhaps complementary to what we have? Thank you.
>> PAUL VIXIE: I'd like to speak.
>> MILTON MUELLER: Paul, go ahead.
>> PAUL VIXIE: So, the Internet has changed a lot since it was commercialized, and it had changed even somewhat even before 1995 when it became a commercial effort.
But, the installed base has always been our guide. I was working on the DNS quite a bit back in the '80s and '90s, and even into the aughts, and many times, we had a great idea for a system that could work better, and constraints needed more to be more resilient and perform better and so on. And, we were never able to do that. We were never able to say, okay, we're going to have a flag day, and after this time, the old DNS is going to get turned off and we're going to use this new one, simply because the installed base is a very long tail. There are Internet connected devices that will never be updated, upgraded, replaced, they'll never wear out, and they speak the old protocol.
So, that has kept us within a fairly narrow band of innovation, which I recognize is a constraint on the economy that depends on the Internet, which is that sometimes they would like things to work so differently that they wouldn't be compatibility with the current system. And the only way to really progress that is with efforts like Namecoin or Blockstack or the Twitter namespace that have been mentioned here.
But in any case, I think that something like the DNS is going to be a permanent fixture on the Internet, and we'll never see its sunset. Thank you.
>> MILTON MUELLER: Well, we have a few more minutes. Are there any other questions from the audience or another comment? It doesn't look like we do, so ‑‑ oh, Mr. Nelson, yes, we have a comment.
>> AUDIENCE MEMBER: As usual, I'll ask a question about technology and communication. This has been a really useful discussion, great people. We just went through the most bizarre political debate in Washington this year at the end of September, where a number of noted Republicans wanted to stop Obama from giving up control of the Internet.
So, I challenge anybody in the panel to come up with a better bumper sticker to explain what really happens in seven or eight words.
>> MILTON MUELLER: I have mine. Some of my colleagues don't like it very much, but it's Internet popular sovereignty. We gave the Internet to the people, we eliminated the national sovereignty, and created popular sovereignty on the Internet, so that's my bumper sticker. I don't know if others have one?
>> PAUL VIXIE: I have mine. Mine is, it was never our property. We were its custodian.
>> Sort of similarly, I think, to Paul, I felt that, and, in fact, spent a great deal of time and effort talking to people where I kept pointing out, that all we were doing is letting the people who were already running it do their jobs.
The idea that the government opened it was a, sort of, weirdo idea that only people, who didn't understand how the thing worked, could have come up with. So, what we were saying was, these are the people that are already making or doing this, so let them do it.
And, I won't comment on whether it was strange that the Republican Party was the one that was arguing that the government should be more involved.
>> MILTON MUELLER: Well, it is not strange because sovereignty and nationalism are very connected. We know that conservative nationalists exist in many different countries, and they will be continuing to assert a more sovereign control over the Internet, which brings me to a shameless plug.
The Internet Governance Project will be running a workshop on just this very project. We're talking about the way cybersecurity concerns are transforming Internet governance, and we think that's a very divisive change of focus of the world of Internet governance, that now the transition is over, we settled the issue about names and numbers, but now we have to deal with the cybersecurity possibly renationalizing everything.
So, if anybody is interested in the rational of this, we have a flyer that you can grab a copy of and pay attention to what we're doing.
With that, we are being told that our time is running out, and I thank all of our panelists. I really think this was a very good panel, and I appreciate all of your attendance. Bye‑bye.
>> PAUL VIXIE: Thank you, Milton.
>> Thank you.
>> Thank you, everyone.
(session completed at 1:27 p.m. CST)