The session commenced at 9 a.m.

CHAIR: Good morning everyone, or someone at least. I don't count too many heads. Good morning, this is the second session of the DNS Working Group at RIPE 58. My name is still Peter.

Some administrative trivia to start with. For those of you probably not present here yesterday, the DNS Working Group has a home page which is listed here. .CZ do have a mailing list. I won't repeat this completely. You see two ways to access the mailing list and get on there. Again today, there will be on‑line support for remote participation done by Wolfgang on the Jabber channel. Do we have remote participation today as well?

Wolfgang: Yeah. I think only one ‑‑

CHAIR: Okay. So anyway, good morning there in Jabber land as well. For the benefit of the minute taker and also for the benefit of the people in the room and the remote participants, if you would like to make any comments which you are encouraged to after the presentations, please go to the microphones in the aisles, state your name and your affiliation, if you so desire.

Which brings us to another overview of today's agenda. We will start with another report from the RIPE NCC given by Anand who I just saw sneaking into the room there on the Reverse Tree Lame Reports and the experiences the RIPE NCC can report right here. After that, Patrik will give an overview of the open DNSSEC software followed by another presentation by Matthjis Mekking about the Outer Trust software. Joe will present some results from a survey on pre‑delegation services TOD registries. Johan will present his thoughts on route zone scaling. We will have a follow‑up discussion for the two Plenary presentations that touched the DNS, the one by Olaf regarding trust anchor repositories and the other one by Eric Osterweil regarding the path issues.

We have one follow‑up item from yesterday that was action item 58.1 and if we are lucky, or unlucky, however you see that, we will have additional action items today, we will summarise them at the end. We might have another 30 seconds or so for any other business. Any questions or suggestions regarding the agenda?

Okay. Anyone awake anyway?

Okay. Then I'd like to ask Anand to come to the stage and present about these reverse stuff and we'll have some discussion afterward, I guess.

Anand: Good morning everyone. My name is Anand Buddhev, the DNS manager at the RIPE NCC, and I am going to give you a brief report about the lameness checks that we have been running for a while now. First a little bit of history:

We, as in the RIPE NCC, received a request from the DNS Working Group and our community to do lameness checks in the Reverse Tree and this was way back in 2006, so in January 2007 the RIPE NCC produced a document, RIPE 400, and this document laid out ‑‑ I can see Brett smiling because he was the author,. This document laid out a plan for what we would do and how we would do it, and in this document, there is a definition of 'lameness'. There are, you know, various ways of looking at it, but the RIPE NCC defined a specific way of measuring lameness.

And a high level description of the process which we would use to do these lameness measurements.

In the latter half of 2007, we began a process, we start writing software to actually do these measurements. So some details about the actual measurements.

They are done from a server located in the RIPE NCC network. What happens is that at the beginning of the month on the first day of the month, the software takes a snapshot of all the very verse delegations that it can see.

After that, it goes away and resolves every name server into its IPv4 and IPv6 addresses. If there are any delays, then this is repeated until it can either find an answer or get back an NX domain.

And, after that, every IP address that the software has discovered is queried. It send a query for an SOA record and it makes several attempts to find an answer.

The query is done over UDP and is non‑recursive.

So what are the responses that we expect? First of all we check to see if the server responds at all. In many cases they don't. We also check to see that the response comes from the same IP address that we send the query to. The response code has to be no error. The response must have the authoritative bit set. And that the answer contains the name zone that we sent in the query. And that only one SOA record is returned. We sometimes see more than one SOA record coming back.

So, a lack of response or non‑compliance with any of these conditions is regarded as an error condition we flag this as a lame delegation.

So, some results from the measurements that we have been doing so far: We found that before we started taking any action, there was about 6 percent of lame delegations in all the reverse zones. This graph is interesting. You see some strange peaks there. We found that there was an IPv6‑related bug in our software and that was fixed in September 2008, and so you see a drop in the black line that runs through the graph. The black line is a percentage of the amount of lameness. So, after fixing this bug, we found that things were stable and it was about 6 percent.

There is also a little peak in February 2009. We had some measurement problems. We had some human problems. And that was the cause of this little peak. So that's anomalous.

You can see that if you look at the end for April 2009, there is a slight drop in lameness and that's actually a result of the alerts that we have been sending out.

So, after we began doing the measurements, or plan was to move on to e‑mail alerts and that's phase 2, so what our software does is build a database of all the e‑mail contacts and it does that by, first, looking in the R name field of the SOA record. It also looks in the RIPE database. It looks at domain objects and it looks at the notify and maintained by attributes and it picks out e‑mail addresses from there.

At the end of every measurements cycle, we generate e‑mail alerts to all those e‑mail addresses that are associated with lame delegations.

We send out the e‑mails with unique envelope senders, so that we can also capture bounces quite easily, and get an idea of how much addresses are failing.

We began with a test run in September 2008. We sent e‑mail alerts to a small number of people. We got some feedback from that we fixed a couple of little problems there. We began full scale alerts in February of 2009.

In February, we sent out 6695 messages, just over 1,200 of them bounced back.

In March we sent out 4173, so considerably fewer messages, 937 of them bounced.

And there was an observable effect in the lameness ‑‑ it went to just about 5 percent.

So our e‑mail alerts have had an effect on users. We got mixed responses, which is not completely surprising. Some people silently went and fixed their setups and their configurations and lameness went away. A few people actually wrote back and said thank you, we didn't realise that things were broken we fixed them. Some people weren't quite sure why they had received these alerts, even though they weren't actually operating any zones. And a few people were quite annoyed. So they wrote back to us or raised discussions on the DNS Working Group mailing list and made their opinions quite clear.

So, we have become aware of a number of issues in this measurement. At the moment, there is no record of the date and time of the probes. So, we have no way of letting the End User know when a particular probe had failed.

A fixed time‑out of 3 seconds is used for all the queries for SOA records. We think that this should probably be flexible, should probably be increased for failed queries. The measurements are all done from a single server at the RIPE NCC, so we have no other server out there on the Internet doing measurements so we don't have a second opinion, and probabilities within the RIPE NCC network may skew the results.

And we have been improving our documentation we think that we can improve it further still and give even more details about the probes, the measurements we are doing so that people have a good idea of what's going on.

Problems and issues with the e‑mail alerts. At the moment the e‑mail address lookup algorithm uses the maintained by and the updates attributes in the domain objects and that's not quite ideal.

We don't have an opt out facility yet. I think some people might like that.

We think that the alert frequency is probably a bit too high. We send out alerts every month and some people have said it's starting to look spammy. So, perhaps once ever three months might be more appropriate. But we haven't decided on that yet.

And when we send out alerts and people fix their setups, they don't have a tool that they can use at the RIPE NCC to check whether their delegation is still okay or broken.

So what do we want to do in the future? We think that this service is quite useful to many people despite the teething problems we have had and we would very much like to continue running this.

We have received several ideas and suggestions and would like to incorporate them into our code and into our procedures. And we have recently published a technical document on our website describing more details about the actual probes that we do and how they run. We think we can improve upon that even further.

At the moment, the DNS department handles all the tickets, related tickets that come in, but we think we can hand this over to our Customer Services Department and they should be able to deal with the sort of FAQ, or frequently asked questions, that come in.

And that's it. I am happy to take questions.

CHAIR: Thank you, Anand.

