The following are the outputs of the captioning taken during an IGF virtual intervention. 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, but should not be treated as an authoritative record.
***
>> DAVID HUBERMAN: Okay, it is the top of the hour. We'll go ahead and get started momentarily.
>> Hi, I was asked to step in as the onsite moderator, but as you can see, we have a completely empty room. So I'm willing to stand by if needed, but I think the online moderator can take the meeting away.
>> DAVID HUBERMAN: Great, thank you so much.
>> I'll it is here in the moderator spot, so it looks right.
>> DAVID HUBERMAN: Thank you. Okay. Ken, when you are ready, so are we.
>> RENARD KEN: I'm ready, thanks.
>> I hope you can hear me. I have struggled with access to this meeting, but it seems like things are working now.
>> DAVID HUBERMAN: Yeah, your mic is very faint.
>> Okay, is this better?
>> DAVID HUBERMAN: A little bit, yes.
>> Okay, I'll see what I can do. If I can fiddle with something as Ken speaks. We were expecting to have Fred with us, right?
>> DAVID HUBERMAN: Yeah. Okay.
>> I am wondering if he's struggling with access to the system. I had to jump through all kinds of hoops and trick the system to get here. But if not, I think we can handle it, can't we?
>> RENARD KEN: Sure.
>> LA RS-JOHAN LIMAN: So I'm ready to go if you are. Who is supposed to start, was that you, Ken?
>> RENARD KEN: Sure, I can start. So good morning, good afternoon, good evening. This is Renard Ken. I work with the U.S. Army research lab. We are a root name server operator. Today we're going to talk about the root server system. And kind of setting things up to discuss and understand governance of the root server system.
So we're going to talk about the overview of DNS level set, make sure we're on the same page technically. Go on to some root server system, how it appears today, a little bit about the ICANN vents and the organization within the root server system. And how the root server system is evolving. And specifically with respect to governance. We can go to the next slide.
All right so, again, a technical background here. I hope this isn't too basic for everyone, but just want to make sure we're all on the same page technically. Looking at DNS, how it works with a focus on the root server system. So as we know, the internet, the fundamental identifier on the internet is the IP address, it's a string of bits. We usually see it as a numerical label. We have two versions of the internet protocol, IP v4 and v6. And you see some addresses down there, they probably look familiar. Next slide.
So why did we go through and do this whole DNS thing? This goes back to 1980s. The original problem was that we as humans are not very good at remembering IP addresses. Computers are. Humans were not. I know I'm not. And IP addresses change. Change with regularity. Today's problem, the internet is becoming complex, and we try to optimize things, so the complexities, we want those to remain hidden from users to make it easier. But we have IP addresses that can be shared among multiple names as well as names that actually span multiple IP addresses. So all these problems contribute to why we want to do DNS. The next slide, please.
So the domain name system is this hierarchy layout of essentially databases, or we call them zones. And the typical transaction that you do with DNS is use a name to look up an IP address. There we have on the right-side example. And we will contact a name server and get their response of the IP address. Now IP address is one of many things that DNS stores. For example, where we find our email server mappings, that's how we can discover where email servers are. There's reverse mappings, we can look at ticket IP address and look up the associated name. There's other service and security parameters that are built into this name space as well that DNS provides this globally distributed, coherent, and scalable database. Each zone in the horizontal plains, they're very independent. Independent in administration as well as operations. So each zone is only responsible for the content within that as well as delegating to sub-zones. For the top level, that's second level, and third level, pretty much arbitrary number of levels.
So we see here the top of this all is the root. That's how we boot strap, we start ourselves into this name space. So the root is very important in order to find anything within the DNS name space. And we can go to the next slide.
A few definitions here. The root server system is the collective set of root servers. This is the technical service; this is what the computers on the internet that you can ask a question to, and it will respond with an answer. The root zone is the information that sits at the top of the DNS hierarchy. It has no parent zone, and it contains the information, just the information necessary to discover those top-level domains, those things underneath it. That's it. And a root server operator, these are the organization, there are 12 different root server operator, 12 different organizations that are responsible for managing the computers which provide this lookup service. Next slide, please.
So again the differences between the root zone and root server system, the root zone is more the information that's that database. It's managed by ICANN. Global contributions to policy and a way of maintaining that. That information is provided to the root servers.
The root server system is the technical side of delivering that content. We respond to questions from NRI on the internet with data that's in that root zone. There are 13 different root server identities, each one having two addresses. IP version four and version six. So the root server system is purely technical. And the operators are the ones that are responsible for that. Next slide.
So we'll go through quickly here the domain resolution process. I'm going to focus on how the root servers are involved. So there on the right side, we have an internet user. This is you that you're using your mobile device, your laptop, your smart refrigerator talking to your smart toaster. Anything, pretty much any computer on the internet can take on this role a user that uses information in the DNS. Now that user does not contact the root name servers directly. They go via a recursive name server. It's configured generally when you attach to a wi-fi or configure your computer automatically. You will have several available to you.
So when you want to ask a question, let's say you're looking for the address of www.example.com, your device is going to contact the recursive name server. At that point, it is going through the name space starting at the root asking these questions. Now when it asks the root for the address ofwww.example.com, the root doesn't know. It will only give you a reference to the dot com server. And that process completes, the answer goes back to the user.
Now a couple of neat properties here, that recursive name server is going to remember the responses to each example and it's going to cache them for a certain lifetime. So if you again ask for an address that's in the dot com domain, the recursive name server already has the answer to the root. We do not need to go back to the root to ask the question again. Because the answer it got previously is valid typically for 48 hours.
The other scaling factor here is that this recursive name server is going to be used by 10s, hundreds, thousands, maybe even millions of different users such that caching mechanism really builds up efficiently. And the chance of when you actually ask your recursive name server for any particular address, there's a pretty good chance that somebody has done that, and it can answer from its cache. So it becomes efficient.
So the root name servers are critical to the name space but are not necessarily involved in every transaction. Next slide, please.
So the root servers, the root zone only contains information about those top-level domains, like the dot com, dot org, the only thing the root server can answer are references to the top-level domain. Again, about two days is the typical lifetime of those answers. After two days, you should and question. Next slide.
So refinements, the DNS has been around for over 30 years. Over those years, some very important refinements have been made. DNS security extensions allow us to sign the data within the zones. This significantly reduces the risk of spoofing or somebody giving you an answer that they're not authorized to give you. Signatures can be validated. This happens at the recursive name server.
More recently is privacy enhancements. DNS was not originally designed with privacy in mind. So these newer protocols are well deployed now to essentially protect the privacy of end-users going to the recursive as well as recursive to other name servers. So this is ongoing. This is being deployed and even further developed these days. So DNS server TLS, query name are good protocols that can be used for privacy. And we'll talk about Anycast, I believe here. This allows us to have multiple computers, multiple servers that actually respond on the same IP address. Improving resiliency, latency, and gives protection against denial-of-service attacks.
So real quick, Unicast versus Anycast.
Unicast is a single source and a single destination computer. This is what we typically think of when we're talking maybe internet computers or phones or things like that. Anycast is the case where we have multiple instances of the service with identical information such that the user can actually go to any one of the potential computers that are implementing this IP address. So typically the information is made by the routing infrastructure of the internet. And the infrastructure will typically choose the closest or most efficient path to get to that IP address. Next slide.
And we see here an example of Unicast. And with Anycast, we have multiple destinations. And that path is chosen by the routing infrastructure of the internet to find usually the closest destination but also gives us the ability to let's say if the destination needs to be taken down for maintenance, packets will be rerouted to an available instance. And because we have multiple destinations and multiple paths to those destinations, we have significantly increased capacity. And that helps us in denial-of-service attack situations where we have the additional capacity to absorb some of that traffic.
And that is it for the background. If are any question, we can take those. If not, we can go to the root server system today.
>> Thank you. I suggest we try to take questions at the end of the presentation. So hello. My name is Lars-Johan Liman. We are based in Sweden, and we operate one of the root server identities. So how did we end up with the system that we have? I'll give you history how we came to the place where we are.
So next slide, please.
The root server system is as old as the DNS because it's a vital part of the system. So back in 1983 when the DNS was invented, instantly need for root servers. Now the internet back in 1983 wasn't anything like what we have today. So only four machines actually acted as root servers back in 1983. Then over time as you see the number has increased. Three were added. In 1987 we were up to seven. In 1991, up to eight. That was when the server that we operate in Sweden was add. And in 1993, sorry -- hmm. Yes. '93, up to nine addresses. And then again in 1998, four more were added. Now this slow increase in numbers here was based on the network, how it was -- where it was deployed. But also at the end limited by a size limitation of the DNS packets. We want to be able to reply with a set of all name servers in one packet. And there were limitations in place back then in the 1990s that made it'd possible to list only 13 addresses.
Those limitations have been slowly removed, but another important part of it was that the process for adding and removing root name servers, it more or less died with person. Back in the day, the entire system was handled by a person called John. And he died suddenly. And there was suddenly no process for adding and removing root name servers.
So we had to do something else. We couldn't have just 13 server machines on the internet back in the year 2000. Because by then, the system had grown quite rapidly. And we introduced in 2003 the Anycast system that Ken mentioned and. By using that, we could start to increase the number of servers so. We still have only 13 identities, but we now have 26 IP addresses because we have both v4 and v6, so two times 13. And we also have Anycast which gives us the ability to deploy lots and lots of servers using 26 IP addresses. So we are well over 1,000 actual servers. Serving this system. Operated by 12 operators but a thousand machines.
This is the list of the 13 identities. And you see for each of them, the exact IP address from which we serve the root service. And you can see who is the responsible operator for that identity. And you will find on the list down there where we operate. Next slide.
This say picture can from as you see at the bottom, the website root-servers.org which is a collaboration between all the operator where is we try to provide information about the root service system as a whole. Now the root server operators are independent of each other. We don't have any common business arrangements between us. But we do collaborate on the technical side very closely. So it doesn't matter whether you get your information from an H root, or I root because it's all the same because it's all the same and we are well coordinated to provide this information to you, so you basically won't be able to tell whether it came from one or the other. And the content is identical. We use the same data. There's no exception from that rule.
So this is a map that is clickable on the website. So you can drill down into this to see where the root servers are located. And this is a zoomed-out picture where you can see there are 250 root servers in the European region. 72 in western Africa and so on. If you double-click on these, you can get down to city level and see which identities are deployed in which cities. Next slide, please.
So the root server operators operate server machines that provide service and the data that we provide is the root zone. The root zone is provided to us through a chain of -- through a process where the data in the root zone is actually data that pertains to the top-level domains. So we have as Ken described, we have the pointers to where the various top-level domains are located and can be queried for information.
So the content of the root zone is actually provided to the entire system by the top-level domain operators. They send in change requests to have the data changed and that's done, the processing of these requests is done by the internet assigned numbers -- internet assigned numbers authority.
Affiliate of ICANN. And they'll process and do due diligence on the change requests to make sure that it's legitimate. And then they'll send the request to the root zone maintainer. That is the company which operates under contract. And they'll do the mechanical chores of generating a new content in the root zone and generating new file which contains these changes. And they'll make the root zone file available to the 12 roots server operators, one of them is themselves but provided in the same way to all 12 of us. So they'll pick out the database, essentially a small database, and we pick it up and we each distribute within our set of servers. So net node will pick up the zone file. The same zone file as the other operators. We will distribute that to all the instances that we operate. And we will make sure that our server provides the correct data to the DNS resolvers. So the blue square in the middle, that's the job of the root server operators. As you can see, the DNS client on the right-hand side, and you can see the TLD operators that puts in change requests on the left-hand side. Next slide, please.
So who are the root server operators? These are 12 different professional engineering groups. We are as I said, we don't have any direct ties between us. We don't have any contracts. But we have very dedicated engineering resources to keep the system running. And if you talk to any root server operator, you will find that the first and foremost thing that he or she will stress is the reliability and stability of the service. To us, this must be up. This must work. And we are also concerned with accessibility for all internet users. So we really try very hard to make our service accessible for everyone on the internet.
And we do so by providing equal service to each and every one. We are not limiting the service in certain areas or certain regions or certain operators or anything. Any query that comes into a root server is equal and treated equally.
We do cooperate technically, as I said. I'm very well acquainted with all the other operators at all the other root server operators. And we do cooperate closely. We have regular meetings where we discuss the technical problems that may arise and look at threats and systems and also at the performance of the system that we have sufficient resources in place to provide good service to everyone. So this is really a group of very dedicated experts on DNS provisioning, and I would argue that they are all professional. It's always a joy to meet these people.
The organizations behind the root server operators are all so very different. They all have technical expertise at the high level for providing these services but organizationally, we are quite different. Net node for instance is a small commercial company in Sweden whereas other organizations are, for instance, universities or government organizations or not-for-profit companies. So in the organization governance, we are quite different. And that's actually a good idea. We're also geographically spread somewhat at least. A number are operated from inside the U.S., but we also have roots server operators based in The Netherlands, Japan, and Sweden. And we also have very different funding models. Now all of these differences, and we also make different technical decisions. We don't run the same operating systems on the servers. We have different software for providing the service, but the service that you receive on the network is always the same.
Now all these things tie into the server operator which is diversity is good. The diversity is our way to protect the system against single points of failure. If we were all business companies, commercial companies, there could be some kind of condition where commercial companies are prohibited to provide a service. But that can't happen now because some are universities, and they are governed in different ways which means that they are safe from the threats of a commercial company. And again, agree graphic spread means if there's a law passed in one country that makes something difficult, it's not passed in the other countries, so we have this diversity which makes the system, very, very strong. And also the funding models. There's not a single source of money that controls the system because money is often tied to control. And we have totally different funding models for how to provide the money needed to operate the system. So if one source of money dries out, there are still plenty of others to choose from. Which are chosen by other operators.
And it's also known that if one of the root server operators were to be forced to stop operation, you wouldn't notice because the system is so overprovisioned that taking out an entire operator instance is not going to have any major impact on the service at all. Next slide, please.
We are involved with careful operation and evolution of the service. We need to stay in tune with what's going on in the DNS field. Because there are technical involvements. DNS was added. These are things that added. We are never the first and early adopters because we want our systems to be stable. That's the primary goal that we have. But we need to stay in tune with what's going on.
So we are carefully evaluate and deploy suggested modifications. We carefully what's going on in the ITEF. And we make every effort to ensure that the system is table and robust. That is our prime target.
The root server operators try carefully to stay out of the policymaking related to root server. We don't care what's in the root server. That's not our business. That's the business of ICANN and to some extent IANA. And we don't change the data. We run the book shop. We don't write the books. We run the book shop where you can buy the book. But we don't care what's in the book.
So we really, really do not modify data in any way. And you can test our systems from NRI, and you will see that we don't change the data in any way. And regardless of which root server operator you send your query to, you will get exactly the same answer.
Next slide, please.
We coordinate between operators. We do attend various industry meetings and bodies. ICANN, we are operating the separate called the root server system committee. We attend the standards meetings and various meetings regarding operations of the internet. For various regions. We try to participate as best we can. And there's also a DNS focus group called OARC which focuses on operations in the global arena.
We have diverse communication tools. Of course, email but we also have phone bridges that are on stand-by. We sometimes use video calls if we have to. And we do share a lot of data. Regarding the operations. You know, query rates and if we have any type of attack, that's immediately shared between the root server operators. And we even do various types of tests to our emergency response capabilities. We have the bridges which are tested regularly, the phone bridges and we conduct training exercises between ourselves to say what would we do if and then we have a scenario that someone has thought out. And we try to invest that scenario in tabletop exercises and so on. Next slide, please.
The root server system committee is an advisory committee to the board and the internet in general. And we issue documents there. One of the documents is a statement from the root server operators regarding the root server system. And that is what I mentioned before, that is the reliability of the data received from the root servers. Here again these are talking points that I mentioned already. Every instance, all the more than 1,000 machines serves exactly the same data. And the data originates from the IANA through that process that I described. And it's made available to us by root zone maintainer.
The system is a hierarchy with a single globally unique root. That's very important. We believe that the DNS should be a global system that looks the same regardless from where you look at it. And all kinds of treated equally by the system DNS sec is the only med you can use to verify the data you receive from a DNS server, regardless of which server, be it root or even an enterprise server. If the data is not signed, you cannot really, really trust it. But if it's signed using DNS sec security editions, make sure it's at least the same data that the appropriate entity put in the server at the other end. It hasn't been modified in transit on the network. Next slide, please.
There are a number of myths going around regarding root servers. One of is that the root server control where the internet traffic goes. That's not true. We are the phone book of the internet. We do not have carry the phone conversations. So the traffic on the internet is handled by routers. And that's how the traffic is funneled through the various channels on the internet between the service and clients. The root service system only tells you which server to talk to and where it's located more or less.
Another myth is most queries are handled by root servers. That's not true. Most queries are not handled by root servers because there are these recursive servers in the middle that actually take query fast bulk of the queries. Remember they have a cache. They'll remember everything you have ever asked it for a certain time. And it relies heavily on the cache. So it can most often can respond directly from its own memory which means that the root servers don't have to be contacted.
Now we have administration of the root zone and provisioning are the same thing. They are not. The administration of the zone is handled by IANA, and root zone maintain. And that's a separate process. And the policy is set by ICANN. The root zone provisioning the handled by the root zone operator but by then, the content has been set by the root zone maintainer and IANA. So we only serve what's handed down to us from the administration process.
Another myth is that the identifiers have special meaning. They don't. It is not different from b; the letter is just an index. We need to be able to distinguish them from each other to find the different IP addresses. But the letter has no meaning whatsoever. And A root is not special in any way, it just happens to be the first letter of the alphabet.
Some say there are only 13 root servers. That is no longer the case. It was the case up until roughly the year 2003, but that's almost 20 years ago now and today we have more than a thousand globally. But only 13 identifiers. So that's where people mix things up.
This also root serve operators conduct operations independently. Well, we don't have any formal agreements between ourselves, but we don't do operations independently in the sense that we don't talk to each other. The collective root server operators coordinate very well and carefully and often and friendly. So this is one system operated by 12 co-operating and collaborating members. It's not 12 different systems.
It's also said the root serve operators only receive the TLD portion of the query. That is not 100% false but it's something that's changing here over time. Typically the root server operators will receive the entire name, domain name that the client is asking for when a query actually passes up to the root server. But from that, the root server will derive, it will find out which top-level doe main name is located in. And it will send the correct referral, the correct pointer to that domain. That is slowly changing so. With modern technology, it happens that the root servers only receive the TLD portion of the query so, that's in slow and gradual change. It's not significant for the response from the root server. It responds with the same thing regardless. It does play a bit of a role when it comes to integrity because the root server can no longer see which actual domain name further down the chain the client is looking for.
next slide, please.
So this is where we hoped that our colleague Fred would have joined us. I'm trying to find out, yes, Fred, you are here. Excellent. I will hand over to you, then.
>> FRED BAKER: Thank you very much. I am with one of the root server operator, happen to be internet consortium which is a nonprofit located in the United States. And currently I am the Chair of the Root server system advisory committee. So next slide, please. As mentioned, we are a bunch of delegates from the different root server operators that convene to advise the ICANN committee and the board on matters related to what we're doing here. This really is a very narrow scope. We get a lot of questions, what do you think if we add some particular TLD or if we do something of a certain type in ICANN? And we kind of say, well, that's not the operation of the network. That's not what we do. So next slide, please.
We produce advice which are documents. And you recall find them, you can look in your browser and RS sac and then a two-digit number and we'll give you a list of the documents that we have produced. They include our operational procedures. They include ways that we measure the system. The way that we pressure service. Governance proposals and so on and so forth. So the root server operators as a group are not represented inside the -- are respected inside the RS sac but it doesn't involve itself in the operational matters. That's handled by the root server operators themselves. So next slide.
So we have representatives of the root server operators of which the three of us are alternates to those, various liaisons that come from different organizations. And we have a larger body, roughly 100 people, that we call the RS sac caucus which is subject matter experts of various kinds that have expressed interest in the operation of the network. And the things that it does. So next slide.
And I'm that guy on the left. Next slide.
In the caucus, well, we have about 100 technical experts. We have statements of interest from them online and give them public credit for individual work that they do. And the idea is even though we operate the network, believe it or not, we don't know everything. So we try to involve people that are interested in that. And are technically capable. So if you would like to join the group, please drop an email to our membership. Next slide.
So to identify that transparency, you can find our documents and our descriptions at rssac.icann.org. The root operators are at root-servers.org. You'll find in each place -- oh, and you'll find in each place a list of our agendas and minutes and so on and so forth.
We have various public meetings. Meetings at ICANN, should ICANN actually meet face-to-face, are open. We invite visitors. We don't invite them to join in the meeting because we're trying to get something done, but they're welcome to sit in and observe. We also meet with other ICANN community group, perform tutorials, which this that the three of us are doing is an example. We have relationships. And if you look, you'll find out about how we operate. We can answer questions about the way the root server operates. And obviously do that. And so you can send a question to [email protected] and we try to respond. Next slide.
So now the evolution in I think 2014, the chairman of ICANN came to the root server operators and said, well, you guys are here and that's great. But how do we add a new root server? How do we -- suppose somebody acted up, how would we remove a root server? We don't have a process because John died. We need a mechanism to carry that out. How do we do that? So we have been working for the last several years to describe a process by which ICANN can add root server operators and provide the facilities that are needed. Next slide.
So we started really in 2014 but that culminated, that process culminated in a document called 37. Which describes what I'm about to go through which is the evolution of the governance of the system. And we've gone through several steps in between times. Trying to flesh that out. The thing that we observed was we're a bunch of techies. So there are parts of this that are really not our expertise. So we invited the ICANN community to look in and provide that expertise as needed. That has happened over the last cup of years. Through a group called the governance working group. The root server system governance working group which includes people from throughout the community. And they kind of started putting together a proposal. And we stopped and said we would like to look at the proposal. So we froze that process for, I think, a period of five months. And then published a document recently called RS sac58 which gives an idea of how we think that one might tell whether the governance working group has accomplished its job. And whether the system design has been agreed to by all parties. And we just restarted the GWG process with the publication of RS sac58. So that's brought you up to current time. Next slide.
So it says a little bit about what we think is important. And he mentioned this, that if there's any one thing that's really important, the system has to exist, and it has to work. And it has to be identical throughout the world. So we've seen some people that are, some sets of people that have decided they want to have their own. And I guess I can't stop them. But that doesn't necessarily help in getting a system that operates equally everywhere. So we proposed a governance model for the root server system and its operators. And went through and kind of said, what would happen if something happened and how would we determine whether the system is actually operating correctly, how would be correct it if it was wrong? And as really as a test of the design. And of course, in looking at that, we found something, oops, that wasn't quite right. But RSSAC37 tries to describe a proposed system and test whether it works. Next slide.
These are six of the 11 principles. I'll get to the next five on the next slide. But key points to us, if you want to be able to trust a name that it will get you to someone, whether that someone is a particular ministry within your favorite country or a particular company, a particular service, then the internet requires a name space that is globally unique, and which is in fact contains all that information.
The purpose of the internet assigned number authority is to provide that root data. And so they do that. And we have to be, we have to provide a stable, reliant, and resilient platform for all users. With the same data. Which Liman went into in some detail. Now I think Ken mentioned that we really tried to operate the systems in different ways. We have different operating systems, different software that is used to operate the DNS network. We do things, we use different hardware. Why do we do that? We figure that if there's any one thing that can take the system down, someone will try to take it down. And so we do things in different ways in order to make it harder to take the system down.
We obviously watch the r the IETF very closely and deploy the things that they say to deploy, but when we see architectural change, we do that because there's a need in the system for that to happen. Next slide, please.
Now for us, this is more than something nice thaw post on the wall and forget. This is something that has to be true with every operator, with every piece of equipment, with every bit of software out there. And the system just has to work and has to operate in an appropriate way. So this becomes really an ethic that's built into each of the people that works for the various root server operators. We must be transparent. We talk to each other. And we engage with stakeholder communities which ICANN is one of but not all of. But at the same time, have to be autonomous and independent. Why do we want to do that? Well, let's imagine for fun that all the RSOS were operated by the same company. Well the company could now make or one country or one anybody, the RSOS would then be captive to them. And that country could say, you know, we don't like some other country, take it out of the name system. And we would all have to do that. Well, so we operate in different companies and different countries specifically to limit that possibility. And as a result, if you think of pipes and water, we're the pipe. We have to be impartial, to not look at or change the data that's going through.
So next slide, please.
We made a number of recommendations. We recommended that the ICANN board initiate a process of which the GWG is the reason the GWG exist. To produce a final version of the model, estimate the cost and figure out how to fund them. And then implement the final version of the model based on the principles that I just discussed. Sew that remains in process at this point. I expect that it will be done this coming year. I can't really give you a detailed thing because we don't know that.
As I mentioned, the GWG started to come up with a different approach to things. So one of our questions, one of the root server operator community’s questions was, how do we decide between the models that have been proposed and. So we published a document called 58 which lists what we consider to be important characteristics that you would use to identify whether the proposal actually worked. And with that build a framework to assess the different proposals. And the operation of the system as it goes forward.
And then in RSSAC359 we made recommendations to the ICANN board as to what they should in order to accomplish that. Next slide, please.
This is a picture of the RSSAC37 model. ICANN defines a stakeholder as someone that is affected by the actions of an entity, so the stakeholders of the root server system include obviously the RSOS but also the IETF and the IFB and the various members of the ICANN community. Which includes, for example, the TLD operators, the general TLD operators, the governments have an advisory committee that they populate. And so on. So different portions of the ICANN community are each affected by how the DNS operates. And we consider them to be stakeholders.
The proposed organization of the root server system includes some things that are kind of obvious but can probably be done by a small group of people such as the financial function performance monitoring measurement function. But one that is fairly wide and includes input from the root server operators and from DNS and various other places which we call the strategy architecture and policy function, and obviously we have somebody that has to pick up a pen and carry things, own the technical equipment that is common to the root server system and so on. That's the Secretariat.
Those are the different parts of the proposed organization. RSOS talk to the Secretariat and then operate as said over a thousand instances of systems all over everywhere. We develop various performance metrics. If you go to website look under at the bottom of the page, you'll find a list of the different root server operators and some links to information that they maintain. And part of that is PML files of how many requests we've received, how many we've responded to and so on and so forth. There's data, starting in the case of operators as early as 2013. At this point, we have data from all of the operators.
And then the strategy are the architecture and policy function. Hello? Oh. Okay. My web browser just decides to inform me of something. Okay.
Is our process right now, we're working with the government's working group. It's composed of representatives from various and different places and tasked with working out the details of the model. And is busily working on the things that I've discussed. Next slide, please.
So if you want more information about us, you can go to the ICANN web page or the RSSAC web page maintained at ICANN, look at our FAQ. And you can and questions. For more information on the caucus, you can look at the corresponding page for the caucus itself and apply for membership.
Do we have one more slide?
>> DAVID HUBERMAN: Nope, that's it. And the next meeting is getting ready to start.
>> FRED BAKER: Okay, so thank you.
>> DAVID HUBERMAN: Thank you, everybody.