The session commenced on the 29th October, 2008 at 9 a.m..
CHAIRMAN: Good morning. We are going to be late starting this morning. We have got no power in front of the room, so we can't drive the laptops and the projects aren't yet working and I believe there is limited network connectivity. So we are trying to work on all these problems and I guess we'll start as soon as we possibly can, but I guess it's going to be another five minutes or so. Sorry about that.
CHAIRMAN: Good morning. Looks like we are back on line more or less. Sorry about the technical problem, but let's move on with it. And first on the agenda is the IETF working group update by Lars Lars Liman.
SPEAKER: Good morning everyone, I am Lars Liman and work for Autonomica Stockholm.
In these slides I made a few notes in italics and they are my own comments regarding what's happened the IETF. The IETF was at the end of July, so some things have happened since then. But they were made just from a quick glance on the mailing list so there are probably some errors in there, but they should at least give you a feeling for what's going on.
There are two working groups in the IETF that pertain to the DNS, and they are the DNS extensions working group in a deal with extensions to the protocol and there is the DNS working group that deals with operations perspective of the DNS.
First the DNS extensions working group.
There was a draft there is a draft regarding methods to mitigate problems that are inwithin DNS protocol and how to make your systems more resilient towards certain types of attack. This document is a fairly young document, but it's already passed the working group last call meeting, that it's well ahead on its process going to ab an RFC. After the working group a new version was published and people were asked to check that, all their issues were address indicate this new issue of the draft.
After that, some discussion on the mailing list, so Oliver who is one of the working group chairs has taken a new grip of the discussion trying to focus it ongoing the right way.
As you probably know, the SHARSHA 1 algorithms have been debated and it's considered to be rather weak these days, so we need to extend the DNSSEC mechanisms to be able to handle more robust checks on algorithms and there isn't yet any specific key types, algorithm types in the type fields for that, so this is a document that just describes new things, the new keep types for the DNSSEC.
This is a very straightforward document, no comments.
The working group as last call was sent out in mid August. There were some issues on the list, but there was a new verse junction a few days ago. This is a living document and it's heading the right way.
There is an update document for the current DNS standard and it's been sitting there for a while. The chairs wanted to focus and get a consensus regarding this document during September, but there was some discussion, but it seems to have died off, and we haven't I'll keep talking because I can see the slides here and if I don't keep talking we'll never get done.
There.hasn't been any working group last call on this document yet.
The next thing is there is a document regarding update of the extended DNS protocol, the author claims that this document /STKOPB, it's already there. So there was an action point on Oliver, one of the chairs to send the document working group last call. When the previous last call the last call from the previous document had ended because they didn't want to have simultaneous last calls for certain documents. The thing is that the last document never appeared in the last call, so this one hasn't come up, the turn for this document hasn't come up yet. Aunt the problem is that the Internet draft has now expired from the archives.
There is also a document regarding deprecation of the MP5 checks on algorithm and this is more contentious. We need to phase it out of the DNSSEC. There was a comment that it shouldn't say deprecated, it should say no longer required and that was taken into account.
However, it was noted that there is no good place in the system of the DNSSEC to tell the status of various algorithms, checks on algorithms and the encryption algorithms. So, even though this document is fine, we need somewhere to tell the status. So we need to update the IANA register function for DNSSEC methods and algorithms, so there was an action point on Peter Koch to draft some text for that and as far as I know that hasn't happened yet.
There is a document that tries to clarify some transfers for DNS, it's been sitting there for very long. It was noted that it needs a new section that makes the distinction between loading a zone from a master file into an authoritative name server and it also a distinction from that to transferring zone, because these are two different things and they have different properties.
So, it was task to make a proposal from scratch regarding that.
Some text was sent out. There was some discussion, but it's died out on the list.
Proposed new work in the working group. Steve crock err wasn't there, but a document he has written was presented regarding a mechanism to signal under the standing or non understanding of certain algorithms in DNSSEC, so when you send out query and the response you can response which algorithm as I as a server am able to handle.
There was an action point to ask the mailing list and the working group to adopt this document and that request was actually sent in in August, but there is no sign of adoption of this document. It's not in the archive and it's not in the Internet drafts archive and it's there is nothing on the mailing list as far as I can see.
There was a request for update of the very document RFC 1123 host requirements where there is a statement regarding top level domain labels which are expected to be only alphabetical and than doesn't really work with IDN names, because they contain dashes, so, we need to update the text regarding labels in 1123, so I was tasked to this this and I am sorry to say this hasn't happened yet, although we haven't dropped the ball yet.
There was a proposal to start investigating how the relationship between dynamic zones and DNSSEC because there are lots of inherent problems there, especially with the signing of the dynamic updates and there is not a document yet, but mark Andrews famous for being the chief engineer behind bind these days, is looking for help to start investigating this problem and he'd Lewis note that had he had written something about that long ago and wanted to contribute that to the discussion.
After that there was a discussion about further forgery resilience work. Further work to make the DNS system more robust and there was an urgent request from one of the chairs to the audience to implement the draft that I mentioned earlier regarding fraudulent resilience already now, even though it's just a draft and it's just passed the working group last call, it contains a lot of good hints how to make your system more resilient. There was a long discussion on something called DNS X 20 which is an interesting way to try to increase the (X) variation in queries. Normally a query varies by the query ID and at more recent idea is to also vary the outgoing port number to make it more difficult to spoof incoming answers, responses to the question.
But you can also change the casing of the actual query stream by making upper and lower case in a random way and there is a draft on how to do that.
The conclusion of the discussion was that we need more proposals. There are lots of ideas out there on how to make the DNS more robust and resilient but it's not documented, so if you have ideas on how to do that, please write up a document and submit it as an Internet draft so that we can get it into the working group and see what the alternatives are and then choose from that and start to work on it and make it formally documented in RFCs.
There was a very short any other business section which was very scary. Row /AR ends and John Dickinson gave a sort demonstration on how to poison a cache using the Kaminsky methods and it's scary stuff. It took a few seconds. It varied between a single of seconds up to maybe 45, 90 seconds but not more than that. This really works. It's really bad.
The DNS op operations working group has a document reflecters are evil. All issues are resolved in this document except that the IESG had a comment about this. It turned out that the document was held up by a comment from Paul Hoffman. He wasn't aware that. It turned out he was happy. The area director who was present at the meeting said I'll lift this. It has since been blushed as an RFC. So this is a success story. The only one in this presentation.
Here are two documents that are unfortunately have been stalled. One regarding which zones to give service for locally in your resolvers because it's no use to send away queries for or 168 dot 192 dot there is a whole bunch of zones that it's meaningless to send out the queries on the Internet because there is no real answer out there. So you better take care of them internally in your own resolver and there is now a formal specification for which zones to handle but that one has been stalled. I haven't seen any actions.
And the same goes for the reverse mapping considerations. This is probably the oldest draft in the working group. It's been sitting there since I was chair for that working group and that's now five years ago. I haven't seen any action. And this is also unfortunate because it's a document that could be used as a tool to improve the reverse look up situation.
The charter is under renovation. It turned out that the performance and measurement part of the DNS working group charters may collide with some other working groups. The chairs will talk to each other and try to find the demarcations between the working groups and it was expected, they were expected to send out a new charter, proposed charter after the IETF, that hasn't happened yet.
The response size draft. How do you calculate the response size? That is waiting for working group last call. So there are a number of documents that are waiting for working group last call but that hasn't happened yet as far as I can see in the archives.
There are two drafts that deal with operations of the AS 112 project, which is a loosely coupled Anycast system for hanling queries for net 10 and 192 and 168 and and the others that leak out to the Internet anyway because people haven't configured the local zones. These are awaiting working group last call as well but they need to be revived because they have expired but neither of the above has happened yet.
Trust anchor configuration. The author believes that all (trust anchor) which is currently the present one. And the chair said working group last call real soon now. A couple of questions were raised on the mailing list in August, but since then nothing has trapped.
The result of priming draft regarding how to get your resolver going from the hints file and it had a couple of interesting comments. One is that we need to align time to leave numbers, not only between the A records and the AAAA records in the routine system or the response to this priming query from the route servers but we need to align it with the SOA and also with the route service.net zone file because the root service carry both the root zone and the root.net zone and they need to be aligned for everything to work well. That may not be the case currently. So, this is actually not out spoken action point on the root server operators to make sure this is lined.
The design team team for the configuration protocol gave a final report in the form of a document which was accepted and it was asked to make the working group the document a working group item. That has been done. It was the design team was disbanded, also done, and it's now time to start working on the actual protocol for the name server configuration.
Operational practices business. There is a DNSSEC document regarding operational practices, it was proposed by Paul Hoffman to update this because actual use of this document has shown that it's not a very good document. So it was proposed to use his presentation as an input to the working list to the working group list and start on an issues list to see what we need to deal with here.
And there was a measurement report from sorry, that's the missing M name one. Joe Abbley presented the problem of dynamic updates hitting the servers behind the N maim, there is a server April and that one gets up by lots of dynamic updates attempts and he wanted to deflect them and presented something which turned out to fall between chairs. So the working group chairs in DNS EXT and DNS OP are supposed to find in which working group this work is supposed to belong. I don't know if that's happened yet.
And finally, there was a report from Joe Abbley and Mr. Kerr, Shane of course, who tried to measure the number of servers or the fraction of servers that are able to support the EDNS 0. There are a number of findings in this draft, if you are interested I'd say read the draft, but it was there was a bit of discussion after the presentation regarding how to measure and what to measure and the methods and so on, so there are probably other ways to do this which may yield a different result and I think that is the conclusion of my report.
CHAIRMAN: Thank you. Are there any questions? Missing is the IDN stuff but that's a complete subject on its own.
SPEAKER: So, a quick update from the IDNA working group.
What we are trying to do now is as people might know is that we are updating the IDNA standard that is, that was created in 2003. There is currently a pretty strong e mail exchange by the working group chair that verifies the consensus of the working group on the documents. At the moment, my feeling of the document status is that the tables comment that I am the editor of and the by directional document, which are the two core documents of what characters are allowed, both of those documents are stable and we have a consensus that those documents are done. There is still a discussion regarding the overall protocol document that describes the standard. And the discussion is: What pieces are normative and what pieces are non normative. What should go into a standard /STRUBGT document and what should go into an informational document. But we do have John Clansmen as an editor of those documents and we do have a proposal on how to split the documents and move text between them.
CHAIRMAN: Thank you for this impromptu update. And now without further ado, we can invite Anand to talk about what's happening at the RIPE NCC on DNS. (Anand) (algorithm is algorithm)
SPEAKER: Good morning everyone, I am an mad Buddhev, I managed DNS services department at the RIPE NCC. And I am going to give you a quick update on what's been happening in our department.
If you are following the presentation from ROSIE, then you may notice that there is some differences because I had to make some changes and this is the latest version and the one on ROSIE is a little bit outdated.
So, an introduction to the DNS team. We are a very small team. Myself, to my left and to your right on the screen is Wolfgang gag /HR*E and to my right is insured owes dike. Wolfgang mainly does K root operations and AS 112 and insures owes dike does mostly the reverse DNS and reverse secondary services.
Talking about services. This is what the RIPE NCC provides to the community. We run one of the 13 root servers of the Internet, K root. We also provide a recertificates DNS delegation for the IPv4 and IPv6 space that we allocate.
The RIPE NCC also provides secondary service for some ccTLDs. The RIPE NCC also does the ENUM zone. We are prime we do provisioning for this. We also have an AS 112 node. AS 112 for those who may not know, is an Anycasted network for mopping up the traffic, the reverse DNS queries for RFC 1928 address spaceLyman mention that had a few minutes ago as well.
We also sign all our reverse zones as well as forward zones and reprovide trust anchors for the community to download and load into their caching resolvers. And we provide RIPE NCC internal DNS services, you know, for our network.
So, K root: We have had stable operations. We have 17 instances currently and most of them are in Europe. We have a few instances in other places such as Tokyo, Brisbane and Miami.
One of the important changes we have made since the last RIPE meeting has been a change in our traffic policy. Previously we announced a /24 prefix from all the instances and we pre pended AS 25152 from the global instances, so that the local instances would get more preference. We have since changed that. We now announce only /23 from all the global instances and a /24 with no export from the local instances.
And we are not doing the path pre pend any more. So, this has actually had a positive effect. We see that more local traffic is now going to the local instances and so that's a good change. And the traffic at K root is currently peaking at about 20,000 queries per second.
K root has also been providing service over IPv6 since February. Seven of our instances are now IPv6 capable. M6 and the one in Miami are the global ones and then five local ones and we are seeing about 200 queries per second about IPv6 over peak time.
We have plans to expand K root now. We are actually working with regional, other regional registries to try and place some more K root instances in the less represented areas such as Latin America and Africa. We are also going to do another round of hardware replacement for some instances. We plan to deploy IPv6 in London and Tokyo, so that should happen possibly before the end of this year. And we have decided that we'd like to promote the instance in Frankfurt to that of global status. It gets lots and lots of traffic and it's in a prime location fora announcing prefixes to the whole world.
So, we do also reverse DNS. One of the changes we have made recently is that our reverse DNS provisioning system is now fully IPv6 capable. Most people will not have notice this had but we actually had a lig bug in the provisioning software, so that if any of your name servers had IPv6 addresses, these were not being put into the zone file. And the provisioning system now does that and so, if you have an IPv6 only name server, then you will we will be able to perform zone transfers from it.
One of our servers, NS dot ripe.net which provides secondary service for many /16 zones, this is seeing about 30,000 queries per second. And we'd like to make this service more resilient by adding a second server. This is going to happen next week as soon as we are back. And the service that's provided for ns.ripe.net will then be load balanced and will be more resilient.
Our DNSSEC operations are still quite stable. We haven't had any new primary zones added recently. I have got some statistics about the number of NS records and DS records. The number of DS records has gone up slightly since the last RIPE meeting. We are now at 156. So there is a small growth, but not particularly significant.
Over the next coming several months, we plan to do a complete review of our DNSSEC infrastructure. We are going to review all the policies and procedures that we have in place. They have worked quite well so far but I think it's time that we looked at it because we have been doing DNSSEC for about three years now and we have gained lots of operational experience and there is some things that we think we could go back and look at.
We also need to replace some hardware that we used for DNSSEC. And finally, we are looking at possibly developing better tools in order to help us with key management and roll overs. At the moment we use the pearl tool that was written at the RIPE NCC by Olaf Kolkman. This they work, but there is some manual work involved and sometimes humans make mistakes and we think that this can be improved. So we'd like to look at this in the coming few months.
Just a little plug for DNSMON. This is not a service that we run. This is run by our colleagues in the information services department but it is related to DNS. DNSMON has seen several stability improvements. It has gained IPv6 support and was it last week or the week before the IS department announced single sign on. This is so that you can use one user name and password for signing on to all the services that IS provide. That's DNSMON, MyASN and other stuff. I see Ruben standing there, maybe he wants to say a very, very, very quick word about it.
Rubin: We did roll out a single sign on for all the information service. If you have any questions about it, feel free to contact France at the meet and greet desk, otherwise try to find me. Thank you.
CHAIRMAN: Thank you very much Rubin. So carrying on. There have been more probe locations. There are now probes in Australia, Russia and Brazil. There are no real time alarms and particularly when there is back up loss or the response time goes up, and quite interestingly, there is now a special category for ENUM domains. It's 500 euros per year and if you have any questions about this, please contact our DNSMON sales team.
Operations in ENUM are quite stable. There have been no new delegations since RIPE 56. We have signed the zone and DNSSEC is now available. It has been since March 2008. Two zones have secure delegations and I am going to present a few more statistics about ENUM in the ENUM working group later today.
We provide secondary ccTLD service. We provide this free of charge to developing and small individual ccTLDs. We realise there is potential for competition within our members so we are phasing out this service for some of the more developed ccTLDs. In this round of in this iteration, we have faced out Latvia, Romania. We have still busy with Ireland, Hong Kong and the Slovak Republic.
Something about reverse DNS lameness. We have been running this project since February this year. We have been gathering statistics about the amount of lameness in the reverse tree. Apologies for that URL, for some reason the colour hasn't shown up properly. But we do publish these statistics on the RIPE NCC website and the graphic that you see on the screen now shows you data for the last 12 months.
The good news is that there isn't much lameness. There is about 6 percent which is not too bad. The minimum is half a percent in the 90 /8 zone. The maximum is about 20 percent in 95 /8 and that's because there is only 5 servers there and one of them is lame. And there is just over 5,000 unique e mail addresses in our database that we need to contact about lame service.
We did a very, very quick and little test in September. We sent out some e mail alerts to people who were perhaps administrative contacts for lame servers. Unfortunately we detected some issues with our code which sends out these e mail alerts and we also discovered that queries over IPv6 were not actually very stable. So we have identified some of these problems. We are working on them and we hope to be able to send out e mail alerts in 2009.
Then we come to a very interesting thing that we have been doing. We have been looking at the domain objects that we have in the RIPE database. One of the reasons for this is because the RIPE NCC now has a legal requirement to maintain consistent and up to date data in the RIPE database. We have nearly 400 though domain objects. 97 percent of these are related to reverse DNS. There is a few IPv6 reverse zones. 45 ENUM zones. 49 TLD objects. About 8,000 sub TLD objects and then there is about 2,000 other objects. You might wonder what these other objects are and here are some examples.
Most of these are syntactically incorrect objects. One was able to create them in the RIPE database in the past because the syntax checker was not so strict. You couldn't create them today. Many of these objects, but they have just never been cleaned up. So some of them from dashes after the in other and between arpa, some are missing a dot. Some are actually /24 delegations where the person creating wasn't quite sure how to use the right syntax. Some are less than /24 domain objects.
All of these are actually ignored by the provisioning system. It doesn't do anything with them and they are there for, you know, since a long since early 2000.
We also have these forward domain objects, these are some of the ccTLD and sub ccTLD objects. Some of them have a refer attribute /O if you do a Whois query for a same that exists in the database, the query will he redirected to the ccTLD registry. Some ccTLD registries have been using the RIPE database for provisioning and many of these forward domain objects are actually quite old and inconsistent with the registry data.
So, that was a quick update. I am happy to take questions...
AUDIENCE SPEAKER: Not so much a DNS question, but happy...
SPEAKER: Right. Then I will hand over to Peter Koch sorry, Stefan.
AUDIENCE SPEAKER: Regarding DNSSEC at the present time, I believe I know the answer but I would like confirmation. What is a proper way to retrieve the many interest anchors of your DNSSEC domains?
SPEAKER: We publish the trust anchors on other weapon site in bind 9 trust anchor format. The file is signed. We have a PGP signature for it and you can fetch this file.
AUDIENCE SPEAKER: That's what I discovered too. But how are you told about a thing like that. What is a proper mailing list to subscribe. Is that specially a question for the RIPE, it's a general issue with DNSSEC. I have now DNSSEC validating resolver on my it's really a problem to keep track of everything. When it was experimental it was okay. But now that we are moving more and more into production. It starts to be a real problem. So first, what is a proper mailing list to be subscribed at to know if there is a roll over.
SPEAKER: That would be the DNS working group mailing list.
AUDIENCE SPEAKER: And do you have any plan or opinion about putting the trust anchors in a DLV registry?
SPEAKER: At the moment we don't have any plans, but it's certainly something we can look at and talk about if you'd like us to do that.
AUDIENCE SPEAKER: Yes please.
SPEAKER: Thank you. Right, if there are no other questions, then I will hand over to Peter Koch who is going to talk a little bit more about domain objects in the RIPE database.
(Applause)
SPEAKER: For the sake of time, I am stealing his slides a bit. As you might have seen on the agenda and as you have learned from an manned's report, there was some issues on domain objects in there. So, there was, I guess they are probably reported in the database working group tomorrow. There was kind of an issue with objects unmaintained and those of you who have been following the database working group and the process there, you might know that there was a decision made that all objects in the database should actually have been maintained for security and consistency reasons. So, stuff like that happened for the domain object as well and the NCC discovered that some of the objects were unmaintained, that included domain objects as well.
So, these statistics were made and there was a short discussion between Denis Walker and his team from the NCC and us co chairs of the DNS working group what to do about this. So, in essence, it was quickly decide that had before going publish with this whole stuff, the situation should be fixed. So all of the domain objects received a maintainer by one way or another. Several heuristics were applied to that and so the situation is okay now and nobody can just alter foreign or third parties domain objects or add random domain objects to the database any longer. There is interesting stuff in the database and this includes these I'd say broken entries which could or could not be removed but that's probably up to the database working group.
It also turned out that there was lots of forward domain objects in there. I guess it's on one of these next slides that don't really make any sense or might not make much sense, because you may know that the domain objects in the RIPE database go back far in time when there was the when the RIPE Whois server was the only one to have in the RIPE services area. Back then, most of the ccTLDs in Europe and the surrounding areas just routinely submitted all their domain names and the registrations into the RIPE database. Most of them have been migrated out in the meantime but some of them remained in there.
The situation is quite inconsistent, so forks some of the ccTLDs, there is random data in there. Legacy stuff and due to the fact that the ccTLD object itself wasn't maintained, a random selection, because somebody felt that their second level domain should just be in the RIPE database.
For a few very low number of ccTLDs, they maintain all their second level registrations in the RIPE database, but that's on the order of I guess two or three ccTLDs with maybe 15,000 or so registrations in total.
So, the question here is now for the working group to decide or first discuss and then make up our minds, what to do with the forward domain objects in the RIPE database, so the reverse objects and the ENUM objects should be out of question because they fulfil a clear purpose. They are used to provision the actual zone generation for both the ENUM tier 0 zone and for all the reverse zones and I guess we want to continue with that. The question for the working group is (zone) what is the purpose of having the forward domain objects in the database (database) what the do about inconsistency there and well, in essence, is there any useful purpose for these objects for the reference into ccTLDs Whois servers or could we, in the extreme case, get rid of this stuff and as chairs, we'd like to receive input from the working group what you think what the purpose could be and what you think about further progress.
AUDIENCE SPEAKER: Hi. The RIPE database was agreed sometime ago, we agreed already that the RIPE database was not a domain Whois server for general proper use. I think the only thing that was said at the time was that the very small ones would be allowed to stay until they could migrate. That was long enough ago that people who were serious about their operations would have had a chance to migrate and now it's time to flush them out.
AUDIENCE SPEAKER: I happen to be the chair of the centre technical working group and since we met at the beginning of the week, I just repeat what we agreed all together there. And this is that: All ccTLDs person will have no problem with RIPE dropping their ccTLD object from the database.
SPEAKER: Marrow, just as a clarification, that it would include both the second level data and the remaining ccTLD object that has a refer that goes and points queries to the respective ccTLDs Whois server, is that correct?
AUDIENCE SPEAKER: That is a very good question, we were explicitly talking about the ccTLD top level domain object. I don't know if the RIPE database allows from the one to be dropped without, and having some objects further down the year being kept. So, the discussion was explicitly about the top level domain object.
SPEAKER: Okay. Thank you. So to explain here, or to expand on this a bit. There is of course the policy issue, so to speak, on whether or not the NCC should, on behalf of the community, delete objects by bypassing the maintainer or the actual procedure would be, but that I defer to the database working group. Let them deal with that. The basic message that should come, the basic advice that should come from this working group is either, oh yes we think the domain objects are still very useful and we'd like to keep them. And the course the next question should be the DNS working group should give advice how that deal with the inconsistency and make sure that no bad things happen. Or the community here is going to say, we don't see any useful purpose any more in forward domain objects and ask the database working group to come up with procedures conforming to traded habits and policy to get rid that have stuff. And I have heard from Marcus, just to reiterate that, that the ccTLD organising centre are happy to see their domain objects deleted.
So, anybody want to speak in favour of keeping domain, forward domain objects? Who would agree, who would support deletion of these objects? Of course, following proper process?
Okay. That's probably like 25 ish hands for the minute. Anyone object? You are raising your hand? No. Okay. That's nothing you object, Jim?
Jim: No.
It's just really a simple issue of clarification primarily for the minutes. I think we can record here that the working group has decided these objects should be deleted and an action point should be created. The owner can be, I suppose, myself and this will then go to the database working group for them to take the appropriate action to get these objects removed from the database since that's a database issue rather than a DNS working group issue. So I'd appreciate if that could be recorded and open up an new action item. Even if it's just to chuck this thing over the wall to the other working group. Thanks.
CHAIRMAN: It looks like we are making slightly up on time although we are still behind and the next one on the programme, the talk with next step with DNSSEC and.
SPEAKER: Good morning, I am Lance Wolak, director of product management at .org public interest registry. As you know, .org we have affilius as our back end provider, back end operations, so while at .org we focus on the commercial launch of new services like DNSSEC, Afilias is right in the middle of the technology implementation. So part 1 of what I'd like to cover is industry coalition that we initiated in August. And part 2 is an update on what we are doing at .org with DNSSEC and the progress we are making and Shane Kerr from Afilias is here today also. So I may lean on him a little bit to cover some of the more technology milestone points.
So, first of all, the DNSSEC industry coalition was formed around August of this year. We reached out to the technology community to get an idea of you know, the things we can do to speed up the adoption of DNSSEC and see what kind of recommendations came back from the community. And the first and probably most prominent recommendation that came back was, the registries that are rolling out DNSSEC really need to take the lead to jump start DNSSEC and followed by the registrars.
So, in August, we got together with a few registries and came up with a plan to work together. First our goal was to accelerate adoption of DNSSEC and provide uniform roll out among us registries.
So, initially it was a kind of an informal coalition, but we have taken steps to organise this in a much more formal manner. We have an MoU, a memorandum of understanding that we have all signed as members of this coalition and we have opened up invitations to any other organisation that wants to become part of this. We appreciate input from everybody on this.
So any other registries or any other software or technology development companies that are interested in participating, please do.
So, in terms of speeding up the adoption of DNSSEC, how would we do this? Well, we came upon she is three objectives. One was to establish consistencies of tools and applications that the registries would be rolling out, and ensure best practices, specs on these tools and applications, shared nomenclature. So even the simple things of how to run an implementation guide for a register or an ISP, having the same table of contents coming from various registries, because while we are all rolling out somewhat our own flair of DNSSEC, we'd like to be able to identify what's common among all of us really to Streamline the effort of those downstream from the registries.
We'd also like to deliver information to the public to educate on the value of DNSSEC, again to speed up the adoption and so, those who would benefit most from it would begin that education process with them.
So, one of the things that we made very clear from the beginning, those involved in this group, is we are going to leave all the political agendas at the door and focus solely on the adoption and awareness of DNSSEC. So we don't want to spend time talking about the things we could do, should do or might do as a coalition but just get to work on specific projects. So that's kind of our mode of operation is to talk less and do more in terms of actual work.
Among the current participants, us, .org, Afilias is part of this coalition, NOMINET, .SE and consulting service provider, Shincuro . These members listed have all signed this memorandum of understanding and again, this is open for any other organisation that's interested. We have interest from at least five other registries right now that are reviewing this MoU and we'd expect them to.join here shortly.
So in our initial activity, which is was in the August time frame leading into September. As you can imagine, with those registries all in the same meeting in the same room, a lot of strong personalities, a lot of great ideas, what we can work on together. It was important for us to identify a set of priority items to work on and have a decision structure to arrive at that. So we produced a decision model and a project plan within a three week time frame. Again keeping to our thought of doing more and talking less.
So, this decision model scope a little bit about that: We wanted to derive a list of priority items from this team. We need today arrive at a consensus quickly and in terms of the scope, we did not want to reprioritise the individual organisations that were involved in this coalition, we didn't want to reprioritise their own specific DNSSEC plan. So the things that we'd be working on together as a coalition, that's what we set out to prioritise, that list of activities (together) we'd be working on.
So, we developed two decision models plus a project man. The first decision model was to identify early adopters of DNSSEC. Our priority targets. And the second decision model was to identify the critical requirements of those early adopters. So going in that particular sequence.
And then specific project plan with assignments taken on by each of the participants.
So not to get into too much detail but just to give you an idea of what we arrived at. The priority order in terms of our early adopt err segments we were going after are listed here in priority order from hosting companies, DNS providers, over registries, registrars, and other software and hardware vendors.
And then in terms of the requirements of the deliverables going out to these early adopters. Tools and applications was clearly top priority. And as I said earlier, this could be anything from developing tools and applications within the coalition to simply just sharing specs, looking over each other's shoulders at what we are doing. Table of contents sharing. And so forth. And then also to produce educational material and some add Casey efforts. But that's the priority order there as well.
Then we had assignments among the participants in this coalition and if you looked at the priority order, the first target early adopter was the hosting companies and in terms of tools and applications, we wanted to provide these hosting companies with a team lined implementation guide and (stream lined) we have a set of projects we are working on here: Tools, applications and a number of how to guides and we have gone as far as the nomenclature what we call these implementation guides, how many chapters, table of contents, will all be the same among these implementation guides coming out from those initial registries that run that list.
Educational material: I wanted to encourage hosting companies to adopt DNSSEC and also provide them with sell through materials. One of the things we are considering but you know these types of things tend to be a little over used but we were thinking about a DNSSEC ready sale or some kind of /STPH* seal) label but more importantly behind that is what is a set of self assessment criteria that a hosting company could go through that would let them get a good idea that they're actually ready to begin doing good things, ready to begin making mistakes, ready to begin making positive headway on DNSSEC. So, while we are kind of calling this the DNSSEC ready seal, it's more so a list of criteria for hosting company to do a self assessment.
In this presentation, I won't go through all the detail today, but as you look through this on your own time, we go through a list of these priority early adopters and the different types of things we are developing for those targets.
So, in terms of the industry coalition, again we are open to any additional participants. As I said, we have five other registries right now that are ready to join as well as other add could he Casey groups. And the contact is our senior product marketing manager and here is her e mail address.
Part 2 of what I wanted to cover is a little update on .org specifically and our roll out of DNSSEC.
We have initiated a product launch process. Really we wanted to get all of our criteria for readiness while documented and have a well functioning bait attest period as well as criteria leading up to production readiness. We are calling this bait attest period a friend and family period, I'll talk a little bit more about that in a second. And clearly with any product launch process, we are closely tracking our critical path milestones.
We expect to have the majority of the technology work completed at the end of this year and the zone signing and our friends and family launch is on track for the first half of 2009. At earliest, around March /April time frame will the zone signing and friends and family our bait attest launch and there is a lot of dependences, software dependences built into that. It could be as late as mid year.
And as I said earlier, Afilias is doing our back end operations and a lot of our technology implementation. Here are the milestones that we are tracking along with Afilias. I don't know if you have any particular insight you want to include with these milestones, Shane?
Shane: I am not sure what I do.
My name is Shane Kerr I am with Afilias. I am the one that's been working with the tools from the point of view of our DNS infrastructure. So the changes to our software required on the registry side, which is the actual database have been completed for quite sometime now and that includes the EPP extensions and things like that. They are not actually in production but it's all been tested and finished. The work that we are doing now is more on the customer facing side as far as the DNS resolution process. So that involves, as you see here, bind testing. We have been working with ISC, we have a new version of bind which came out a few weeks ago which actually supports N sec 3. From the technology point of view the most interesting thing possibly for this group, this is an N sec 3 signing. It was only standardised earlier this year. The tools are quite new, leading edge. We are hoping that well, that's probably the minute limitation from the technology side in terms of stability.
Another issue that's possibly different from us from other registries is the org. zone is actually updated very quickly, we push out updates every minute or so compared to most TLDs which have a regular schedule in which they publish their owe mains. So this one minute interval is actually quite challenging it terms of signing the zone and the quantity of data we produce. Org. is quite a large zone. So these are the main issues we are working on. We are working not only with ISC for bind but also with he will net labs, we run NSD on all of our servers as well. NSD has actually had support since before the standard was published. So, we hopefully expect a few problems with that, although it's very difficult to tell because there hadn't been really any operational experience. We are in the early stages right now of talking with some people to organise a technology bake off for this stuff which we hope will happen around the time of the November IETF, and hopefully that will resolve most of the inter operational issues, at least in terms of transferring the data on the IX for A X site, and things like that.
As you know you see all kind of weird queries on the Internet. So this stability in terms of random garbage that you get is less easy to determine in a laboratory setting. We are going to be putting this stuff on to our production servers. We hoped to have a live demo today, but yes...
We are going to be putting it on our life servers over the next few weeks, so we will be working with some people who want to update their resolvers to participate in the test. You should be able to hopefully just change some of your configuration file on your caching resolvers and use the signed.org. It's not going to be very interesting because there is not going to be any DS records in T but there will be, as a friend and family programme comes on line. Before we put that into the main before we actually sign our normal production zone, we'll go ahead and put up a live real time test and anyone that's interested, will be able to contact me and we'll set them up.
SPEAKER: Thanks Shane. Okay. So as you can imagine, there is a lot of healthy debate going on right now with seasons, even the pros and cons of implementing it. While we believe it's a natural upgrade to DNS, there is a still a lot of discussion, a lot of fear and, certainty and doubt or Fud being communicated around DNSSEC. We also have a market education and PR effort around DNSSEC we all the Fud bust err series. We have a blog just to look at the Fud that's being put out regarding DNSSEC and we have guest blogers that come in and can provide some insight on you know, behind the Fud that's going on and to hopefully clarify, for the sake of moving forward, DNSSEC.
So, that concludes my update. I'd love to come back and give you an update on the additional members of the coalition. We have tomorrow gTLDs joining as well, some ccTLDs and you know, within another month or two, should have some of these projects completed and some new projects being undertaken and I'd be happy to share that with you again.
Thanks.
(Applause)
CHAIRMAN: It looks like we are still going on a slightly delayed schedule,. And the next person is, who wants to talk about the how this works will be explained to you by Amani Mohammed Bin Sewaif.
SPEAKER: You can hear me? Good morning everybody. I hope you are all enjoying your time in Dubai and have nice days.
Actually this is Amani Mohammed Bin Sewaif, I am from Etisalat UAE. Today I am going to present for you about the Gulf consultancy for back end trial and talk about the core project, infrastructure. How we deploy it in the setup.
The agenda of this presentation will introduce to you about the IDN projects. Then I will give you overview about GCC IDN project core. Then our goal and objective we achieve in these projects.
Also we talk about the technical part which is a focus a little more detail in this presentation. The IDN core project, we have the scenario. And we will talk about, we will end the presentation with the IDN back end infrastructure. So we'll talk about it in more detail.
I guess most of you know about IDN international domain name. It's a multi link you'll domain name that presented by local language character. Here in Arab, we are using Arab script. Non I think letter /AR is Arabic. This is a the common language for us in the GCC. There is a high demand also to have this ashic domain name because most of Arab users would like to use Internet and understand this technology and get familiar with the Internet.
Also, we'd like to demonstrate to the Internet global community like ICANN and ITU that we are familiar with the IDN technology and that we have already experimented with the solution.
Also, this will help us to speed up the implementation of this Arabic domain name.
We have here in the Gulf, we have Gulf and Arab stat, we have created a group which can experiment this Arabic IDN route, so the mission of this project actually to imtempt for Arabic domain name, so the community can have the time to express, to experiment the IDN root and also to early experiment the use of the Arabic domain name, identify their need, locate their problems and also they can set up the policy and standard.
There is a strategic objective for this group. We have established and implemented domain name. Also there is a committee, a steering committee and also a technical committee we have established in this group to increase our objective also to increase the use of the Arabic domain name. Also to let Arabic user expert the use of the Internet.
Also, we'd like to promote the Arabic identity culture you know. So the user can have the time to express and experiment this Internet content.
And this team group we have two structures. As we said in this, we have steering committee and technical committee. Also, the resources that each of these, we actually have 22 countries in participate indicating this project. So this committee most of them Hassall Kated ccTLD, Arabic domain and also they have communicated with the IDN root to add them.
The direction of this project, we have done this test bait, we'll keep continuing this test bed till the international community, you know, like ICANN and ITU recognise this Arabic TLD.
The participated countries, as I said there are 22 car ab countries to most of these Arabic countries, you can see it in this slide the participating countries.
So, I think now we finish the introduction part. Now we are going to focus more on technical part, which is the IDN core project we implemented.
So we would like to achieve from this project to have to provide IDN TLD Arab community 22 countries, many ISP would like to have simple set up, redundant and also to have this decentralised scaleable set up. Also to easy to trouble shoot. Also we don't want to have the set up different than the other set up as we have it now. Also we don't want to have any impact on the regular DNS. Also, we'd like to see no extra requirement for the end user. So, to have it only in the DNS server. Also, we'd like to see also concurrent experiment of regular DNS in the I DNS look ups.
So the I DNS project team have done any testses okay. We went through many scenarios. Some of them work, some of them we'd like to see a better solution for the community. Also we have to agree between the groups. This is the tests we have done and I'll go through each one of these, so you will see some of them work, some of them we just discovered because we didn't agree within the community till we reached the final solution which I will talk about it.
We tested forwarding to add also another second, we added a new TLD in the hint file. We considered also altering the bind code, but we will talk about it in more detail. Also we have developed a client plug in. As an alternative solution to the IDN. Also we considered merging the root zones. One of the things (client) we test indicate more, stub zones and slaving also, the last one we tested slaving every ccTLD zones in the IDN root.
One of the first scenarios we tested forwarding. This forwarding as you can see from this diagram, that forwarding to per zone to ccTLD, ISP forwarding to ccTLD T. As you can see it's impossible to manage 22 countries. So it's not easy task. It's hard trouble shooting those. I want to stress, it is also the further sub delegation is not possible. Also, this will limit the experience of the group because they will not have like real experience. So it's better to think about another solution. So another scenario.
So we skipped this.
The second one we did forwarding at a recursive root. As you can see from this diagram, we also have central, we have central IDN root, okay. You can see the IDN central root. This root receiving recursive requests, configuring zone forwarding, we did this task. We supported also further, this is supporting further delegation for bigger community. You can see there is a huge dependence on the root. So this was not good things. Also, it is different than regular DNS. Also, this will limit again the experience of the group. And as you can see, you need a very powerful IDN server.
One of the things also we considered some of the these idea we discussed to have a new TLD in the hint file. This will add we did by add ago new TLD in the hint file. It was easy to configure, okay, but the bind ignore non root enter trees in the hint file. It is ignoring T so it didn't work, so it didn't work for us. So we tried a different scenario. You can see this hint file. We add ccTLD and air course. This didn't work also. We tested we considered by altering the bind code, but we didn't do it actually because this require a lot of maintenance, so if there is some upgrade in the bind, so all the committee have to do this update. It's like consignment of responsibility. You have to accept across the community. No changes to be done.
We consider also having compliant plug in. We developed this client plug inby our team in Saudi Arabia, thanks to them we are developed this client. It was a very good plug inand you can download it on this site. You can see it in more details.
It was working also.
We have also considered merging the root zone. This is one of the things we considered which reconfiguring the caching server to the new root.
Also, we go rezone and considered a new root. Root transfer and the root zone and merging them into single one.
So this require updated regularly. If there is any change in the ccTLD, so we have to update also. And we need also to reconfigure the hint file. This is risky as you can see and it's completely dependent on the root. So this require also as you can see a great infrastructure, carry a grade infrastructure. Expensive solution, not trusted by all the community. So we didn't consider this. So we didn't think about it after that.
So, we explored more scenario. I think this also a little bit working for us and I will talk about it in more details in coming slides.
The stub zone. You can see this is a better approach forwarding because this that is no recursive queries. Sub delegations are possible for bigger community. This was also one of the things we liked. Trouble shooting also close to the normal DNS. Without root, you can see it is again hard to change in each of the ccTLD. So there was no ID node here, only using stub, so you can see this is the opposite of this forwarding.
So, how so simplify the management and provide similar DNS experience.
We tried to use another solution. So we tried to use a stub zone against I DNS root zone. So you can see here, we thought about having DNS record and a glow available and the IDN route. As you can see we considered having this stub zone. It is easy administrator and trouble shooting close to the regular DNS.
So, one of the things also we did, we tried to use a stub zone against the IDN route. Yes, it can be done. This is what we did. We have this master root zone. We added the DX NS, the Arabic ccTLD and the records. It is easy to administration. Trouble shooting close to regular DNS. So this was one of the things we tried. So it didn't work also.
Why? We will tell you now in these slides. How stub zone works in the bind. You can see here in the bind the caching getting the sub zone from the root and expecting the authority I have reply. So get the NS record, follow the NS, but the server is not authoritative as you can see from this diagram. So the root servers was not authority I have as you can see for the ccTLD. So this fails also.
So, from this, we thought about also another approach. By slaving every ccTLD zone in IDN root. This is a good idea technically easy for us. But the zone transfer was, there was a Joan transfer trust issue between the committee was an issue for us. Zone transfer was not supported by all the countries, so policies between the community was also an issue for us. You can see we would like to slave the zone from this all the Arab countries to the IDN root.
So, we reached the final design, we agree, this is the final design we agreed between the committee. As you can see, I want to show you that we have done this is the final design, we have no slave zone, no slave zone here and this is the same as the regular DNS, but what we have done here we have created many zone tore ccTLD which has this, so each country has this, this is the IDN root and the mini zone and we have the this root. So this was the thing which was working for the community. And it is working for us.
And then this is the /TARBG. This is the IDN root which we have like alternative route for caching) for IDN core projects and you can see these things, how this is like created it.
So the configuration required for the caching bind, this is what we did, we went to the caching name server. We created stub zone for the 22 countries, you can see the master IDN root. This is the caching stub zone and same master for all IDN roots. For the 22 countries, which is Arab countries.
It is caching bind same configuration for all. Pre defined, we added ones, same configuration for all of them as I said. Resolution close to the regular DNS. Distributed control. Easier trouble shooting.
This is, how wested Nominum. How stub zone worked in NOMINUM. We tested bind and now Nominum. Bind is a little bit different stub zone in bind than Nominum. It doesn't get to the ccTLD NS. It doesn't follow the ccTLD static tunnel. The switch only moving to the IDN root. But delegation work, which is good. Not useful for IDN root. Imagine /AORT uses bind. So we thought about bind also. Also thanks to Nominum, they have helped us by working around script in the case of the ccTLD.
This is the, I would like to say this is the global diagram, back end of the IDN core. You can see here there is many countries are adding, doing the look up to the IDN root. One in Saudi Arabia and one in UAE and all these countries are the 20 countries doing the DNS look up.
Finally you can see this demonstration. I just want to show you this is what we wish to have like in, like you know to have for Arabic users, to experiment with Internet use. We see here this is Arabic. This is /TK* you know in Arabic we are writing from right to left. This is us showing it to you for the left. He'd we'd like to have this one in the right side. We achieved it with you only within these 22 Arab countries F we are moving away from these 22 countries, we cannot solve it, we cannot browse this Arabic domain.
So, this is also the this is the ASCII code, we ever it in the DNS. (ASCII)
I think I reached the end of my presentation.
I would like to thank my group. This is not only this is only one team, this is only one team, there is many teams also worked on this project from different countries.
Would I like to thank Etisalat and hem add sad /AOU and also from our formal person general ab lean and the Saudi Arabia group, ride he will /TPAOEUS and ab /AOEL is that /PHAFPBLT this is the group behind this project.
So I reach the end, if you have any questions, please feel free to ask and if you think about this solution is good or there is an alternative solution, please feel free to discuss it with us, we are happy to discuss any new solution or approach.
(Applause)
CHAIRMAN: Thank you very much for this talk. I really liked especially to learn about all the things that didn't work.
SPEAKER: It's working with us now. If you go and browse these sites in Arabic it's working. I can show it to the people in the break time if they want to see.
CHAIRMAN: I'll take one question.
AUDIENCE SPEAKER: Olaf: What I didn't get, maybe I didn't pay attention well enough, whether this is an interim solution until Arabic names and script is available in the global root? It's a clarifying question? Is this an interim solution until Arabic names become available in the global root or will this continue to keep on working after that happens?
SPEAKER: No, this is like, as an you say a trial, till the ICANN route has approving this ccTLD in the original root. So we'd like to have this you know, because this project is working good in the committee, these 22 countries, so if we go away from these countries, this project is not do it not universal as an you say. /AO*ED like to see it.universal.
AUDIENCE SPEAKER: That is the way to go I think. It is clear that this demonstrates need and it is very important
SPEAKER: It is very high demand here in the these countries, we'd like to see these, you know.
CHAIRMAN: Again, thank you very much. And without further ado, you have seen some movement down here on the table. That was the sneak err e mail going for the final stuff about the NTIA statement.
SPEAKER: Okay. We try to get a little drafting group together yesterday, as an you probably remember to prepare some kind of statement that perhaps could be made on behalf of this working group and possibly the RIPE community about a response to the NTIA and signing the root. We came up with some draft text and then had a little bit of a discussion inside the little drafting group itself on the that discussion didn't complete until the working group was actually in progress this morning. So, the initial plan we have with this text has been kind of pushed to one side and what we now feel is the best way forward is simply for this working group here now to run through what we identified as an what we believe the core bullet points of what we'd expect to see in any kind of signing solution. And I'll going to run through these things very shortly and the intention will be is that if we have got broad acceptance that these bullet points are fundamental conditions are acceptable, the drafting group will then go away and try and distill this into a piece of text which will then circulate to the list, hopefully drawn today, and if we think this is acceptable, then perhaps we can then also have it endorsed by the Plenary session on Thursday. Again that will be a decision for the working group to take once we have had a chance to discuss it.
So I am just now going to run through these slides now. At some point Patrick might jump up and down and say I want to change some of the text because we have been working on this that's why Patrick and myself have been working backwards and forwards because we have been exchange things with US B sticks because we couldn't exchange it over the net. Anyway onto the points.
Fundamental point: The addition at DNSSEC is not going to to the existing processes should done in a way that is not going to jeopardise the existing deployment of DNS. I think we can all agree that that's a reasonable thing I hope we can. I don't see anyone objecting. Good. Patrick was getting up there. I was a bit worried.
Second one: Again, it is important that this deployment is recognised as an a global initiative and we should try to present it in that context. We represent a large part of the world with many countries with many diverging viewpoints and very many different ideas on how things should be done. We want to make it clear, this is a global thing and it shouldn't be seen as an being the property of a particular country tore a particular community or constituency. I know Olaf wants to say significant.
AUDIENCE SPEAKER: I don't want to say anything about this particular point but I'd like to propose for a little hum thing on each point so that we get a feel from the room how much support there is. Just a you know
SPEAKER: Okay, we have to also remember that there are people out in web land that can't really hum. We are going to have a couple of other points here. Peter and then Patrick.
AUDIENCE SPEAKER: First of all, I'd like to suggest because people didn't have the chance to see the bullet points in context that you run through them quickly, one after the other and then we discuss about the items one at a time going back and starting over from A.
AUDIENCE SPEAKER: I as want to point out that I already have a later version of this presentation, just because people that I showed this to that are much much more aware of the political context we are talking about. They have suggested the bullets to be in a slightly different order. And there are some slight actual individual words which are sensitive or nit picking and stuff. So I encourage people to, at the first round, concentrate on the overall meaning in the bullet instead of nit picking on individual words and that if it is the case that you have individual words that you are sensitive to, come and talk to us, because we already have newer versions of these texts.
SPEAKER: Okay. That you know Patrick. Okay, next point.
Is that we want a policy that encourages TLDs to participate in this exercise. We should end up with a procedure for signing the root that makes it difficult or awkward for TLDs to then present their keys to the route or IANA for signing and participate indicating a signed DNS root.
The deployment should be done quickly but not too quickly that we get it wrong.
Deployment should be done in a way that the organisations involved can be replaced or we can shift the functions from one organisation to another, that nothing is going to be finalised and set in stone that let's say for example, one organisation will always be the key signing key or hold the key signing key or always do the zone signing or the zone file updating or whatever.
Data should be moved between the organisations without appropriate authenticity or integrity checking.
There is /O no need to appoint a new organisation. We don't need to reinvent the wheel or engage yet more bureaucracy in this process. If we do that that's going to bring in all sorts of risks and uncertainties because it can change the trust model. Bring in more complexity, you know the rest.
The organisation that's responsible for generating the zone file should hold the private part of the zone signing key. That's self evident too. You if join the zone file you need to be inserting all the key records and the signatures that go along with that.
Any changes should be minimal as far as the existing process for receiving an auditing changes to the root zone. We shouldn't be suggesting a mechanism that is going to complicate that or introduce more steps in the process or even more bureaucracy.
Publication of the public part of the key signing key should be done as an wide as an possible. That's self evident.
And I think this is perhaps for me the most important point of all, especially my personal expressing my personal opinion. That what we are talking about here is data authenticity and integrity and it's not about control of the DNS.
Now we have had a chance to quickly one through all of those points. I am going to back pedal and let's now have a quick look at this and if you have any comments on the wording, if you think the wording is slightly wrong, please speak up and let's see if we can get a sense for consensus around each of these points in turn. Not necessarily the order they were presented it, we can try and deal with that later and I expect at some point Patrick is going to jump in with comments because he has got a later version of this than I have here.
Let's take point A, do we think this is kind of reasonable? And does anyone really object to that?
AUDIENCE SPEAKER: You can't pose an and question.
SPEAKER: Do we think this is reasonable?
Does anybody think this is unreasonable?
Patrick: I think when people have seen the bullets, people have issues or something can also go to the microphone. So, we move a little bit faster through this
SPEAKER: Okay. Are there any comments on point A? I guess not and it looks as an if we have consensus for that. Nobody seems to have any great concerns about this. Thank you.
What about point B, does anyone have any comments to make on that? No. Do we think this is reasonable? Okay. Thank you.
Point C, does anyone have any comments?
AUDIENCE SPEAKER: Peter Koch, speaking in personal capacity. You asked for nit picking. Here im.
The wording of encourage, although I suggested that myself, seems to be a bit strong to me. The intent of the bullet item is it should see not discourage and we also love delegation but in this case it's appropriate or I consider it more appropriate.
SPEAKER: Okay. Thank you, noted.
Patrick: There is a slightly longer revised text. Let me read it.
"Specifically it is important policy and processes are not such that TLDs in the world does not want to participate. Policies and processes developed should not be burdensome and encourage TLD operators to participate and share keys."
We can work on the word Smithing. The point is making.
SPEAKER: I think my personal feeling Patrick is perhaps the second sentence is clearer than the first.
AUDIENCE SPEAKER: My point was partially addressed by this and I was more going to refer to the specification, there are clearly two processes and one which by the IANA collects the information from the TLDs and generates an unsigned zone. The second one I think we are trying to address here is where this unsigned zone becomes signed. (Address) perhaps we should try not to stabilize things by having the second part influence the first part.
SPEAKER: Okay.
AUDIENCE SPEAKER: C seems to be somewhat in conflict I think with what was K about the existing process. If we could get those two together.
SPEAKER: I can only put up one page at a time here but I'll skip forward to K is that the one you want?
AUDIENCE SPEAKER: This one, I. So I and C seem to have some overlap that is potentially quite problematic. It might be better to combine these two items in a way that makes sense. Having these two things separated, you know, by some distance and having them possibly conflict is going to be a problem.
SPEAKER: Okay. Thank you.
AUDIENCE SPEAKER: Or even to go further, just remove point C. Because this actually does say what I think you said which is not to make it part of the future.
SPEAKER: Could we please try and keep our comments when you are making your comments, remember that there is another working group due in here in seven minutes. Now, we have got to try and get this thing done. If you can make your comments brief much. We have noting everything that's been said. Please make your comments and trust this drafting group to incorporate those things in how we word Smith things. Let's not try and edit this document in real time now. Because it's not a document.
AUDIENCE SPEAKER: In particular, I disagree with the last suggestion, although I can see that it would appear to be supportive of what I was saying. The encouragement for TLDs to participate and sign also needs to be part of this. Not, which is what I think is suggested in part of the NOI, preservation of process.
SPEAKER: Right. Patrick.
Patrick: Let me just say she short that this bullet about encouraging TLDs to participate in that kind of trust. The reason that popped up is because talking about trust in DNSSEC people, one person in this drafting group thought that we were talking too much about trust that the resolvers should trust the root. But we also need to talk about the trust that the ones that are supposed to pass their DS data to the root should also trust the root system. I just wanted to explain why it popped up.
SPEAKER: Okay.
AUDIENCE SPEAKER: I strongly support Patrick. Jim, I strongly support Patrick with these two sentences because it's really important, the process and trust. Key point. We should not miss it from our
SPEAKER: Noted Demitri. Thank you. Moving on to point D.
We want this done quickly but no so quickly that we do a half assed job or IANA and NTA do a half assed job. I think we can all pretty much accept that. Yeah, okay.
Deployment should be done in a way which is not going to cast things in stone. We should have the ability to change the organisations and perhaps at some point even change the process itself if that becomes necessary, if something better comes along, or whatever.
Patrick: There is suggested addition which is a clarification. "Key deployment must be done in a manner such that any change in participating organisationings does not result in a change of keys."
SPEAKER: Okay. A see a few heads noting with Patrick's texts, does anybody have any strong objection to that? Okay.
Next one:
"No data should be moved between organisations without appropriate authenticity an integrity checking. That involves checking the keys, the unsigned zones and is a forth. I don't believe anyone would reasonably want to object to this, but of course, if you want to object, please come to the mike.
Okay. Nobody does, move on.
/KW RBG there is no need to deploy new organisations as an this might slow down deployment and change the trust model.
AUDIENCE SPEAKER: I am Shane Kerr. I don't I think we should be agnostic on this point, so I would prefer this to be removed. If someone has a very clever scheme that can you see include a new organisation, I don't think we should necessarily oppose it.
SPEAKER: I think we also have to recognise, again speaking in a personal capacity Shane, is we have to recognise that if we start talking about new organisations, this is the kind of thing that might lead to a top heavy ICANN bureaucracy with some other Government steering Government or something pontificate being this.
AUDIENCE SPEAKER: Or it could be a sub set of an existing group for instance which is a new organisation which so, I think it's so that well, I stand by my original point.
SPEAKER: Okay. Thank you. Staffan.
AUDIENCE SPEAKER: For the pure DNSSEC deployment, I agree with G and with I which says more or less the same thing. That of course if we want to start to design the organisation, a new process, it will take time, which is not ideal. But we should make very clear that point that G and I are only for the specific case of the DNSSEC deployment and do not mean that we agree with the current organisation or current process. Because otherwise GNI could be interpreted as an an opinion, as an a concertificates tif opinion that things should always stay the same which I believe is not our opinion.
SPEAKER: Thank you. Moshen.
AUDIENCE SPEAKER: I think this point is very highly layer 9 and I don't think that we are in a position here to talk about organisations putting them or removing them. I think they are other places than the RIPE meeting to discuss about that.
Another I am really uncomfortable with the background of these proposals, because that means that at least we are not we don't dislike to have or maybe we are happy with what is currently done with DNS and it's maybe not the case at all for some ccTLDs who use another forum, maybe ICANN or whatever to explain that. So I don't think that the RIPE is in a good position to say whether it is good or bad to put yet another layer or to remove another layer. That's my feeling.
SPEAKER: Okay. Thank you Moshen, just before we go to Olaf. We are being begin an extra five or ten minutes, so we should be thankful to the ENUM working group who is going to be coming in here, we have got a little bit more space as far as time goes anyway. Olaf.
AUDIENCE SPEAKER: Is another way of phrasing or of combining your issue with this issue that the introduction of DNSSEC should align with the organisational model as an is implemented at should the line following the organisational model? Which is to say that the organisational model can change and that if that does change, that DNSSEC follow that. Word crafting is hard standing at the mike, but...
AUDIENCE SPEAKER: Moshen: My point is leave those policy layer 9 things to the organisations themselves to express whether they need to change the current or the future organisation model or not and as an a RIPE community, we need only I think tackle the technical things and as an expressed yesterday, maybe it's an expression of technical requirements for a solution for DNSSEC that's my point of view.
SPEAKER: Okay. Thank you.
AUDIENCE SPEAKER: Trying to bring these into the area which Moshen was trying to get this framed on. Could we perhaps reword these as an "Unless it is proven that from a technical standpoint, there is a need to create a different organisation, the solutions that can work within the current process, established processes should be favoured."
SPEAKER: Are the preferred option.
AUDIENCE SPEAKER: "Highly."
AUDIENCE SPEAKER: Lars Liman, I disagree with the motion regarding the RIPE is now a layer 9 organisation, we are quite qualified to have input there. And I suggest we follow Olaf's take on this, align it with the, whatever structure deals with the normal DNS stuff.
SPEAKER: Okay. Thank you. Can we take rough consensus around that viewpoint bearing in mind that we have got one or two people have got a slightly different take on that? We have taken note of the comments that have been made. Remember these are just initial discussion bullet points and we will try to accommodate all the comments that are made in whatever we can distill from that into a later document of some sort and we will hopefully get that out as an I say later today and you'll have a chance to comment on it at that time.
Point H: Please no one object to this, I hope. It makes sense that whoever is responsible generating the zone file should hold the private zone signing key. Yeah, please, yeah. Okay.
I think
AUDIENCE SPEAKER: I think it's good that we are laughing but we should not like hold other breath. So...
SPEAKER: We think here minimal changes that this process of introducing DNSSEC shouldn't disrupt or have a significant impact on the existing way in which updates the route zone process, for example, a change of delegation in the new TLD or whatever. Again I think hopefully that's something we can call agree but I see Kim going to the mike.
AUDIENCE SPEAKER: Kim Davies. I'll say I am terribly conflicted in talking about this, but I think the reading of this might need to be clarified if I get a sense of what you are trying to say. If you put the constraint in that it should be basically minimal change to the process we have today, I think that very clearly hones in on exactly one proposal that's in the NTIA document. That's the group's intention, that's fine, but I think with that constraint, it very much limits the way the root can be signed.
SPEAKER: Okay. Thank you.
AUDIENCE SPEAKER: This is what I was worried about. Minimal changes should not be the goal. I think the sense in the room that I heard earlier had to do with aligning the process to the way the protocol and operation works and there are significant changes introduced by DNSSEC that I think interfere with this minimal work.
SPEAKER: Okay. Moshen.
AUDIENCE SPEAKER: Moshen: I fully agree with what has just been said. Minimal changes to the way protocols work and as an I can read this, I can understand that we are, as an a community, happy with what's going on right now and we are endorsing something which many, many TLDs and I am not talking about .fr, are not happy at all. So maybe this is a way to hold all discussion indication other forum and say RIPE community doesn't have anything to say about the current process and Verisign is in a very good position to say okay, nobody is complaining. I mean, I don't want to dwell into politics here, but this is really endorsing what's happening today. So my point of view is, don't talk about the existing processes in the political way, but in the protocol way, of course I completely agree with what has been said.
SPEAKER: Okay. Thank you. I think Patrick wants to jump in.
Patrick: I just do a bit of clarification here. What we tried to say and it's my wording so it's my fault that the words are like they are. Let me just clarify what we were thinking of. We don't want the introduction of DNSSEC be a tool that people that don't like the existing process is using to change the existing process. Which is right now I completely understand it's a different thing on these words.
AUDIENCE SPEAKER: Liman I see two opinions here that are probably not competing. Let me try to introduce a new word here. That the initial deployment should be made in such a way that that's minimal change to the process. Then you can probably may stress that reevaluation of the process could be taken part in a longer term.
AUDIENCE SPEAKER: Olaf: The initial we are on a good track in that introduction should not fix ate the model into the current place. I think that is what Moshen is getting at. I think we all have a good fight at what we are trying to get at.
SPEAKER: Okay. Point G. I don't think there is anything here that anybody could reasonably object to. I hope so. But please, if you have got any complaints, go to the mike.
Okay. Final one: I think this is also one of these layer 9 messages which I think is very important, we have to try and convey. Because there are a number of politicians who will see this issue as an an issue of control and we have to say it's really about the authenticity and the integrity of the DNS itself. Patrick.
Patrick: I just want to point out that we have a suggested text that removes the two last words.
SPEAKER: Okay. I could live with it.
AUDIENCE SPEAKER: Stefan: This is a very good point, quite in line with RFC 1591, but it's completely unrealistic. I mean, if you don't want I am Monday the e mail working group may go list that we should concentrate on technical things, I am not going into politics, but if you don't want to see politics, to attach politics, don't work in the DNS.
SPEAKER: Okay. Demitri.
AUDIENCE SPEAKER: It seems for me that this statement, it would be more preferable if it clarified the DNS should be, not "Is" "Should be."
SPEAKER: Okay. Right, with the comments that have been made from the floor and I notice that no one has been talking from Jabber land. So I suppose we have a rough idea that we have got enough information for this drafting group to do a little bit of work later on today, but I think Patrick has to the a comment to make.
AUDIENCE SPEAKER: Patrick: I would like Staffan, do you have any suggestion on what to say instead of this that actually makes sense, that not only tell it to us at the group and here at the microphone and if the answer is no, that's fine.
AUDIENCE SPEAKER: Stefan: No text suggestion. Just one thing to keep in mind. This is a very good principle. It's like it's a very good principle. But don't mix principle with the current state of affairs.
SPEAKER: Okay. Thank you Stefan. Two more comments Liman and Olaf. Olaf first. Sorry Peter is in line as well.
AUDIENCE SPEAKER: It's not a comment, it's a question about what is the next step. Is it the intention, for instance, to bring this to the Plenary and see if there is Plenary consensus for this list of bullets?
SPEAKER: Okay my view is the that the drafting group will try and prepare some text based around these bullet points and the discussion that's just taken place. That draft text will then be sent out to the DNS working group mailing list, so that everybody on the list gets a chance to look at it, think about it, comment on it.
If we feel that we have got a rough consensus around that draft text, once it's been out to the working group we'll try to see if we can get some sort of statement made at the Plenary if we think that's a practical way forward. If the working group feels that's not appropriate. Of course we don't to it. That seems a reasonable way forward.
AUDIENCE SPEAKER: So that's 24 hours?
SPEAKER: If we can, yes, yeah.
AUDIENCE SPEAKER: Liman: In response to Stefan, there is nothing wrong with principles. I have no problems telling the NTIA that world peace is a good thing.
AUDIENCE SPEAKER: Daniel: I just walked into the room. I had to speak next door, I apologise. I think you should have a plan B. So plan A is whatever I haven't even followed it whatever we have here, the drafting group gets to make a proposal we'll see whether we can get rough consensus in the Plenary. If that doesn't happen, I think plan B should be that we try to get rough consensus on the DNS working group measures and make it to the DNS working group.
SPEAKER: Yes, okay.
With that, I think we should probably bring things to a close. I'd like to thank yap for doing most the for this session. I'd like to thank the speakers, saws an aand mar /TPHAPB nor the minutes and taking care of the Jabbering sore the stenographers doing an excellent job for translating the text into a meaning /TK FRG my poll seize we had some technical difficulties earlier on. Let's grab a quick cup of coffee and make this room free for the next working group which is due in here five minutes ago.
Thank you.
Applause.
** ENUM next�..side room 11am 29oct08
There anything anybody wants to add to the agenda at this stage? Jim is waiving his hands but I think he is scratching the back of his head. I won't be wants to add anything toy agenda so we'll go with this.
So we start with the noting the minutes of the previous meeting at RIPE 56 in Berlin. These have already been approved on the list. So this is a last, last call for anybody in the room to object. I am inviting people to raise their hands and object, and there isn't any hand going up, so those minutes are definitively approved.
And before I move on, I should mention that our co chair sends his apologies and greetings to everybody. He had pressing work commitments and couldn't be here this time.
So, we move onto the review of the action list. We have one open action from the previous series of meetings and that's action from RIPE 56 on Jim Reid to edit a guidance document regarding the operational problems and I'd like to ask Jim to let us know where that is at the moment.
Jim: Thank you Neil. I am sorry to say there is no news at all. There has been no input to me from anyone on the working group about this particular topic. I have not been particularly proactive in soliciting comments and that's a failure on my part, but there is a collective failure of this working group to do anything for it. So, could you please review this particular action item. If you have any comments to make about it, please e mail me or have a chat with me. I am more than happy to listen to any comments that people make, especially if /TP* it involves alcohol. And at that point then we'll try and get a document put right. But my job here is to edit this document and not produce it. And I can only edit the document if people give me text. So please, working group members, can I have some text? Speak
CHAIRMAN: So we'll keep that action item open and we have a plea from Jim: Send text. If none happens by the next meeting, we'll see at that stage and make a decision whether to keep it open further.
And now I am happy to invite Danesh Babutta from UK EC, UK E numb consortium to give the main presentation of this morning. And perhaps somebody from the meeting organisation can help us find which button we should click next.
SPEAKER: Morning everyone, anyone who was at the party last night probably feels the same way I do.
Anyway I am here to probably give, well actually give an overview what we have done in the past was just given updates. But seeing as an there is some new faces here I thought I'd give a full overview of where UK EC came from and where we are headed and how the UK ENUM industry is moving forward.
So, basically back in 2001, there was a D T I ENUM workshop meeting, department of trade of industry, and this led to the formation of the UK ENUM group. Basically an informal set of people who just got together informally and wanted to be representative of / PB industry, there was no legal status, no membership and it was done on a best efforts basis by everyone. It was fairly open and transparent. People were invited for comments and anyone could contribute if they wanted to.
So, what the US ENUM group did was they defined roles and responsibilities, interfaces, the governance models came up with the accreditation validation models, various things like that and they ran a trial which was quite successful in 2003, which actually prompted the DTI to go ahead and proceed with commercial operations of ENUM and give the go ahead for that.
This again gave birth to the UK ENUM consortium which we call UK EC.
So UK EC was actually lowliey formed as an a non profit limited by guarantee company in October 2006. There were four interim directors who did some great work on this. They ran the thing for a whole year and a half before passing it on to the current directors. It is recognised as an an oversight governance body for ENUM in the UK. On the side I have written regulator, but you must note it's with a small R, we are the governance body for ENUM in the UK and rerelate in soft terms the registry operator. And we are actually awarded the tier 1 registries operations to NOMINET, the .UK registry for five years.
The structure of UK EC is it's one member one vote. It's a member based model. We believe in self regulation. We want the industry to guide us. And the membership fees depended on what your turnover is. We had an AGM on the 25th March and four initial directors were appointed with the four interim directors standing down and we had twelve members to start with. At the moment we only have about 15, so we'd like more.
After the AGM, because we were four brand new directors, had no real idea of what had actually been discussed internally by the initial directors, by the interim directors, sorry, we had meetings with them and there was a transfer of responsibilities and knowledge we got to know where they were coming from, what the actual history was. And we also appointed a representative from NOMINET to our board.
We also didn't have a secretariat at the time so an interim secretariat was appointed and we started the outreach meetings going to ICANN and RIPE meeting.
How we operate is we have weekly conference calls between the board. This is basically just updates of what's going on, keeping an eye on what's going on. What needs to be done, discussed, do we need to say anything, do we need to go to any meetings, so on. We have monthly board meetings where we pass resolutions.
At the moment, it requires a full quorum of directors to pass any resolutions. So, at the moment it's that's five directors need to be present. So if one goes off ill. It just means they've to postpone things for a short while. That's something that we are probably lookingality for the future.
We also have a monthly joint review committee meeting. Now the joint review the JRC as an we call it is two members from NOMINET and two members from UK EC, although I have also been asked to join that from time to time. And we just talk about NOMINET operations, the way that NOMINET are going forward and they try and understand where UK EC are coming from and we try and keep a very very it's a very informal committee meeting, but we just try and keep in touch with each other.
And then the secretariat deals with you will a the paperwork.
What's NOMINET's role? There seems to be some sort of confusion with what NOMINET's role is in the whole thing. I just wanted to make it clear that NOMINET were given a five year contract by UK EC to run registry operations. So, what they do is they pay us an annual fee for keeping the contract and a proportion of each of the registrations of the ENUMs come to UK EC as well and I believe that's 10 percent of the registration fee comes to us.
So, NOMINET deal with all the UK ENUM registrations, all the technical side of looking after the name servers for ENUM. That's what they do and marketing and PR. We have got a two tiered system. We have got the business enterprise regulatory reform department, the DTI, they sit on top of all this. Under that you have got UK EC, who deal with you will a the policy. Governance and various over bits of documentation. And under that you have got NOMINET who do all the registry services.
So, what to we do this summer then? It was a very, very busy summer because we were looking at launching ENUM services at the end of the summer. So, we noticed that under our governance model there was no policy advisory group that had been formed. It was quite difficult getting people together. So we wanted to be a bit pragmatic about this and what we did was we went to the old UK e.g., the UK ENUM group guys and and asked one of the people from go to see if he would be willing to be an interim chair and get together an interim policy advisory group. So Tony homes from BT quited gladly agreed to do this and he is now looking at disputes resolution, locks dates and EU data protection. We are probably going to pass various other things on to them.
Now the interim policy group is only there for a period of six months. That comes to an end in February and we are actually looking to create a proper policy advisory group, moving on from then.
So in anyone here would like to join that, then we'd quite welcome applicants.
We also delegated 4.4.E 164.ARP A. We had various consultations. There was a registrar contract. There is the validation agency contact. The validation agency policy etc.. I'd like to mention something on the validation agency side.
Initially, we were thinking of having a policy on validation agencies and authentication agencies. I'd also like to explain the difference here slightly. Authentication is the process by which one identifies the identity of a person or organisation and validation, on the other hand, is all about validating whether the number or the number block belongs to that person or organisation.
In the end, we decided not to look at ought thencation agencies and not come up with any policies on that because we believed that the.registrar or the company registering the ENUM domain on behalf of the customer, the end user, would do the authentication themselves. They are best in place to do that because it's their customer and they are best to authenticate who the customer is.
So, dropped the authentication agency bit and just went with validation agencies.
So, NOMINET launched services finally on the 7th October. However, it was a very soft launch and the reason for this was that no one actually came forward (soft) to be a validation agent and without a validation agency in place, none of the numbers can be validated so no one can actually register any ENUMs. It was a soft launch and NOMINET then invited registrars to come and become registrars with a view to doing a proper launch sometime at the end of November.
What we are doing now is the validation agency contract was written by me and so it's now been packaged into legal speak, so it volumes all the English laws. And we are also working through a complaints procedure which passes on to dispute resolution. There wasn't because we are fairly new to this, there wasn't actually a complaints procedure in place and as an we are go along, we are learning. And finding that there are some other things that need to be done.
And because there is no validation agency in place, we have also requested UK EC have also requested NOMINET to be a validation agent of last resort. And they are now doing a feasibility study on this and we are wait to go hear from them next week.
Also, because there is an interim secretariat in place, we need to appoint a proper secretariat in place and we have gone out for tenders and we have got some sonses and we are going through those now.
We'd like people to get involved, to you don't have to be in the UK, you can be anywhere. If you are part of the industry, then you can be a member. We'd like you to be a member and you can contribute to the UK ENUM development and the way the industry moves forward. You can also become a policy advisory member, policy advisory group member and for that you don't actually have to be from a member organisation. So if anyone would like to get involved, please do see me.
Otherwise you can get involved, become a validation agent of course, we'd like some of those. Or you could become a registrar, I can point you on to NOMINET.
And you know, just as an an enticement / BGS I am sure that we can give a discount on the membership fees for anyone attending RIPE. If you'd like to, please see me before I return home tomorrow.
So, that's the end of the presentation. Are there any questions?
CHAIRMAN: Are there any questions? Don't all rush, are there any questions? Remember to declare your name when you come to the microphone.
AUDIENCE SPEAKER: I am certificate gay /PE trough. E 146 is a resource, it's a number such as an IP address. Why you can't use base such a RIPE
SPEAKER: Sorry, I didn't catch that.
AUDIENCE SPEAKER: The number is a resource. In some countries such as an IP numbers resource. Why you can't use some database for IP validation such as an RIPE database numbers?
SPEAKER: Okay. Just to be clear, what you are saying is why are we doing a validation on the IP just to clarify, you are asking me why are we doing a validation on an IP address, on an IP resource?
AUDIENCE SPEAKER: No, no,. I think you can get a number in large blocks, not for personal not for personal one, and can use number in plain for validation of authority.
SPEAKER: Right, I am trying to get hold of this. So you are asking us why we need to validate a number? No, sorry.
AUDIENCE SPEAKER: We can see /16 belongs to, for example, some LIR. We needn't follow a validation for end user, why you can't use a validation in a large block of phone numbers?
SPEAKER: In the UK we have different Telco providers who give out different number blocks. So what we need to do is we need to validate well the way that we are doing things is we need to validate that the number actually belongs to that user. So validate ago number block belong to go a Telco is not the issue. The issue is validating the number that, or the block of numbers that belongs to an organisation, because there could be disputes arising for example, we don't want let's take myself for an example, I wouldn't want somebody else registering an E number that is my number.
AUDIENCE SPEAKER: Thanks.
AUDIENCE SPEAKER: Chris Buckridge from the RIPE NCC. There is a couple of questions from car conshe have another who is the ENUM working group co chair. The first is where do you see plus 44 ENUM going compared to other countries?
SPEAKER: Interesting question. I am personally not entirely sure of the immediate future of this. Long term there are various ENUM applications we are hoping that people are going to come up with various ENUM applications which are going to take ENUM forward. There is various public relation things that we are doing and making people aware. Right now in the UK people are not really aware of ENUM. We talked to them about ENUM, they go, well what is that? And you then have to go through a whole explanation, ex complaining what this is. The vary yours other directors within UK EC do go to other meetings at places like Internet world, and we are just raising awareness like now. What we are hoping is where it's going to head is it's going to have major, major take up.
In the short term future, we believe that it's going to be mainly the organisations that are going to take this up and I'd say from my own point of view, within a couple of years or so, is when the end user population is going to probably take it on.
AUDIENCE SPEAKER: And I guess a follow up question is: Is crew, CRUE available in plus 44 ENUM?
SPEAKER: Yes, NOMINET are working on that and we are going to get an update on that next week.
AUDIENCE SPEAKER: I think in relation to his first question, he follows up and says: In terms of registration figures etc., I mean we have not seen steep figures yet across the board."
SPEAKER: No, no we haven't. Any other questions?
CHAIRMAN: Thanks very much den he shall. So now I'll call on Anand Buddhev from the RIPE NCC to give a report of the tier 0 ENUM operations. While he is setting himself up, I'll just test this other mike, it seems to be working.
SPEAKER: Good morning ladies and gentlemen, I am Anand Buddhev, manager of DNS services at the RIPE NCC. And I'll be giving you a quick update on what's been happening since the last RIPE meeting.
Just a quick overview. The RIPE NCC runs or manges the E 164.arp aJoan. We have been rung this since 2002 and operations are very stable. On the 26th November last year, 2007, we actually signed this zone as well and since the 25th March, we have been accepting secure delegations.
There have been no changes to this zone since RIPE 56, as an in no new delegations. Of course some name servers might have changed, but there are no new delegations.
And of the current delegations, only two of them are secure.
One of the things we have been looking at recently is lameness in the ENUM zone. We have a project running at the RIPE NCC which probes name servers and checks to see whether they return authoritative answers or not and this lameness project also queries name servers in the ENUM zone and we have found that of the 45 zones in total, 8 of them actually have at least one lame server. So this, in our view, probably affects operations in some way.
We have also been looking at queries coming in from undelegated zones. We did capture some data between the 8:and 21st October this year. We used a tool called DNS cap to capture EXX responses sent out from the RIPE NCC ENUM server. Then we processed the result in captured data with DNS stop it figure out which were the top results. Our data showed that plus 1 for the USA and Turkey and India and Portugal were among the top queried zones.
Just a point of information here: Plus 1, that is the USA number, was delegated until February this year and it was then removed from the zone (Plus) and this is a pie chart showing our results. You can see there in red, that's the USA, Plus 1. The section in green is 90 for Turkey. And then next to that in a sort of light purple is India. One interesting statistic out of this is that there are some, or rather significant number of queries for 0, which is the international dialing prefix in many countries, a a few others, Pakistan and Bangladesh also stand out.
And finally, a little note about DNSMON. This is not one it's run by our colleagues in the DNS information services. They have made some improfits to the stability. There is IPv6 supports DNSMON now and very recently chef also introduce add single sign on. This is so that you can use just one user name and password to log on to all the services of information services such as an DNSMON, MyASN and so on. They have introduced real time alarms for things like packet loss and response times. And very interestingly for this group, there is now a separate category for ENUM, and that's 500 euros per year. If you have any questions about this, please see my colleague mark, he will be happy to help you the
And that concludes my little presentation. I am happy to take any questions that you may have.
AUDIENCE SPEAKER: Peter Koch. Thank you for the presentation. Regarding the undelegated prefixes, I am concerned a bit about seeing the 0 in there so promptly, if I remember correctly.
SPEAKER: Yes.
AUDIENCE SPEAKER: Peter Koch: This seems to be a severe bug in the application really, right? Unless you have indications that somebody is like fat fingering and doing manual queries which I guess isn't the case begin the numbers there. Do you see any chance this /TPH* doing some deeper research, what application is behind that and might get rid of these queries, not that they, I suppose, are operationly risky, but just to keep the Internet clean, right?
SPEAKER: Well, operationally of course they cause no problems (operationly) and I am quite happy to analyse it further and figure out you know where these queries are coming from and you know, what sort of things people are trying.
AUDIENCE SPEAKER: I mean despite all our efforts it's an early deployment phase and some feedback to vendors might prevent bad things happening in the futures, so that's just a suggestion here. That you know.
AUDIENCE SPEAKER: Chris Buckridge and there is a couple of questions from Jabber. When you looked at lameness were any countries showing all name servers as an lame?
SPEAKER: No.
AUDIENCE SPEAKER: And car ten again asks again the room, are there any participants from Turkey, India and/or Portugal present and if so maybe they could give us an idea about the status in their respective countries as an it seems there is potential.
SPEAKER: So cars tonne is looking for representatives from Turkey or Portugal to perhaps to say the status about ENUM in their countries? Any volunteers? It doesn't look like we have anybody from these countries. Does anyone have any other questions or comments? In that case, thank you very much.
CHAIRMAN: Thank you Anand, that was very informative.
(Applause)
Now for a few words from me about a project that's been running since before my time as an co chair of this working group. It was started by Kim Davies a number of years ago and he kindly continues to host the server where this resource is kept.
The ENUM data .org list or page is a per country report on ENUM status in the different countries. It depended on input and updates from the people responsible for the country codes involved. It's not something that we invent ourselves. At the moment, cars tonne she have another and I remember doing the maintenance while Kim is still hosting, providing the hosting and the URL for it is there.
And here is a pie chart of the current status. We have information about not the 45 that Anand mentioned but a further nine that we know about that either been removed from delegation or which have been, which have a status of objected, that's to say that they haven't gone through the administrative, they have failed at the first hurdle before getting to the stage of being delegated. We see 8 production country codes. 3 are in a status between trial and production which is we have called hiatus. 5, we believe are in trial. A number of others, 28, quite a big number, are delegated but haven't advised, haven't announce that had they are in a more advanced stage than just delegated. So it looks like they are preparing to start a trial. 3 are not delegated, including, for example, + 1. And then 7 are objected, and that's the current status.
I'd encourage all of you to check the page and /SAO whether the information for your particular country, in particular, if you are part of the group of organisations that are closely connected with ENUM in your country are actually up to date and let us know by e mail to, so yap ENUM WG chair so that we can take care of it.
And we do appreciate your help in keeping this piece of information up to date. It's only useful if it's up to date and I'd like to thank you in advance.
And I guess there probably aren't any questions on that. So I'll ask Ondrej Filip to come forward and tell us about the ENUM federation. (+ is the plus sign)
SPEAKER: /TR*UPB very much. I am working for CS NIC, I am speaking on behalf of an organisation called ENUM federation.
It should be another industry association in NIC) of campaigns that are involved in the ENUM. I think I will just repeat the things that are probably presented meantime in this forum. ENUM is very complicated things for normal people. They really don't understand what does it mean? Just do you understand ENUM. It's very hard to identify tools, software, hardware, any pieces that can run ENUM and what's that actually?
VoIP for many people means a lot of things F we take the premise that it's tied with the VoIP, then many people don't differentiate between Skype and other technologies.
Another thing that was repeated many times, people don't want the technology, they really need to have some solution, so and in many countries, I think we have eight in production phase now, we face the same problem. So that's why we initiated an organisation called ENUM federation.
The goal of the association would be to promote ENUM products, to create some brand that would be similar to things like Bluetooth, wi fi, well recognised brands. So we would like to create such a band for ENUM enabled products which can be a lot of things, coal bee phones, all registries and other things. So that probably a whole bunch of much brands which would be very similar but maybe differ a little bit in consol. That's the goal of the association so we will see.
We would like to create some websites and database of those things and we would like to coordinate on a campaign, so to prepare some campaigns how to promote ENUM and then execute it /HROEBG locally. We don't have ambition to be globally T should be more and more coordination about it.
So the current status is that the organisation is almost established. What that means, there are 5 ENUM registries or technical operators that signed memorandum, so it's the Austria, Czech Republic, Germany, net err lands and Great Britain. Currently we in working on other legal stuff, so the signs and we are waiting for the registration.
The association will be based in /PRABG in the check republic and we are just waiting for the registration now, but basically we are ready to start. (Prague) so, the major work will be hopefully done in the next year, so we, in the first quarter, we think we will work on the visual identities and all the marketing stuff around. And then we will continue with the website and hopefully we will be able to start some campaign.
We are open for new members, so if you would like to join the initiative, just feel free to contact me or the Pavel, so me or Pavel or and we'll help you how to go about it.
So that's it. Do you have any questions?
AUDIENCE SPEAKER: Christian: Are you looking to develop a branding that suppliers will use or are you looking to develop branding that ENUM registries and registrars can use themselves? Because the two are rather different I would have thought.
SPEAKER: Yeah. Actually, all of them. So of course, it would be great to have some logo that would be understandable for people that's /KWAOEUD hard sure, but we would like to have (quite) an ENUM enabled phones, so a brand for such phones and we would also like to have brands for software and also the registries, registrar, etc.. So the plan is maybe too broad, but the plan is to cover all those things. But you know, we know that's quite ambitious.
AUDIENCE SPEAKER: Chris Buckridge from the RIPE NCC again and there is another question from cars tonne, for Andre. Are there any further prospects besides the founding members?
SPEAKER: He probably meant the new members? There are, I think, three registries, I don't want to name them because I didn't speak with them directly, but there are three other registries that are planning to join, yeah.
CHAIRMAN: It seems there are no further questions, so I'll thank Ondrej. And move on
(Applause)
CHAIRMAN: While we are still at short news, there is an opportunity for anybody who didn't put their short news item on the agenda to stand up and tell us something about ENUM in their country, if it's short. Nobody is rushing.
We have nothing from item G, because we didn't have an ENUM related Plenary presentation this time around.
So we move on to item X, which is interaction with other working groups. Now, the Address Policy Working Group has a proposal before it to, involving Anycast for ENUM Tier 1 operations and indeed, ENUM tier 0 operations, and that document was discussed earlier in the week, and seems to need further work. If people want to take the opportunity, because we have sometime now to continue that discussion here, the opportunity is there.
People are really trying to compensate for missing their coffee break earlier. In that case, we'll move on to item Y on the agenda, which is any other business:
And everybody is deep in their e mail. They have other business, but not for the working group, I guess.
And so, all that remains for me then is to thank, is to summarise the action items. We still have one open action item from the previous meeting. We have dealt with that already.
To thank everybody for coming. To thank you our hosts, the hotel, Etisalat, to thank the people who have supported the meeting, one of whom I forgot to mention at the minuting and that's the meeting recorder. To thank Ruben and Chris and Natalie and all our speakers and to let you go a little early to lunch. Thank you all.
(Applause)
The session concluded.