AUDIENCE SPEAKER: Is the e‑mail template you are sending out, is it somewhere available to have a look on that? The reason I am asking is we are getting quite some requests from our customers on behalf of, because of a similar e‑mail sent out by ARIN in the US, and the customers don't understand, or some customers at least don't understand what's it about and we have to take them what is DNS delegation and how it works. So I would be interesting to have a look on the e‑mail just to see how it looks like and it seems to be that RIPE is doing it better because we haven't seen any request from our customers about the RIPE e‑mails, but that might come in the future.

SPEAKER: The template is not available at the moment, but I am happy to make it available to you.

AUDIENCE SPEAKER: That would be interesting, yes.

AUDIENCE SPEAKER: You could provoke a ticket of course.

AUDIENCE SPEAKER: Yeah, Brett Kerr, Nominet, you mentioned in your presentation there was no way of being able to check their delegation, could they not use the reverse delegation tool to do the delegation to check the delegation?

SPEAKER: Yes, they can use the reverse delegation on the RIPE NCC website, but the reverse delegation checker doesn't quite do the same checks that this software is doing. So the response that is they get out of it wouldn't quite be the same.

AUDIENCE SPEAKER: Shouldn't those processes be synced together to do the same thing?

SPEAKER: That's a good suggestion and somebody else has mentioned it. I think Peter mentioned it in an e‑mail and we are actually looking at doing something along those lines.

AUDIENCE SPEAKER: Stephane Bortzmeyer from AFNIC. You mentioned that you developed a software specifically for this programme and which is different than the one we can find on website. Why didn't you use one of the existing DNS delegation testing software like DNS check by the, because it would have ‑‑ it's still, it's always better to reuse and reinvent something from scratch. You have already two very good software DNS delegation testing tools.

SPEAKER: That's true, I think when the design team looked at this way back in 2007, they realised that none of the existing tools were quite doing what we wanted to do and so we decided to develop our own software.

AUDIENCE SPEAKER: Could be more specific on what was missing because I am interested in the future development if something is missing.

SPEAKER: I realise that you are probably interested from the view of DNS witness, which we are also aware of. Well, we had the requirement to be able to look up in the RIPE database for e‑mail contacts. That's one of the things that none of the existing tools would do, for example. And that's one of the reasons we actually went and wrote this.

About the queries that it does, there is nothing particularly special, it's a regular query so wasn't really the reason. It wasn't so much DNS related as, you know, whois related. I don't know if that answers your question.

CHAIR: For the sake of time, could we take detailed discussion either to the list or off line, because I would like to ‑‑ thank you.

AUDIENCE SPEAKER: I am happy to take ‑‑ this is Shane Kerr from ISC. I am happy to take detailed discussion to the list but when I did put it on the list I was told to wait till the RIPE meeting we would discuss it here. So...

CHAIR: Well, I was referring to detailed discussion of deficiencies and other testing software.

AUDIENCE SPEAKER: I am going to give some full disclosure before I make a few comments.

Which is that, I think that we spend a lot more time in the DNS community doing delegation checking than is appropriate. I think you know, the beautiful thing about DNS is that once it's delegated, the user who has the delegation is the one who gets the benefit. So they have the responsibility and the ability to make their servers as good as they want. So I think we should be careful in not overdoing it and I think, quite frankly, that this delegation check with all these e‑mails that we are sending, there is a lot of work that's being used here both in RIPE NCC resources and both way more in the tens of thousands of e‑mails that people are receiving, they have to figure out what this do with, or even figure out if they can ignore it or not. So I did raise a question on the list as to whether or not we should consider continuing this activity. And before you respond to that, I'll talk about some of the things we can do before we make that decision.

One is, I think if we had better metrics, can he could have a much better sense of how much this was helping we saw some matrix which I think are actually very weak. We looked at the number of domains, but I don't know if that actually counted. If I have a domain and I have got 5 servers and one of them is Lame and maybe or IPv6 is Lame, you know, that means something different than if I have a server and all of them are Lame, for instance. So, I think we need a little more detail on what exactly this lameness is measuring. And even further, I put forward a proposal for a way we could measure actual impact on users . Since the RIPE NCC is the parent of these domains, before any query gets to the delegated servers, it actually has to go through the RIPE NCC server. So the RIPE NCC could measure all the domains that are ‑‑ well, not a hundred percent, Olaf is doubting my assertions here ‑‑ but it's not a hundred percent but you could get a rough feel for approximately how many users this was actually impacting. Because of caching you can't ever really know and because the RIPE NCC isn't the only, it has secondaries also you can't know, but I think you could get a much better feel for what the actual impact on users of this, of Lame delegation was. It could be way, way worse than we are measuring in which case I would actually support more effort in this activity. These 60 percent of servers, could cause 25 percent of queries to be timed out and retried or it could be way, way better than that. It could be that these 6 percent of servers only get hit by one in a thousand queries, in which case we can be done and go home for the day.

I would suggest before the RIPE NCC spend any more time improving the service, we should actually decide whether or not this is something we want to do based on some real metrics, so...

SPEAKER: Thanks for your comments, Shane.

AUDIENCE SPEAKER: Nice diatribe thank you. Bill manning. The DNS is designed to be accommodating with [] bit rod. There is not a strict coherence requirement in the DNS. It's loosely coherent. And if you turn ‑‑ so, having things [] Lame for a while or temporarily or even for a long time, really impacts the child who is going Lame or has gone Lame. And the parent sort of gets a little, you know, irritated about it, but if you spend lots of time calling all of your children and knocking on their doors and letting them know that you think that something is wrong, may turn around and tell you yeah we know something is wrong, go away, it's none of your business, your option at that point is to remove the delegation.

People get the chance, or the choice because of the hierarchal nature of the DNS to run their delegations they way they want to. Conversely, if you are so, can I use this word, fascist about chases down you known is Lame delegations would you feel comfortable if the RIPE NCC members and everybody else who happens to touch something in the outer space, the fact that the RIPE NCC is doing something wrong, that's a lot of e‑mail, right. So I don't think that you really need ‑‑ that we really need to be this sterile in trying to keep the DNS tightly coherent.

SPEAKER: Why not? I mean, if we just leave things as they are, they will ‑‑ you know, there will be no improvement. This way, at least ‑‑

AUDIENCE SPEAKER: How do you define improvement?

SPEAKER: Improvement as in, you know, if there is breakage and people aren't aware of it, they can fix it. There are some people who choose to ignore us and don't care, which is fine. We are not the police, we are not going to go and remove their delegations. But there are people who do benefit from these checks who, you know, thank us and say yes, this was a useful thing to do and you know, it's benefited them.

AUDIENCE SPEAKER: I simply give a counter example that not everybody is appreciative of the constant harassment.

SPEAKER: Yes. And that's why we mentioned an opt‑out facility so that some people can choose to perhaps not receive messages from us.

CHAIR: I'd like to close the queue after Olaf.

AUDIENCE SPEAKER: I would say that from my experience, most customers are happy to get information about their problems they have with their DNS. And secondly, I read the report on the DSSR that was mentioned yesterday, and there it was said that many people, administrators or decision takers don't know the importance of DNS, and receiving this information that the DNS is broken and can have some impact on their business is important to raise awareness that DNS is important. So, I think this is a good service.

SPEAKER: Thank you.

AUDIENCE SPEAKER: Olaf. The term "Loose coherence" in this context is one that I don't completely grasp. I always understood "loose coherence" in the DNS to mean that if you get an answer in one place and time, and you get an answer in another place and time, you understand why they are the same or why they are different. But that aside, I think I am in support of Shane's idea, investing a lot of energy in something without the actual impact while you have some ways of measuring that impact is probably a bad idea. So measuring ‑‑ trying to measure what the impact could be is a good metric and I think that Shane has a fairly good proposal there.

The other clarification question I wanted to ask, this is purely for the reverse tree.

SPEAKER: Yes, and for the ENUM zone but we don't make that information public.

AUDIENCE SPEAKER: So, with respect to the Reverse Tree, another part of that metric might be what applications are actually affected if you could get a handle on that, what applications are in fact if the Reverse Tree doesn't resolve, is part of how much energy we put into this.

SPEAKER: Okay. Thanks, Olaf.

CHAIR: Thank you. I am in the comfortable situation of trying to make a summary here. First of all, I think the Working Group at one point in time actually approved the proposal by the RIPE NCC or actually tasked the RIPE NCC to go ahead with this and then later saying okay this is all rubbish. That's a bit tough. I mean, the Working Group can change their mind, obviously

AUDIENCE SPEAKER: That's only two persons. If you want everybody ‑‑

CHAIR: Hang on. So that's fine.

AUDIENCE SPEAKER: Don't summarise only on the opinion of two persons.

AUDIENCE SPEAKER: I want to clarify that what I said was not ‑‑ I didn't say this is rubbish. So, no, if somebody interprets that as being rubbish, then ‑‑

AUDIENCE SPEAKER: This was distortion.

CHAIR: I was provoking that. That's not nit picking here. That's my task anyway. So, trying a summary.

We have been hearing some reports or some indication of say annoyance or disturbance caused by these tickets. I would like to do several things here. One there will be an action item from Anand, obviously, which will contain probably continuing evaluating the feedback and then incorporating that in any further action and that is touching upon harvesting the e‑mail addresses and all the other useful feedback that we got here.

The other important thing seems to be impact analysis, if I understand Shane correctly. And the third one should also probably be do some more, and I have no better term than outreach or education here. For anyone interested in what happens if you have too many Lame delegations, there is an interesting RFC, I guess it's 4595, written by our colleagues at Verisign reporting on their experiences at change effects that happen if you too many Lame children. So anyone believing that Lame delegation only affects the child is actually encouraged to read that RFC. So that could be part of an outreach effort.

The last thing I'd like to do is I'd like to get some sense of the room or at least from the awake part, ‑‑ I am sorry ‑‑, what people think about the service, set aside that there might be some rough edges right now and this has just begun a couple of months ago, so we probably should also give the RIPE NCC some learning curve there. So, we are doing ‑‑ I am trying to do something that is stolen from the ITF called humming, which is the last two questions and you can hum loudly or silently or whatever to voice your opinion. So the one question will be: Do we think that this is a useful service and should we continue it but still worked on as we just discussed. That's the first one.

The second one will be: Do we think that this is a service that should be abandoned and the RIPE NCC should not invest any more activity in that?

AUDIENCE SPEAKER: Shane Kerr: Well, basically what my position is that we should stop and think before we decide what we are doing. So I think ‑‑ I would support neither of those actions. I would prefer some analysis before we decide whether it's useful or whether ‑‑ I don't think we can safely answer whether it's useful or not today, so... I don't even propose that the service be stopped. I think continuing as it's running now makes sense because it's basically limited overhead for the way it's running now. Before making any decisions, especially since apparently it's really bad if we change our minds again later, then we should just wait.

AUDIENCE SPEAKER: If you want to get some results, we are doing this since a couple of months for .NL zone as well. We see similar results as RIPE NCC. People saying this is great. We didn't know there were errors we see a significant improvement in the lameness? Our zone and also in a lot of other DNS errors that people were not aware of. So there are results and it is improving and people are happy with it.

Shane: Measured how? If as I indicated before, if you measure this ‑‑ how many servers responded collectly in that's an interesting measure and it's an easy measure to take but I think it's useless in how it affects users, which is I think what the important thing is that we should be worried about. The user experience.

AUDIENCE SPEAKER: We see every error that we measure is going down.

CHAIR: I guess the point here is that what Shane is trying to say, and I need to understand so please correct me, of course there are errors in there and errors might be fixed the question is what impact do these errors actually have because those zones never are queried, the error is there but doesn't have any impact, is that fair?

Shane: That's correct or very rarely query.

CHAIR: Still the question is for Anand and his group, what should they do right now? So continue and improve the performance and quality of these tickets and stuff. Or ‑‑ or suspend any further sending of tickets until some research paper has been published on impact analysis. But we need to get this closed somehow and I'd like to ‑‑

AUDIENCE SPEAKER: Jim Reid: I have to intervene here is another DNS Working Group coach here. Just a question of practicalities here. We are really over our time already. So how we are trying to get this Working Group agenda back on time today is going to be an interesting challenge for us even with a 30‑minute coffee break to fill.

I would like to just unilaterally suggest that we stop this discussion here and now, we don't have any hums on anything. We just send to the RIPE NCC an action item to gather for data analysis to address the point that Shane raised earlier on and to continue doing what they are doing for the time being. There is an ongoing action policy form. So let's see ‑‑ until the Working Group come back with something. I would suggest do some analysis and report on that at the next meeting and I think we should try not continue discussion here. If you want to, by all means do so, but that's just going to make it more difficult to get this Working Group finished before ENUM starts.

CHAIR: Fair enough. Done. Patrik, you are next.

SPEAKER: Hi, I am Patrik Wallstrom. I would like to present our own DNS project. I hope it works now.

I work for .se but the own DNS project is a collaboration between several organisations, it's Nominet, [] N let labs, airy and John Dickinson is helping and out SURFnet. Basically everybody participates because they want to have a good signer for DNSSEC. It's a very good signer. It does nothing else but signs zone files. It takes in unsigned zones and signs it and it send outs an unsigned zone. So it does automatically keep track of keys. The user doesn't have to do anything. So it's a very modularised project so every participant is working on their own little piece of module.

First we have the, what we call KASP is the key and signing policy, which is a policy that is enforced by what we call a KASP enforcer, which does everything it can to enforce the policy it's given as an ‑‑

Then we have the signer is given a number keys zone file and it signs the zones with a configuration sent by the KASP.

And then we have the hardware security modules, which is a hardware device for CRYPT exploration and storing keys in a secure manner.

What we lack currently is the KASP auditor. We have the requirements on it. We would like to have it written by a third party, becaused auditors function is to actually see that the KASP is implemented in the correct way and verify that the zone file is signed the way it is supposed to be without any strange stuff going into it.

We have what we call the input and output adapters, that's the zone files coming in and going out.

We have currently only the file storage going, but we would like to implement AXFR and IFFR dynamic updates and anything you like.

We are also working on the LIBHSM, which is the PKCS 11 functionality. Currently the KASP and the signer implements their own PKCS level support, so it won't abstract that away.

So what is an HSM? It's a device that stores keys in hardware, at least the master key. It has different levels of hardware security. The highest PIPS levels, which is the American security standard doesn't allow even the temperature in the room even to change too much. If it does, then the keys are destroyed. So it depends on the security level you want.

The highest performing devices we have tested generates 14,000 signatures per second so that's fast enough to at least sign our zones I guess.

And when .sc looked at HSMs, a number years ago when we wanted to sign the zone, they were all expensive. Today we use a smart card which is a very slow device, so we want to look into other devices as well. So...

As an alternative to hardwaring device, we developed our own soft HSM which is software implementation of the same thing. Is also had the PKCS 11 support, and it's used to store all the keys on file on the local machine. So you can use that if you want to do development with open DNSSEC or sign a number of really just your regular zones at home or something.

If you don't require the security level of a relation zone.

So the KASP is implementing, among other things, this is the state of keys, it's automatically generates keys if their policy says ‑‑ if the policy says that the zone shall be signed. So, it automatically generates keys for the zone and then it published the keys in the zone file. It uses the keys for signing and it also automatically retires old keys and then removes them. So it depends on the lifetime of the policy on how fast this process is going.

There are a number of other met a data that is contained by the KASP. It's all the timing on the keys then things happen. It keeps track on which HSM the keys are stored in, so it can give that information to the signer. The unique locator ID is used for that. So the signer can patch the keys for signing.

Basically, an ideal command to be implemented for the KASP is just the command to remove key. There is basically no other use for a command to be sent to the KASP. The remove key is basically revoke key or the emergency key rolled into one because what happens then is a new key will be generated because the KASP says that zone should still be signed. So...

We don't have currently a command line interface or goobey defined for the KASP, so we don't know actually right now how it should be maintained.

We have the signer engine, which is developed. It does everything with the RR sets sorting and it. It adds the RS significants and keeps them up to date. That's the basic function of the signer.

So this is the overall architecture. The orange blobs it the configuration files. And then you have the unsigned and signed zones fed to the signer and you have the KASP information ‑‑ the KASP database using the LIBHSM which gives all stuff to the communication which signs the configures for the signer.

So that's the overall view of the architecture.

It's supposed to be very easy to configure this system. Today basically it's like this. You have to have an HSM, so if you want to have an HSM up and running you have to configure the HSM. To configure the soft HSM, you have to initial eyes the token, and add that token to the soft HSM configuration file.

Then you add the soft HSM library in the list of repositories, which is the list of HSMs used in the general conf.xml file. They also say how often the enforcer should be running and how ‑‑ where the signer should look for stuff.

And we have the KASP configuration, which is a long list of policies. This is a short example of the default policy. Which can be used for all zones if you want. And there you have the resign and refreshing towards and for how long signatures should be valid. The length of the keys and all information like that.

So, this is all going to be enforced by KASP . If it fails, it should warn or even stop working.

What we currently have is a list of zones where we actually say where the unsigned zone files, where the signed zone files should be and the output. You have assigned a configuration for that if you have ‑‑ oh, the signer configuration is the configuration file which the KASP outputs. So the signer knows where to read it.

And this is the signer configuration, which the signer use to say sign the zone, which contains the locator of all the keys. So, the purpose of this is you want to roll over a HSM, you can have keys located in another HSM file. So this contains all the information that the signer needs to sign this zone file.

We have lots of things left to do. We wanted to have an Alpha version this week so we have we couldn't postpone RIPE so we have to postpone the Alpha version. We have to integrate all the components to have them working together, all the individual components are working okay by now, but they haven't been integrated. And then we have to have an install guide and user guide to you'lley have users trying this out.

We are currently doing peer reviewing within the project, so we look at each other's components and find out if there is anything wrong with them.

Since it's a very modernised project, we want to make open DNSSEC one package.

We have to do more testing. Test the complete system to see if it can sign a lot of zones or big zones. And we have to do that for a very long time, because .sc and I believe .UK as well will want to use open DNSSEC this year to sign. So we have to do a lot of testing during the summer.

So, this is my two week properly it's, but we want to have a version 1.0 for the IETF in Stockholm.

So everything is documented on website, open DNSSEC .se or .org, or whatever, and we have all the meeting agendas and everything in there, so if you want to look at the source, you can look at it right now if you want to.

So, thank you. Do you have any questions for me?

CHAIR: Anybody any questions?

AUDIENCE SPEAKER: By the way, my neighbour told me it's the same question. Is there anything to allow for dynamic updates signing on the fly, something which just gets and doesn't go through the HSM necessarily I mean.

SPEAKER: Currently there is no such thing but we are planning on having dynamic updates.

AUDIENCE SPEAKER: In that case, is the HSM to be just off the vat or put something just on the signing server so that it gets the key.

SPEAKER: Ideally the HSM will be on line. If you do dynamic updates, then it will have to be on‑line, I guess.

AUDIENCE SPEAKER: Okay. Thank you.

CHAIR: Any other questions? I have a question for you regarding this project then. So this is kind of a prototype thing for how to run DNSSEC in a registry, say. Is there any opportunity for, say, tailoring this to other registry needs tore what is the idea behind that?

SPEAKER: We would really like to have this signing for anybody who wants to use DNSSEC. It should be as easy as possible to use it. We will also, it is a BSD licence as well so anybody can integrate it into their own products. If say for example, ‑‑ want to use if for signing their stuff, that's completely fine. It's designed for that as well.

AUDIENCE SPEAKER: Olaf, of the development partners in this project. The ultimate road map is to have the ultimate DNSSEC signing tool. That is to say a piece of software that you can implement on a little device that becomes your black box to sign DNSSEC with a nice QE in which you can configure with a few lines, with a few clicks, the policies by which you want your zones signed and then you have this box and you either put it in your zone generation process or you put it behind your master server so that it can take ‑‑ it's basically a bump in the wire as we call it. That's the ultimate goal.

What is presented here is a first step. Basically to make sure that the policy engine works; that an important component of the system is that it can work with various types of hardware signer engines and a software emulation of that, so that people can provision their own security needs. The intention is really to make a tool that makes DNSSEC deployment trivial. So that's the ultimate road map.

CHAIR: Okay. Thank you. Stay at the mike, maybe I have a follow‑up question for the both of you then.

It might be a bit premature to ask this right now but for anybody considering using this for their production service, what about project support and stuff, are there any ideas available there or ‑‑ a pointer to some document is fine.

AUDIENCE SPEAKER: I missed the seminal word in this question. Project support you meant?

CHAIR: Yes, project support. So as a commercial entity, trying to rely upon this, who do I send the contract proposal to?

AUDIENCE SPEAKER: Olaf: We are intending, but this is really something that we within the project team needs to finalise, but we are willing to take the software support on our hands. A full 24/7 is a different question I guess. But the way we go forward is first walk and then run.

CHAIR: Oh sure. I said premature.

AUDIENCE SPEAKER: Yeah, the question is a bit premature.

CHAIR: Thanks nonetheless.

AUDIENCE SPEAKER: We are testing open DNSSEC to be integrate with our DNS management tools and then there will be also support for this, commercial support. But it's not decided if it will work with our products. We are testing that now.

AUDIENCE SPEAKER: Just to expand on that, there is a conscious choice tore BSD licence so that commercial entities can pick it up and run with it.

CHAIR: Okay. Thanks very much. I don't see anybody else at the mike, so thank you very much Patrik for the presentation and thanks Olaf and the others.

(Applause)

CHAIR: I guess, Matthjis is next to make an announcement presentation.

SPEAKER: Hi, my name is Matthjis Mekking. I work for NL Netlabs. What is Auto Trust? Is it a tool to automatically maintain your trust anchors. It's an alternative to what's already out there, but I am not going to compare them with that.

Auto Trust follows the guidelines that are described in the RFC 5011, it follows their time, their transition table that's described in there.

It is a resolver independent trust anchor maintainer, that is you can run it next to unbound, you can run it next to bind. Any resolver that is DNSSEC capable. It is highly configurable. It started out as a basic aiding tool, but since I got more questions about it, I have added some useful options, I guess. And it's making use of the L DNS library. Those are DNS function alternatives that I can separate from the algorithms IX I can really focus on the corner cases of the algorithm.

It started out as an aiding tool. The first project at [] L Netlabs, I have got more questions about it so I have added options that are I think are useful in real time situations.

For example you can signal the resolver if the trust anchors are updated. It works with the REVOKED bit not set. There is an option for that. I have added that because I hardly see revoke bits setting key rollovers at the moment. It does accurate active refresh timers. First of all, it was intended to run from the [] /KRUPB job at fixed timers, but you run the risk of missing key rollover if you set the rate of the /KRUPB job too low. So, I have made it demonable so you can run it as a demon, and then it follows the exact timers as described in the RFC.

Version 0.3.1 is coming up. This is how it fits in your world maybe.

If you have a machine where the resolver is running, where the trust anchor files are maintained, you put Auto Trust up there and start up queries for all the DNSKEY R sets which has trust anchors for. Once it sees the need to update the trust anchor file, it does so, and signals the resolver that it should reload them.

There are some small issues. It's not a trust anchor fetcher so you still have the pain of initially setting up your configured trust anchors, but hey, there are public repositories for that now. There is no trust point deletion. It's bit of detailed subject, so if you want to have information about that, I'll be in the hallway.

One issue with the algorithm ‑‑ it doesn't allow for holidays, that means you can put Auto Trust off line for three months and then put it up back again and just assume that everything resolves just fine because in the period you might have missed a key rollover and there is a minor to‑do list. But for that, I guess the tool is ready and if you are interested in attic updater for trust anchors that is resolver independent, you check it out at our website. Please try it and if you have questions or see strange behaviour, give it back to us at our bug /STKPWHREUL a page or mailing list and I will be grateful to accept your feedback.

Thank you.

CHAIR: Thanks very much Matthjis. Questions? Nobody?

Okay. Then again, thanks, Matthjis.

(Applause)

CHAIR: And I think Joao is next on the service of pre‑delegation checks.

Joao Damas: I'll make this short and go straight to the questions I have rather than the report on the survey because the one thing you get clearly back from looking at the different, what different TLDs do for different checks is there is no uniformity at all. There is a wide range of variation. There is those TLDs that just perform syntax checks and some of them are not even correct. They don't have the actual set of character that could be present in a domain name listed as valid characters, but at least some people guess these right.

Some of these syntax checks including additional constraints like ICANN's requirement to not have domains that are two characters or less so that the IDN is not conflicted if they decide to change the labels later.

Some people, for unknown reasons, have reached constraints on dashes. Not underscores, but dashes, they cannot be in their positions. And then there are the more complex complete checks, where name servers are checked themselves. For availability and so on.

So I don't know if the Working Group has anything to say about what they think, about what people here think is a reasonable set of the delegation, of pre‑delegation checks talking about things that happened before the domain is actually put in production. And in particular, what have these were to apply not to your customers, but to you? To TLDs? If you were to going to put a TLD, a new TLD in action, what do you think is a reasonable set of tests that you should perform by the bind zone on your too soon to be, to become live TLD? Do you think that the checks should be full on? That the domains, the name servers should be actually checked for availability? If you are using Anycast servers, should they be checked from more that you know one position? I would like to hear more from the audience on that.

CHAIR: Okay. That's it?

SPEAKER: It's a question time. And the questions this time are being asked by the presenter.

CHAIR: Okay. I think we can just open up the floor for five minutes or so to be right back on schedule. I think Mohsen was first.

AUDIENCE SPEAKER: Mohsen Souissi, we have been running for quite a long time, something called zone check maybe you are familiar with, for pre‑delegation checks and .fr. We used to have some complaints and yeah, expectedly, there were the same people coming again and okay, get off this zone check thing, we are really bored of it. Very recently, we have EPP deployment at AFNIC. Actually we just delayed the zone checking just after the registration with EPP. So, I believe that all those complaints were ‑‑ and by the way, there are only a few of them, so we believe that the technical quality whatever definition of technical quality of ccTLD zone, we believe zone checking or checking delegation, etc., is a very healthy thing. We believe we should continue to do it. And whether the tool is really complete or is up to date with standards is it including DNSSEC or not? Is it including EDNS 0 or TCP, and this is only flavours we can discuss in policy with the stakeholders as we call them, and I mean, the principle in itself, I think it is a very good idea and we are actually working on that we hope that the consistently other TLDs would take those same ‑‑ we are not in a position to teach people to do it, but we believe it is a good thing.

SPEAKER: Okay. I see that. One question: Would this same encouragement to use this tool be apply still if your parent zone were to apply those checks to you? If the root zone ‑‑

AUDIENCE SPEAKER: Mohsen: Actually, I don't mind, we believe, before even adding a name server for .fr or dot RE, versus very aware of that. It happens that we have been mistaken as everybody, I mean, but we believe that principle should be applied at every level and yes ‑‑ and independences of the let's say the autonomous system and we believe it should be applied uniformly. Out there there are too many ccTLDs which are really broken and I don't know whether people running them are aware or not, and those are only basic things. Three name servers on the same subset. And really sub‑net. I mean I believe those checks are to be applied and that's my personal point of view now. Maybe it is too conservative, but in the principle itself, I think it is good quality for the DNS checking. And to just answer the concerns of Olaf, maybe it is not to be applied in the same way for the reverse checking because maybe it is not so essential or critical for the functioning of the Internet. So, I don't have the same statement and the same power of words on that.

CHAIR: Thank you. I am in line after Jim and please let's keep our statements short.

AUDIENCE SPEAKER: That's a good one, I don't know where to begin. First of all I like this initiative. And I agree with Mohsen. We done pre‑delegation checks a long time at .nl as well and we have had complaints as well and the only reason we get complaints because people want to commercially register a domain name and not so much as to have a domain name in place that works. That's the only complaints we get.

As to what do we need to test? I think there is local policy that determines whether or not certain tests are applicable or not. We do pre‑delegation tests because we want to make sure that people that register domain names understand DNS. That's for one thing. So that's local policy I think. And as to the details of the checks, I think there are checks that you can say that should be performed and every time and others are supposed to give a warning say hey, are you sure? Because they think this is a strange value but we don't reject the registration because we think it's completely bogus. You might have proper reasons to do it. But I would be very interested that if a test it performed that the test is performed the same way at every delegation, every TLD. So we don't get you know, complaints from customers saying hey but you do it a different way than .fr does it and dotcom does it. I am interested in for example if you want to test them how do you actually do that the beast way?

The last thing I want to talk about is that pre‑delegation checks are a good thing, it improves the quality, but doing checks on a continuous basis also has some good things, and one of the things I am thinking about is that I remember a couple of years ago deep raise had some problems, apparent registration problems and there were fishing problems. People deleting name servers or zones where name servers were resident in and these domain names were registered by other sort of half criminal organisations just to be able to inject false information into the DNS and do fishing. We have thought about this and the only thing that we can actually do to stop fishing is to continue to see if name servers are still present in the DNS and if not, do something to the demain name server delegated. Customer saying do you know that your name server isn't working any more? You might have an issue if the demain name of deleted and reregistered again. For our own zone we can check by looking into the registry database but when had a foreign name server is used, the only way we can check this is by delegation checks.

CHAIR: Thank you, Johan.

SPEAKER: I am a well known sceptic of too much delegation checking because I think this is clearly within the authority of the child rather than the parent. That said, I am about to change my position here. So I agree there is a point and I agree this is needed. It's clearly not enough to just to outreach and education.

However, in the light of this being a necessary evil, if you like, I am still much more in favour of delegation checks of stuff that's actually running, that is producing actual services that people depend on than I am in favour of pre‑delegation checks. Because my definition before the delegation has been made, no one is really depending on it and therefore I think it's reasonable to give the new delegation, the new child the opportunity to actually getting things right.

So, I think when you get into the pre‑delegation stuff and also for the ongoing delegation checking stuff, it's very, very important to do exactly what Antoine was also talking about, make a distinction between just informative stuff and checks that you'd use to actually fail the delegation. I would want to be very, very, very restrictive with stuff that actually fails the delegation, because that's almost never necessary.

SPEAKER: Yeah. And would that comment apply to all levels of the DNS from the root down?

AUDIENCE SPEAKER: From my perspective I completely agree with Mohsen in that respect. I don't want to see the standardisation because I don't think that's appropriate. But checking as such, is appropriate at all levels.

SPEAKER: Okay. Thank you.

AUDIENCE SPEAKER: Jim Reid representing myself I think more than anything else here. I agree with both what Johan and Antoine was saying. I don't think it's at all possible or practical to have a single set of delegation tests or criteria that can apply all the way from the TLD down to the end most leave node of that domain. You didn't say that, sorry, my apologies.

The problem here is that some TLDs have different local policies or the policies that apply for the TLD itself are applied to the TLD don't necessarily apply to its children, and my specific example here is a situation we had with TELNIC and the .tel TLD. So just personal anecdotes of this might help a little bit here. Whenever we change the delegation for .tel, the sort of thing IANA were checking for was will the response from the root servers fit in a single 512 bit reply and do the name servers line up enough? However in .tel, because it's all to do with NAPTA records and the DNS is the service, there is nothing else there other than DNS, the criteria then applies to the children, the delegated zones are much much stricter and some of the tests that we would apply there were for things you have to speed EDNS 0 because you were going to get a lot of numbers in NAPTA records coming back and it was also from the pre‑delegation points of views, the zones don't get delegated until they are properly set up because at that point they are going to be getting used we want people to look things up and get success of answers without waiting for a probingen main server to come back on line. So the criterias can change depending on local policy and local policies vary from TLD to TLD. If you go back to ccTLDs where I think some of this initial discussions started, you may have other kinds of factors that influence that too. For example, some countries with crazy ideas that... inside that country. So how can you possibly reflect that in a generic delegation checking policy or mechanism. So I think we'll probably end up with a generalised delegation checking model, probably all you can say is do the parent and child agree with the DNS records are for the zone a have the correct addresses for the actual named servers themselves. Anything beyond that I think could become problematical. We have some guides about what we would think would be a reasonable test to apply and what might be the advantages and disadvantages of doing that.

SPEAKER: I like your distinction between whether the DNS is the server itself as opposed to just the way to get the servers.

AUDIENCE SPEAKER: Peter Koch ‑‑ these pre‑delegation checks from the beginning we intend to continue doing so. We are doing this partly to protect our infrastructure and the quality of our services and the service that is we are providing to and with our members and we have the support of the majority of the registrars for this.

For the unification of the tests, I think I just can follow up on what Jim said. Policy setting for ccTLDs is a local matter and there is a variety in the customer base and local experiences and so on and so forth. So it might well make sense to have differences there. Nonetheless, from a technical perspective, the checks should be reasonable and I think our are.

Regarding your question: Checks from the root zone. Policy wise, there is a slight difference seen there. The root zone is, from our perspective, not seen as a registry of the same quality that the TLDs are.

SPEAKER: Would they be lower or higher?

AUDIENCE SPEAKER: Pass.

AUDIENCE SPEAKER: Peter: No, no, no one cares that you measure it against. It's regarding the eligibility for registration. CcTLDs are just there and again, this is local policy matter.

But fun that you mention it. I guess several years ago now there was a consultation actually regarding pre‑delegation checks or redelegation checks for the TLDs to be applied by IANA, many of us has sent input, so Dean I can also sent input there we still stick to that. We haven't heard anything back unfortunately. I would be very interested to see stuff implemented or at least responded to, thank you.

SPEAKER: Just a quick question for you Peter. One of the things I looked at when trying to get the picture of what people did, dns.net's bid from a few years back, there you for instance explained how the the zone is maintained and checked and it is so, why its quality is so high. But you said for dot net, we wouldn't make these checks mandatory, at that time that's the telecommunications. Is it just purely because dot net didn't have anything of the sort, so you were feeling like this was a policy that was inherited or do you think that actually different TLDs have different criteria? Even if you are both, you are running both of them.

Peter: Honestly speaking, I don't remember off the top of my head the details of this. I could, and this is with all caveats applied, this is probably, was probably approached from a purely policy setting perspective and acknowledging the fact that GTLD policy is developed in a completely different way than ccTLD. But I am happy to follow up on that after I have done a bit more research and follow up with you privately.

SPEAKER: Thank you.

AUDIENCE SPEAKER: Joe Abley from ICANN. I was curiously just here to answer your question before you answered it. Kim Davies is not here, he was going to be here but he is not. I don't work in the IANA so I don't have a good answer but I wanted to ask if there is a message I can take back to Kim, is there a general interest in having the IANA pre‑delegation checks made public? If so, I can pass that on?

SPEAKER: Well personally the answer is yes. It's always good to know what's the criteria you are being judged against.

AUDIENCE SPEAKER: And the more basic objection is the IANA does a whole bunch of checks as well as the authorisation checks, but it doesn't make any ongoing checks that's result in communications backs to the zone operators.

CHAIR: That's it. Thank you very much. Thanks, Joao, for raising the issue and preparing the slides.

(Applause) and next is Johan, I guess.

SPEAKER: My name is Johan and I work for autonomica.com we do DNS stuff as most of you know.

The topic today is the root zone and in particular scaling up the root zone. The root zone is a fairly well known zone in the hierarchy. It's at the top. It's been very small and stable for many years and this has all sorts of advantages. It's very easy to distribute a small zone. It's very easy to verify changes to a small zone because the volume changes, well usually is some way proportional to the size of the zone and there is other advantages that are really, really nice to have for this important zone. And as you are all aware, at the end of the day, there is a robustness perspective on DNS in general and this robustness perspective has some sort of tendency of propagating up in the hierarchy. So it's just fine to run your private home zone in a slightly more relaxed manner than a corporate zone, and again a TLD zone is typically managed even more carefully and appropriately. And this sort of propagates all the way up to the root. So I am not disclosing any secrets when I tell you that roots or operators tend to be somewhat cautious and aim for robustness.

That said, there has been a decision to initiate large scale expansion of the DNS root zone. And the new plan is that basically everyone who wants, can get a TLD, as long as they pay for it. And it's also intended to be possible for enterprises to have their own TLDs and as far as I know, there are lots of enterprises out there that might be interested in this.

That said, and before progressing further into this, I should mention that ICANN has commissioned a study of, well the technical implications of this with various degrees of scaling up in various dimensions, as in the number of delegations or changes per time unit or something, so basically, as we speak or at least as I speak, this study is being initiated on behalf of ICANN, and the lead will be [] lie man /KHAPT man sitting over there, I don't know if he wants to say anything, but my point is that there are technical issues with this and those technical issues will certainly be studied. So, the point of my presentation here is not to sort of jump the gun on that technical study, but instead, I want to look in the sort of, the middle space between technical issues and policy issues and the problem space in general.

So, there is be more technical output later on when the study has concluded.

So, let's start by looking at demand. Demand is an interesting word. I think it's fair to say that there is a large demand for new TLDs. I think it's fair to say that anyone who has before bought a domain name would be happy to buy the same domain name as a TLD. Prices of course is an issue but if we disregard price, if we just look at what people would want to have, demand is large. And because demand is really, really large, I mean in the end this is sort of the perfect product in the domain name industry, this is the product that would just over shadow what all the TLDs are offering, getting your own TLD will always be sort of the trump card that is better.

Expansion, regardless of your position on whether expansion is good or bad, it will always be about holding back, because you just cannot deal with all the pent up demand that is down there.

So, not losing control, holding back, make sure this doesn't get out‑of‑hand will always be needed.

So how large is the demand really? That's impossible to judge. I think it's fairly clear that we cannot have an infinite number of TLDs registers on the planet. I mean over time enterprises will just give up. You just cannot register IBM in thousands and thousands and possibly millions of TLDs, sooner or later you will just give up and instead you will get a .IBM and you are done, but that's a different story.

So I think there is a natural boundary to how many TLD registers of the type we have today that the world can actually deal with, so that would probably sort itself out. But then we get into the enterprises and there are lots of enterprises. And we are also getting into the IPR space and when it comes to intellectual property, well, this gets even more complicated because those guys, they are not really asking for domain name and they hope they get it before the other one. They are demanding that they get that particular domain name because they consider they have the right to it. And that's an interesting problem space once you get into this collapse of the name space that this actually means, because everyone will sort of be competing in the same fraction of the name space.

So, there are various problems here. We also have sort of the scary market drivers because once company A has their own TLD, I think it's quite obvious that company B will have more incentive not to be left behind.

So, we could see a lot of growth here actually. And it's not the case that this will only be restricted to, well normal TLDs. TLDs running registries and setting off domain names down the tree. It is specific talked about the usefulness of TLDs for enterprises and this is referred to as innovation in the name space. I am a bit sceptical. I admitted, to me these are just names. There is nothing you can do with a TLD that cannot do with another name further down with less risk to the rest of us.

AUDIENCE SPEAKER: It's business innovation.

SPEAKER: Of course, but of course, a shorter name is cooler in some respects, so from a technical point of view, I am still sceptical.

We have to look at this. Would a large root actually be that bad? With a present small root, we have the really, really good property that most of the important contents are actually cashed in the recurve I have servers. It's just a bunch of delegations. You cache the refers to COM NET and a few ccTLDs that's your own countries and neighbouring countries and you are basically set and that will be the ISP recursive service basically all the time. So this is good for people operating root name servers because that means we get less traffic. Or less ‑‑ well slightly less traffic at least. We still get all the crap. But we get less of the real traffic so I get at the end of the day we should be happy about that in some sort of roundabout way.

But at least it actually allows us to scale the system up further because we do move traffic further down the tree rather than to have all the stuff go up to the root all the time.

But it also has other good properties. For instance we have the good property that should the root be unavailable for some short or long period of time, it's actually not that much of a deal, because all the referrals that you usually need are already cached. So for instance, when we had D dot attacks against the root server system, well those typically are not detected by users. Because the system still just works. They are detected by people watching monitoring systems or journalists looking for a story rather than the technical community or the Internet community in general really having an issue. But that's because there are just a few referrals and all of them are cached. If we basically flatten the name space we moved millions of names up in the root zone, those will not be cached we immediately increase the dependence on the root all the time we lessen the robustness of the system and suddenly attacks on the root server system will both be more dangerous for us as a community and more attractive to the attackers because it will actually make a difference. That's not too good.

And another important thing is that right now, there are around 200 root server instances on the Internet. That's the same order of magnitude as the number of countries on this planet.. The root server operators are moving out in new places all the time. Although I cannot promise that we will have root servers in every country on the planet, it is sort of clear that we are slowly getting in that direction. And that's good, because if you have local root service and you have your local ccTLD service, then you are actually fine in spite of bad things happening on the Internet, because the local name resolution will work, even in remote corners. That's something to ponder.

On the other hand, if we look at really, really, really, really very large zones like dotcom and a few others, dotcom being the largest one of course, well incidentally, there are no dotcom servers in Africa. There may be sometime. I am not saying Verisign is doing the wrong thing here. It's not a complaint about dotcom not being available everywhere. I am making the observation that dotcom is a very large zone. It's not easy to publish dotcom in every back yard. While we can easily publish the root zone in every back yard. And if dotcom fails to be available in a particular back yard, well DNS still works. Root service is available, the national ccTLD is available and a few other neighbouring TLDs that are used and if there is no local service for a particular zone like dotcom, well for various reasons, local businesses tend to not use dotcom as much in those countries. I have travelled in Africa. In Africa dotcom is not nearly as popular as in let's call it more centralised parts of the Internet. In Africa the local TLD is more popular, for a reason.

But if we move all this stuff is again. Basically taking the extreme case, if we move all this stuff into the root as some sort of extrapolation. Then we are basically getting the fail sharing between the dotcom problem of distributing their massive amounts of data to far and remote corners in spite of already having a system that actually works much better. So we are sort of moving in the wrong direction from a robustness perspective here. Which is a bit worrying.

So, looking at this from a slightly different perspective, the reason we have the DNS today, the reason DNS looks the way it does today is because it was designed to fulfil a specific set of design goals, and this is a very ‑‑ that small inset is a very, very, very old slide that I use when I do DNS training around the world and I have done this since mid‑nineties and this slide has basically stayed intact. It's been true from the start. So, the reason DNS works the way it does is because we want to expand the name space we want to localise the updating responsibility we want to minimise the net traffic in latency and we have the both reverses and forwards we want to have annexe tensable protocol. That's fine. So look at this.

If we basically move stuff up into the root in a more aggressive way, we actually collapse the name space to some extent we lose this property of localising updates in different places. It all goes to the massive data space in the middle we lose the optimisations in network traffic that will be a function of cachinging that we will be defeating. That doesn't look good. And to make it even worse, we actually have experience with a flat name space. That's called the host .txt file. So, if you again look at the extreme case here, the host .txt file had various problems. We designed DNS to deal with that you will these problems we got something that actually worked quite well. And time moves on and now we are moving perhaps back in that direction again.

I am not saying that we are going all the way to host .txt but there is a bit too much of a parallel here for comfort. It could be sort of the host .txt file distributed over the DNS protocol. That's a sort of a scary thought.

So, that brings us to the really important topic here and that is how could we limit growth? I mean, I actually don't dispute that we could probably add a few hundred TLDs with no technical impact. I don't think there would be a problem with 10,000 new, but I am scared about the end game, when this sort of just continues to roll and for that reason I think it's important to have a mechanism in place to be able to say "Enough." And that, by the way, is one of the things that the technical study is aimed to look for, when is enough? What numbers are safe? I want to go one step beyond that, I don't only want to know what is safe. I want to know how to stop it once we reach that point.

There are basically just two methods. One is financial barriers and the other one is administrative barriers.

So let's look at financial barriers. There is some sort of initial application fee. I don't really care what the amount of money is, but it's some amount. So the first argument I have heard when I raise my concerns about this getting out‑of‑hand and how to kerb growth is, well, if needed we will just raise the price. I see a lot of problems with this. But let's ignore the part of money going to ICANN, that's a problem by itself, but it's not my focus.

The major problem here is that ICANN has already stated that as volume goes up, the application fee will go down. So, if the application fee goes down, we will end up in a situation where most of the early applications will probably be from let's call it, the industrialised world, not only but a high fraction, they have the spare cash or used to at least. And then the application fee goes down and volume picks up and the developing world jumps in because it's now reasonably priced and then suddenly the price goes up again because we need to kerb growth. I think there will be complaints about this. I think it's not possible to both aim for the lower price by increasing volume and at the same time, aim for the higher price to curb growth. You just can't have it both ways. So, I think this is not really thought out that it will work. It just might. I don't know. But I would like to have something slightly more definite so that we know it will work. And I think there is, it's not clear that this will work.

So let's look at the admin barriers then. I think admin barriers are really good. We have admin barriers today. When I send in an application for TLD which I do now and again, they say get out of here. That's a very good admin barrier and it works.

The problem here with admin barriers is that if you want to design for growth, which is what ICANN want, because they have made a decision that they want to grow, and you beef up your operation and you hire new IANA staff and you streamline your processes to be able to deal with a higher follow and accept more TLDs for every time unit, once you have done that, it will be much more difficult to say "Sorry, for administrative reasons we can only process two TLD applications per week" because that's a pure lie. Today it's probably true, but once you have hired a hundred new staff and you have a stream lined operation, it will no longer be true. So I think this is a case of staying with the local policy is easier than to first open up the gates and then try to close them afterwards.

So, going back and trying to sort of summarise this. Going back to the argument of demand and demand being large. If we look at the world as the TLD drug addict. The TLD drug addict really likes new TLDs. More TLDs. We want them we want them now we want them as cheaply as possible. The old plan was you are not getting any. That's sort of a tried method of dealing with drug addiction. Now we have a new plan and it says: "Okay, we will hand out a fair number of these new TLDs and hopefully you won't like them and sort of demand will just Peter out and then we will just turn off the supply."

I don't think that will work actually. Especially not when you lower the price.

So, I think there is a problem here.

CHAIR: Speaking of which Johan, we are running deeply into the coffee break and you have a couple of remaining slides. Will you try to ‑‑

SPEAKER: I will fast forward and you will just have to have your reading exercise afterwards and just read through this, if you like, or have coffee instead. But the central theme I think is established. And abundance scarce, there are problems with going from scarce to abundant and back to scarce again. We have covered that, there are problems with changing policies because when you sort of change the policies underneath the feet of people, that will cause them to adapt and that causes its own set of problems. And once you define a certain number of delegations that are safe, let's call that N, we will probably run into a different problem trying to deny the N plus 1 application. Because there will be no technical ground for it. So, even here, even if we define what is safe and what is not safe, we still have central problems.

I will skip this. And I will actually skip this too. And I will move to the last slide.

So, the what have question. I don't know about education in other countries but I know that in Sweden the what if question is actually referred to in engineering education. You should ask the what have if question. What if this happens? I mean that's the way you design an aircraft. Not because you think it will fail but what if, etc.. So what if questions are really important when you want to do prudent design from a safety perspective. So, what if there really is no practical way of limiting growth once the gates are open? I am not saying this is true. I am just saying no one has proved that it's not true. There is a risk here and it should be studied.

What if it turns out that basically unbounded growth doesn't work too well? What if we don't have a plan B? Because once you have sold the TLD, it will be sort of difficult to take it back. And what if, just to make this really, really, really concrete, we have to choose between signing the root because we have a small zone which is technically easy to sign or do a really, really massive expansion of the zone which might preclude signing? Again, I am not saying this is a fact. I am saying it's something that should be considered, because one of the problems with having the non‑technical people make decisions like this, is that they usually take the candy store approach, they are kids and they get into the candy store and they want the yellow stuff and they want the blue stuff and the red stuff, but from an engineering point of view, sometimes you have to explain to them that you can get this or that, not both.

Okay. I am done. Sorry for ‑‑

CHAIR: Thanks very much Johan, I don't think we have very much time for discussion. We won't come to a closure here anyway and we have two announcements afterwards. So the both of you and done.

AUDIENCE SPEAKER: Hi Johan. Joe all speaking. One thing that I keep not coming to a proper conclusion on whenever I hear talk about this is, I mean, how is the unbound growth situation be different from the root than it is for dotcom for instance? What would be the challenges that one would face that the other does not?

SPEAKER: Do you want me to answer?

AUDIENCE SPEAKER: Well, yes, if you have an answer.

SPEAKER: I think that from a technical point of view, there is no difference. Dotcom or the root face exactly the same technical difficulties dealing with the churn rate and dealing with how to distribute the zone or ‑‑

The difference lies in the consequences for the world.

CHAIR: Sorry Joe all, I don't think we can ‑‑

AUDIENCE SPEAKER: I had more than one question.

CHAIR: Sorry, Jim.



AUDIENCE SPEAKER: Jim: I would like to ask two questions here Johan. Is there any way that members of this Working Group could either participate or give input or their thoughts on this scaling issue either to ICANN or to this work that's underway that you mentioned earlier on?

And the second question I have is one for the Working Group is: These what if questions you have posed, are these things that the Working Group should consider and try to do some work on? Speak peak my answer to the first one is that I honestly don't know, because I am more of a technical person than I am a policy and community how to do this in the right order and the right community type of thing person.

So, I have tried to argue this in a few technical fora, and that simply doesn't work, because this crosses over into policy. And when you are trying to argue about this in purely policy fora, it doesn't really work because it's too technically complicated which is basically why we are here because RIPE is sort of the ideal crossover between policy and technology.

I do make the observation that in the case of for instance the TARs, we had a really good discussion about TARs in Tallinn some years ago and that resulted in a TAR Working Group or taskforce and eventually documents were sent off to ICANN having a position on this.

Whether the Working Group wants to do something like that in this case or not is not for me to decide.

CHAIR: Thanks. /TKPWEUS we have to cut this discussion here as interesting as it is, thanks very much Johan for raising this and I guess you will be approachable for further input and then maybe come up with a group of people discussing this.

SPEAKER: I should just add that if you look at this in the download thingy, there are various references that you can look at what other people were said about the root scale expansion, so it's not only my positions here.

CHAIR: Thanks very much for this.

(Applause)

CHAIR: There are two more things to say. The one is obviously the follow‑up discussion for the Plenary is unfortunately to be cancelled right now in here. The other one is the action item collection, so we have caught one action item today on Anand and the chairs to take care of the Lame delegations reports. The other one from yesterday on the domain objects, and there is 57.1 which you postponed discussion about today, DLV registration of the NCC maintained keys. My suggestion is that the Working Group gives the Working Group chairs the responsibility to coordinate with Anand again to take care of this. Is that okay with you? No opposition great.

So that's basically it, I would like to thank you all the presenters, our mini takers and our on line scribe and the technical support from the RIPE NCC. Thank you for your patience. And the last thing between you and your T‑shirt is me thanking you and buy, buy. I'll see you in Lisbon.

(Coffee break)