These are unedited transcripts and may contain errors.

ENUM Working Group session on 5 May, 2011, at 2 p.m.:

NIALL O'REILLY: Is this working? Yes, this is obviously working. It also confirms the stenographer's sense of humor.

Good afternoon everybody. This is the RIPE ENUM Working Group. If this is not where you thought you should be, you should go to the other room. My name is Niall O'Reilly and I'm on my own. There was a calendar clash and Carsten can't be with us. Another person who can't be with us today is Lino Santos in Portugal, who's given me some information which I'll be presenting on his behalf later on. There's some housekeeping announcement. If you want to ask a question of one of the presenters, only do so on the microphone so it can go out over the webcast and into the archive. We have a whole team of people whose names I might not remember. There's Alex, our scribe; Chris, who's looking after the Jabber or chat; Anna Papa Murphy from Doyle Court Reporters and Sander and his colleague on the sound desk. So I'm going to go through quickly the reference to the minutes of the previous two minutes. There were late corrections of RIPE 60 which have now been made and I'll be making a last call for those minutes in the near future, and also the minutes  there was some strange problem with the minutes of the Rome meeting which only very late became ready and I've had a bunch of corrections to those already and I'll make a last call and that brings us to action point 1, to see the last calls for those minutes are put out in the near future. The action points from the previous meeting, two of them have been done in that the clarification we needed for the RIPE 60 minutes is now down and it's been arranged a presentation to be given later today. We still have one open action item, and we will be working on preparing a panel discussion, an interactive as much as possible at the Working Group, the next meeting of the Working Group in Vienna. That brings us to more or less all routine trivia. My calculations, which are suddenly hidden on an iPad whose battery has stopped working, we're tight for time. I'm asking the speakers to go 5% faster. I'm going to shuffle the order because Pavel has an early flight and he's anxious so I'll ask him to take the first slot and then we'll work through the rest of it in the order shown. That's it from me for now.

Pavel: Good afternoon. My name is Pavel Tuma I'm from CZ.NIC. I'll try to be faster than I was supposed because I was supposed to have two presentations and I squeezed them into just one.

The first topic I'd like to speak up is the update on 024E164.arpa then probably something more interesting, which is the talk about the new use cases for ENUM which may have emerged. So this slide would be nothing surprising as the same evolution or roughly the same evolution happened in all ENUM countries. Since the start of ENUM service the number of domains rose to a certain point because at least some of the providers are very interested in at least trying ENUM. Then the number remained the same and unfortunately in our case, when those priors abandoned ENUM, the number has dropped almost to zero. If you look at those providers, you will see that the market disappeared completely because they started five registrar ENUM domains to check ENUM. Basically this one is the only one, at least small and mediumsized voiceover carrier in Czech Republic. This was May 2009. If you look at the same picture today, it's much lower and the columns are the same registrars.

So to summarize the development, we had three voiceover IP carriers but just that one make. There are still some private numbers in ENUM, and what is clear now and even before there's a real low interest in ENUM for routing the calls.

What I had to say that  looks like it's not a proper version of the presentation, but anyway the last point I was about to say is CZ.NIC doesn't plan anymore to support ENUM in the meaning of some kind of promotion or marketing. We are definitely not going to stop the service as some other registries consider it, but there will be no more promotion.

So what are the other uses for ENUM, if there are any? What I see as the new opportunity is this, the smart phones. People have the smart phones, these are almost regular computers. Everyone is connected over some mobile data network. This is probable the source that I think most of the opportunities could come.

Some of them or some application already emerged. We have ENUM [droid] for android phones for Nominet. Basically if you dial the number, regardless if you dial the number or select something from your phone book, you dial, it does the NS query and displays on the screen the result if there are some ENUM records found, you can select whether to call over it or over the phone or if there's a web page or email you can use that.

There's a brand new ENUM discovery application from .NL from SIDN. I'm sorry I wasn't able to manage that to the functionality state, but so far what I know, if you dial the number, again on android phone it will try to suck out the information and you can add that to your phone book in the phone.

But there's something else. We were approached by 1800 phone word which is the association of toll free line providers in United States regarding the corporation of ENUM deployment for usage with tollfree numbers. The reasons, what they see as the opportunity is the tollfree line call can deliver only the phone call, while the smart phones are able to do much more.

And the situation on US market is that US carriers are abandoning the flat fee mobile for data charging as we can see the press releases, they're going to switch to pay per use charging.

And the propositions from 1800 phone word were to use ENUM to develop multi media content to those ENUMenabled smart phones and to use ENUM as a tollfree mobile data enabler, meaning that the data transferred to the smart phone will be charged the same way in the phone world, meaning that if you download something, it will not be charged to you, but to the service provider to that web page provider as with a regular tollfree line numbers.

So what if the usage could look something like this. You dial the number and on the background the DNS query send some ENUM records are found and basically it can display some kind of mobile application for toll free lines. You can easily imagine that if you're calling airlines, you can check your booking by that application instead of waiting for the operator on the call. Or it can be used as the advertising in the same situation, you call the tollfree line, there's an IVR, you're waiting to be connected to the operator, you can watch some advertising.

So these are, basically, the opportunities we're talking about with 1800 phone word. To the operators of tollfree lines it can save the cost because if you have used that kind of web application to check your booking, it's definitely cheaper than the call itself and labour of the operator.

And you can advertise you can show your products while the customer is waiting for something else on the IVR.

We have discussed that in ENUM federation and I discussed that with relevant NTTs on the Czech market and we see some opportunities with that. Generally the opportunity with advertising can be related to any phone call, it doesn't have to be just the tollfree line. The advertising could be as well an enable for some kind of special offers. The idea which came up was for the carriers for the mobile or VoIP carriers, if they provide the advertising to the end user, they can offer him some kind of discount, et cetera.

And we were discussing what I call personal broadcasting, if you call your friend, you dial his number, you can see, well, the phone is ringing, you can see on the screen his latest Twitter feed, join his link on Facebook or something else. But, of course, this is  everything I've just talked about is just on the paper now, so there are a lot of questions. I have here the most serious ones. This requires some kind of standarization how the phone will behave once you dial the number and it sends the DNS query. The question is what will happen next, is there a user story how to use that kind of functionality which fits everyone? We don't know yet.

The other problem would be whether this functionality should be stand alone down load application or hard wired to the operating system of the phone, the pros and cons of both are quite obvious.

And the other problem we can see is the question whether all the interest of all involved persons are aligned, specially in the situation of advertising, because the interest of the carrier in here would be to display the advertising while the end user probably doesn't want to see that much of advertising and it's more complicated because here are not just the carriers and end users but service providers, registries, registrars, a long list of parties.

And of course there's one big question: Which probably nobody has the answer to: Whether the phone numbers will be used as the identifier and this is even more serious with the smart phones when we have the whole functionality of the computers like you have in front of you. We have the apps, we have everything. And, of course, all the smart phones have the fullsize keyboard so we can type really easily whatever else than just the phone numbers.

So that's basically it.

Any questions?

NIALL O'REILLY: I have a question, Pavel: Do you have a project ready for exploring this question that you yourself asked about where it would go next?

SPEAKER: We are in the process of that. We're trying to set up the prototype environment with 1800 phone world including the application which will try to answer some of those questions which will have the defined functionality. Probably, it will be used just for these two use cases I shown to display some sort of web application and display some kind of advertising. But it's ongoing still.

NIALL O'REILLY: Watch this space?

SPEAKER: Yeah.

AUDIENCE SPEAKER: Have there been some discussions about taking some interactive application influence the queuing, more information from the customer to go to the right queue and this kind of stuff or has this been a topic yet?

SPEAKER: There have been, but just at the very beginning because definitely what we think the applications can benefit if the user supplies some kind of information with the query, maybe not with the DNS query but the HTTP query which will be found in the NS.

NIALL O'REILLY: Any further questions? Let's thank Pavel in the usual way.

(Applause)

And introduce the next speaker, Terena is the umbrella group which provides the framework for the national reserve networks in Europe. Parallel ENUM that the national reserve networks have set up.

PETER SZEGEDI: Thank you very much for the introduction. Can you hear me well? So my name is Peter. I was invited by the cochairs to talk about the NREN net service. Here's the outline of my name. I saw some enrum participants in the room. Maybe you don't know much about Terena. I'd like to talk about the history about NRENum, give some service principles, show the architecture you are and get a status update of the service and the future plans. Few words about Terena. It's the transEuropean association of the European [ENRUMS]. So it offers a forum in to collaborate and share knowledge. It's a collaborative organization and we have the members. At the moment we have 39 national members, the national reserve organisations, we have some Internet national members and we have other members, the backbone network for European networks.

Of course we have Internet national peers, similar organisations around the world, Internet 2, APAN, CLARA, and we have many other affiliated communities I can mention EGI or EUNIS, and many other organisations.

So this is what we call the community, the Terena community, when I talk about that, I talk about the community. When I talk about Terena secretariat I talk about the people located in Amsterdam. There's a small office in Amsterdam, roughly about 16 people who are the employees of the Terena secretariat and that helps maintain this community. What we do, we have different activities, the major ones are listed here. We have Terena compendium which is printed information about the members. We public it every year so it's not just a snap shot, but you can check the privacy versions and the technical and none technical aspects of the activities around the world. We have one big conference per year, the next one will be held in Prague in two weeks. Aside of that we have smaller meetings, seminars. The most important things, that we have task forces, those are the groups where we discuss about the various topics, about networking, about storage, about other issues, because the task forces we have other small projects. And there are services for the community, and NRENum is one of our services. You can find everything on the website. I'm here now to talk about the NRENum.net service. The service was initiated by switch. Bernie, one of the initiators is here, to provide countries where the golden ENUM tree is not yet available with the possibility to publish ENUM data. It was initiated around 2006, around September but it was initiated before, but that was the first date that I found officially minuted in some discussions because between 2000 six and 2008, Terena task force, which was caused task force and enhanced service communications looked after this and that was an introduction period of that service. That task force was finished at the end of 2008 and during 2008 there was a discussion about continuation of this service because that trial was successful and found useful so there was a kind of discussion how to continue with this service. It was agreed that Terena secretariat and the community will continue with this service after the end of the task force. And eventually in Jan 2009 it was agreed that the Terena secretariat which ensure the continuation of the trial service for two more years at that time. And that two more years ended at the end of 2010 and the beginning of this year we started discussion what to do with the service, of course. And all the service participants agreed we should continue with this service and also try to give this opportunity to all the NRUM to try this service and we agreed again to mandate the service two more years and now officially we'll run by this service by the end of 200012. The beginning of two 13 we'll discuss again and check all the environment again, if it still  if the service members still want to continue with this service.

So what is this service and what are the motivations or behind it when it was initiated? At that time the golden tree was not available in many countries and there was the basic question who will be or who is the TIER1 registry for each countries? And of course taking the fact we have this community, it was initiated to create a private tree where the registry can be the [NREN] and we considered that as an migration path towards the golden tree. So the nrenum.net is a voluntary effort and this community is wellestablished, based on trust, maintained by the secretariat, so it has all the features to make the service successful in that the NREN is can be the TIER1 registry for this service and they can operate the route DNS for this service of course. And then the NRENs can subdelegate to their customers and the national reserve institutes.

What are the service policies? We have a policy document available on the website, on the service website and it basically says that the delegation are done only if the following terms apply, which is, of course, if the golden tree, the e164.arpa is not delegated, even if technical is delegated by the official service is not operational, not in a production stage that's another option, even if in production stage but other issues, for the NRENs that makes it difficult for them to delegate their zone into the golden tree that's another option.

If you check the technical details, the zones delegated, they have to be configured correctly, which is an obvious requirement but it actually says that it's the NREN's responsibility if the DNS is configured in a correct way. You can see the service architecture. I put the link there, if you down load the slides you can check the policy document. And the service is run by the community, as I said, so what the Terena secretary does is run the website, which is basically con influence which creates the opportunity to  so that it can be updated by the service participants themselves. So we're on the weky and on the mailing list for discussion and the active service members can discuss about a new delegations and can decide if a country, an NREN can delegate to the nren.net tree and the service, the Hungarian NREN and other second carries, the Swiss, this is only for better reliability.

So technically the delegation is done by the route operator, but actually the community is, the service members are the body who can agree on the new delegations. If you check this graph, see the point is that the route is run by the NREN's, and the national registry and even the registrar can be the NREN for that country and the end user can be the NREN's customer, so in this tear, twoteared model, the NRENs played a key role and act as a TIER1 registry for each country domain.

Just to check the basic principles, the operation, the operation of the zones, as I said, it's up to the NRENs, the members, the registries, and if the DNS or any other details in the DNS is not configured correctly, then it's up to the members to discuss the issues and zones that goes any operational problems may be temporarily removed from the tree.

The migration, which is an important thing consider this as a temporary service. So as soon as the conditions that I showed before are not valid anymore and there's a production ENUM service in the country which can be managed by the local national registry, then we will  I mean the service participants will migrate all the zones to the golden tree. But the querying of the tree is possible and that's free, so we recommend all the service participants, even in those countries where the golden ENUM tree is operational to query the enum.net tree as a secondary.

So as I said, this service, we had a recent discussion at the beginning of this year because the mandate of the trial service was ended, so we discussed if still the motivations that I discussed before are still valid and what we could do with this service. And the service participants agreed that still there is a slow up take of the golden ENUM tree in some countries, specially if you check the reserve and education community, that it can be found that it's poorly populated. So even some countries, it's good that Pavel is here from the Czech Republic, where the NREN has some difficulties in putting their zones to the national Czech registry, so some countries there are issues between the NREN and of course it's maintained and the local registry in that case is for the NREN it's much easier for them to populate their zones into the NREN tree rather than the golden tree.

So this is the current situation, it was discussed recently and, in conclusion, we agreed or the service participants agreed that this service is still useful and they anticipate in the future to have multiple trees available and for this community, specially for reserve education community, the nrenum.net can play an important role and they agreed to continue with this service. So that's basically about the principles and motivations and here's the latest status of the service. At the moment we have 12 countries delegated to the nrenum.net tree. April this year and there were two more delegations to the tree. You can check the full list on the website. I put the full list there. There are two members of the service, SURFnet and LITNET where we know it's in production stage and we're discussing with those NRENs and we're considering to migrate all those zones to the golden tree. As far as I know it's happening in the Netherlands, there is a national registry, for the Netherlands and SURFnet has good connections to that and all the zones in the nrenum.net tree will be migrated to the golden tree and it's happening as we speak.

And another thing, we should contact or tried to contact with LITNET, it's the registry for Lithuania community and this was, as far as I know, there is the golden ENUM tree is in production stage. We're trying to negotiate and check the possibilities to migrate all the zones to the golden tree.

There are other NRENs which we know that they query the nrenum.net tree. They do not populate that because there is an operational golden tree in those countries, three that we know of, could be more. But actually, I just mentioned an example, that they signalled to us that they have some difficulties to populate the zones in the golden tree because there are some procedures and universities cannot deal with that and we cannot act on behalf of the universities because legal issues are there. So it would be up on the universities to do those host delegations and the universities simply cannot deal with that. So the situation in practice start NREN and [] /SES /TPHA wants to populate the nrenum.net tree which is more easier for them to do so.

And just a few words about the size, just to show the size of that. We have no specific information about the size of the TIER1 zones, of course. Some number that I know I'd have  in Portugal, we may hear more than that, at the moment there are more than 35,000 numbers in the nrenum.net tree. So I don't know much about the other countries. I sent out a mail to all the service participants that would be good to know more about their  the size of their delegations in their country just to know how important this service is for them.

And of course the future. Future plans in this list, in the first column, I listed the 12 countries that are currently pop lating the tree and also the NRENs that we know they're querying the tree and there are some other plans, invite more countries who are active in VoIP service area to join to this tree.

And the future development plans, of course, can include some additional, you know better than I, the GDS numbers can be advertised by this service. In this reserve and education community there's a user for video conferencing, they mostly use direct IP addresses or GDS numbers to call each other. And if you decide to use the nrenum.net tree to advertise the GDS numbers, it means they can query if there is a call from each end point, then they can check the  maybe first the golden tree then the nrenum.net tree, if there's any information about the numbers in there, then as a final step they could route the call via the GDS architecture you are. And there's an initiative which is called EDUCONF. This could not be a service under NRENs dealing with video conferencing services and one of the options to solve the addressing solution is to use this nrenum.net service and find the GDS numbers as a DNS lookup service and not go through the traditional GDS hierarchy.

More information available on the website. This website is a confluence Wiki page. It's public. All the members can see it, and there's some pages that only the members can take a look at.

If you have any questions about the service, I'm here to answer.



NIALL O'REILLY: I'll start off the questions. You mentioned GDS. That might not be something everybody is familiar with. Perhaps you could say a quick few words about what it is.

SPEAKER: It's the global dialling scheme. That means that if you have H323 protocolbased video conferencing unit and also the multiconference units which makes the calls available among multiple partners, then you can call the GDS number, which is general  it's a phone number like formula number for the end points, and that is routed via a GDS hierarchy, which is based on gate keepers. And the proposal  actually those gate keepers are maintained by in our case, in our community, by the NRENs, but according to the current situation, it's quite difficult to have available  full availability of all these end points via this GDS architecture you are, there's also an issue with gate keepers, reliability, configurations, via this hierarchy. So it was found that it would be more beneficial to have a lookup service, like the nrenum.net service, where there is a  and the party's GDS number can be found via this DNS service. So that was  that is a proposal for this potential activity to take nrenum.net service as an opportunity for the GDS number schemes.

NIALL O'REILLY: Do you see ISP displacing GDS or do they go ahead in parallel?

SPEAKER: I think they will will go in parallel. We don't thing that ISP will  actually, we check both, the ISP and the GDS and we found that GDS is not that, it's still used for those video conferencing and for those video conferencing infrastructure. At the very early stage, it told that ISP will be the final answer for everything and GDS will disappear. At the moment it's not the case and we still consider GDS as an important thing and that could be somehow advertised via this, that's why we thought it would be useful.

AUDIENCE SPEAKER: Just a question: The H323  GDS is just a means of finding the other number, and video conferencing are based on H323 and, nowadays, zone zip, so just to have is 

SPEAKER: GDS is about the addressing, the question was about the addressing not the protocols.

AUDIENCE SPEAKER: GDS is not supposed anymore for five years but it's still there.

SPEAKER: It's still there and still used, that's the point.

AUDIENCE SPEAKER: I have a question: What other condition putting or delegating zones and your nrenum.net? The problem is they don't own the numbers, the numbers of the universities, so we, of course, want to prove that owner agreed those numbers are delegated in golden ENUM trees? What are the conditions of putting numbers into your registry?

SPEAKER: We have no that strict procedures or conditions, if you check the policy document, which is available on line. There are no strict conditions in that, so actually in our case, if the university is served by the NREN, National Reserve Education Service, and the VoIP service is offered by the NREN to their customers, then we allow the NREN to act as a registry, also act as a registrar. So the NREN can do both and in that case it's not  I mean, the university, obviously have contact through the NREN and can delegate their zones directly into the national  under the national scheme.

AUDIENCE SPEAKER: So there is no one more level or other organization or third level organization as it happens with the golden tree.

NIALL O'REILLY: Are there more questions? No? Then, Peter, thank you very much for your presentation. And the next one will be from Bernie, which is a nice overlap since you mentioned him in your talk. He's been the chair of the IETF ENUM Working Group which was wound up because they had finished their work and declared success. He's's going to tell us what their conclusions where and where they stand now.

SPEAKER: I'm no longer working for Switch as it was the case when we started. I'm now working for myself. I have some task in the IETF. So what I'm going to talk about, I'll give a brief status update on the IETF ENUM Working Group, and then I will go to a particular document that changed something recently. It's about the ENUM service registrations with IANA, then I'll have a short summary conclusion and if there's time for question and answer discussion.

So status update is more or less we published three important documents, I call it the ENUM trilogy. These are three documents connected together: RFC 6116, which is the update of the main specification; 6117, which is the document which specifies how ENUM services get into the IANA registry; and 6118 is a transitional document that updates the IANA contents synthetically, it fits the new registry system.

And the IETF ENUM Working Group was concluded during the Prague meeting. We had a nice dinner. Mission was completed and I would say it was about the time after 12 years hanging around, standardizing ENUM, there's not so much left anyways. There are some left overs or documents that are still around, one is dealing with IAX registration. This has been approved last week and will be published as an RFC soon. Then I started the first update of ENUM service, for calendaring that you can find your calendaring addresses from a phone number. That needs to be updated to be in line with RFC 1617 and there has been some extension in the calendaring space that need to be reflected in ENUM. So question between who knows what an ENUM service is? Who knows what the ENUM service is? Okay, I'm happy that I make the next slide. I'm trying to explain this here. All the rest of the presentation is about ENUM services. An ENUM service you need, for each service you put into ENUM a name so sip, sip or sip S, or email: Mailto, or in pictures, you have this Swiss pocket knife, in the middle there's ENUM and all around is the ENUM services, like fax, mail, phone, et cetera. On the wire you see the ENUM services as shown there. And all the ENUM services are registered with IANA.

So there's RFC 1617. In short it provides the guidelines and processes for registering ENUM services with IANA. It describes registration procedures and tells you what all has to be in this document. It obsoletes the old one that was in RFC 3761 and it was published more than a month ago, seven weeks ago, as part of this ENUM trilogy, after five years of hard work.

So the original goals was that there was quite should variation in ENUM services and how the specification looked like. So we were harmonising the concepts of the specifications. We also intended to reflect evolution because in the beginning we didn't know how they would look like and what is important in the specification. After we had this experience gained, we put that to paper. And we kept it best current practices.

For the authors of ENUM services it means the authors now have clear instructions on what is in an ENUM service specification and how he actually can register an ENUM service with IANA.

The changes in the process, this is probably the most important, is that earlier it was necessary to have a standard striker or BCP, now it's information to have it required which doesn't involve anymore fool with all the process involved, and you can do it even outside the IETF standards process, just involve this expert review. And new elements in the template. I have two minutes left. Next slide will be pretty fast.

So what the specification contain is his here. You can read it on your own on the slides. And I'm going to give a short insight into the IANA registration template. It tests these fields. On the wire it looks like this.

How you're doing it. The first step, if you want to design an ENUM service specification is RTFM. Everything is explained in RFC 1617. You write and submit is to the ENUM Working Group list which will be open even if it's closed. Depending on the feedback you're getting to the next step. However, if you believe the specification is mature enough, you can submit it to the IANA. The IANA will then initiate an expert review. Depending on the outcome, you either have bad luck and it's not going to be published or you need to make up dates or if you're lucky the expert approves the specification and you are just about to publish it. Once the specification is published it is added to the IANA registry and you're done.

Up dates and deletions basically follow the same procedure as for initial registrations. ENUM services are never deleted but declared obsolete. I was now pretty fast and to summarize, we closed the ENUM Working Group because mission was completed. The IANA process for ENUM service registrations now has lower barriers, result in speed up. The content. ENUM service specification is more exhaustive, improvement in quality and clear instructions how to write it, the specification no longer needs to be in RFC, it can be in something else which has some requirements from the process like described in the RFC 1617. So now we are at the last slide which means you can ask some questions or if in your discussion about it. I think he's happy if there's no questions. We can proceed with the program.

NIALL O'REILLY: We'll do that, Bernie, thanks very much.

NIALL O'REILLY: Next, we have Wolfgang to give the regular update. I take this opportunity to mention that they've moved things around in the DNS services team in the RIPE NCC and to take  I'd like to take the opportunity of thanking Wolfgang's colleague who used to give this presentation very well to us in the past and to welcome Wolfgang.



WOLFGANG: Good afternoon everybody. So since the introductions have already been done, I'm going to go right into my presentation. I want to apologise right away. There's going to be considerable over lap with the DNS Working Group but that's just the nature of the update. I'll start with a brief overview of what the DNS department is currently carrying out for RIPE NCC and RIPE community. Number one we operate the reverse DNS zones that we allocate space to our members from, and we also do the same thing for other RIRs as a secondary. Also we operate Kroot as one of the 13 DNS root servers. New to our service is his what we call FReverse. There's been an update on this earlier today. I'll give more details on that in just a bit. Then we also offer secondary DNS service to ccTLD to develops countries and here for this Working Group specifically we operate E164 arpa, the tier 0 zone for ENUM and also the AS which we operate at the Internet exchange.

Projects we've been busy with mainly is Anycast project. Eventually, the goal is we move all our DNS services into this Anycast cluster which is being operated from two instances, one in London and one in Amsterdam. We migrated a couple of critical zones in.add.arpa and IP6 arpa as part of this mentioned FReverse system. These are the top level zones for IPv4 IPv6 reverse space. Then we migrated all our RIPE NCC zones on to it. I'll give a brief overview on what is left to do for that.

Relevant to this Working Group here, we had a DNSSEC outage on the 15th of February. What happened during that outage we had a KSK role over and our signer missed a signature in the DNS KEY set in that zone. We did some analysis with our vendor on that problem and, unfortunately, the vendor was not able to reproduce the problem and eventually concluded it was probably caused to a high system load. Moving on to the bad of this situation, we had another one of those outages on the 14th of April, this time it affected ripe.net and one of our reverse zone. We couldn't down load any high system load. So that actually brings us on the good part. We increased the amount of logging that we did on the system and we could reproduce the problem with our vendor and we're going to get a bugfix release soon and are going to put into that production before the next case role over. The first outage already got us thinking that there have been a couple of these outages not just for RIPE NCC but other entities and we get the feeling that until DNSSEC implementation reaches a mature level for the code that is being used, there need to be safeguards in place in order for this engineering staff to feel confident operating those systems. So starting at the meeting earlier this year in San Francisco, we did  started some discussions on what such a safeguard should be and there's been some input on that already, NL NetLabs started that already and they also opened a mailing list which I encourage you to joy if you're interested in the topic to coordinate further how the safeguards are going to be implemented. They're not the only one, also SIDN who did prototyping so there is general consensus these kind of things are going to be necessary for the future.

The better part of DNSSEC is the situation with the signed parent has developed very well since the root zone has been signed about a years ago. The blue part of this pie chart here represents all the parent zones that we have where we are at the moment able to publish our trust anchors into. We published all our IPv4 reverse delegation records. IPv6 we published a little earlier. The arpa part and net and organise have been signed a couple weeks ago. That leaves us with the white part here, those are actually only a couple of zones and the good part here is if we look the prediction for the end of the year is like this, we'll only have three more zones for which we cannot publish our delegation records in the parent zones. We consider that a good development and are hoping also to get those done rather soon.

In terms of ENUM specifics there's only been one delegation change since RIPE 61, and that has been long awaited with Portugal plus 351 which has been put in in April.

That shows us this picture for the DNSSEC enabled zones in the ENUM tree. The changes here are the Netherlands which had been signed for a while, they're fully signed and have a DNS record in ENUM zone. Portugal is actually already signed but does not have a DNS record in the ENUM zone yet. Unfortunately our colleagues from Portugal are not here today to fill us in on their plans but I assume we'll see that resolved rather soon as well.

The lameness picture for ENUM is not going as well as we would probably hope for. We still see a quite high amount of lameness, lameness referring to zones that are either completely lame, not being resolvable or not resolvable, and partially lame so at least some of the systems that are supposed to serve the zone do not serve the zone or are broken in some way. There is almost no change here. It's instead in this kind of bad shape and it begs the question: What kind of service quality we expect and if this is maybe something the ENUM Working Group here would like to tackle in one way or the other?

Looking at undelegated country codes. Those are queries we received that are not in the golden tree at the moment. Normally we used to see a high amount of queries for Portugal here. That changed obviously since Portugal is not undelegated anymore. But I exploded this pie chart, this is the bulk of the queries that we received in a period in the last three days, I believe, or two days, and what happened here, it seems that one provider, cell phone provider in Turkey is querying a large amount of different tame names in the plus 905 region, which is the mobile prefix, so that makes up 90% of our queries that we receive for E16 for Arpa. If we explore the rest that's the rest of the picture. Nothing too surprising here. The US which was closely following Portugal before is now the majority of the queries, Russia and the rest here are the candidates that we normally had in those statistics. So no major change here. This is an operational glitch of some sort.

With that, that brings me to the end of the ENUM update, and I would be happy to answer your questions on it.

NIALL O'REILLY: We're now ahead of schedule actually so there's room for plenty of questions for Wolfgang. Or at least five minutes of.

AUDIENCE SPEAKER: Bernie, you had a slide about this lame delegation zones. I'm a bit surprised there were so many. I thought it was Italy and nobody else. Can you tell me who else it is?

SPEAKER: I actually did not put it out here.

AUDIENCE SPEAKER: In the meantime, I can go to one of your comments that maybe you should discuss about the service, at least I was running still an ENUM zone I faced a problem when you had calls running into time out, it was bad for the quality of service of a VoIP system and I was kind of proposing that those who cannot maintain their line service well should be removed from the zone file. Usually there are those who not run anything.

SPEAKER we basically get into a weird situation here. On one hand, as long as the service is not being widely used, one could argue that the service quality is not so important. On the other hand, if it affects the service quality badly in that the service doesn't work as it could, it might also affect the uptake. My personal opinion is, if you qualify for a delegation in ENUM, at least it should work.

AUDIENCE SPEAKER: The first, I would be interested if those who have lame delegations or those who don't do anything with ENUM anyway.

AUDIENCE SPEAKER: According to our list here, the ones that are completely lame as in don't answer at all, is 65, which I believe is Singapore, 39, which I think is Italy, 84, which is Vietnam, and 62, which 

SPEAKER: I think that's Australia. Maybe New Zealand? Must be down there.

AUDIENCE SPEAKER: 62 is Indonesia.

SPEAKER: I have to say I don't really know how much those zones are used in production, but yeah, partially lame, yes, can happen, but what we also see here, this is not temporary, this is stable at this bad shape. So who  who is supposed to have the mandate on saying something? We can contact the operators, but do we have the mandate too?

AUDIENCE SPEAKER: We have, in the past, sent emails to the operators to alert them to these problems. But we've not received responses and the problem hasn't gone away.

SPEAKER: For Italy, even the contact records that we had were not reachable. So, yeah.

AUDIENCE SPEAKER: Is there a policy document that forbids removing the zone or is there no policy zone that says this is out?

SPEAKER: The way I understand the current set up, and please don't take that as the hundred percent answer here, is that the RIPE NCC does not decide what goes in the zone. We just do as we're told, basically. Maybe Alex can say more to that.

AUDIENCE SPEAKER: Alex Le Heux. You're correct. When we receive a request for an ENUM delegation, we pass it on to the ITU, who approves it or doesn't, and if they approve it, we set up a delegation and that's as far as our involvement goes.


AUDIENCE SPEAKER: Brett Carr. I wanted to mention, I think Italy's been that way for quite sometime. I've tried to get them and couldn't get any response from them.

SPEAKER: We were able to finally contact them, but that was going over three different corners.

NIALL O'REILLY: If I've understood correctly, it's not just the shape of the pie chart but the actual members that represent is static, there's no churn?

AUDIENCE SPEAKER: From an operational point of view, once delegation is received, and this is my previous ENUM hat, it does take some time for things to be set up operationally, I don't know if Brett wants to mention with respect to how long it took the UK to do things. Just as an example. I'm not saying

SPEAKER: Is that in relation to the lameness? Because without picking one out of them, it has been considerable time. We're talking years.

AUDIENCE SPEAKER: It took the UK quite a while as well.

AUDIENCE SPEAKER: Perhaps I should add that when we do the delegation, we always check the name servers. So at some point all these name servers were responding. And they've gone silent after that. So we do not do delegations if the name servers don't respond. Because we only do this check initially, and then the servers go lame after that, that's always possible.

AUDIENCE SPEAKER: That was certainly true with the UK as well because during  the UK was first delegation during test phase and from the test phase to actually setting up ENUM in the UK there was a time when the name servers were not responding. I don't think it's not normal for that thing to happen. You can certainly check for delegation at the beginning but there could be operational reasons in between.

SPEAKER: I agree.

NIALL O'REILLY: We might follow that up on the mailing list and see if we need to take action. I don't think we want to make a kneejerk decision just now.

AUDIENCE SPEAKER: I was just about to propose something like that, that we look at this and see what kind of action or solution space there is to tackle this problem, as a proposal.

SPEAKER: And that's how quickly five minutes are gone.

NIALL O'REILLY: Indeed. Thank you.

(Applause)

NIALL O'REILLY: As I mentioned, Lino Santos from the Portuguese National Reserve Network, couldn't be here today and I have quick slides to show to talk about the situation of ENUM in Portugal, which, as was already mentioned, has just been delegated and moved  in fact, Wolfgang said it as well, has been delegated and is moving out of NRENum into the golden tree.

And a clicker.

So the TIER1 manager in Portugal is the national regulator, ICPANACOM and they've signed a registry. And the interesting thing in Portugal, they have already 35,000 numbers in the NRENum ENUM system, and it will be interesting to see how those migrate into the golden tree and whether the kind of obstacles that were mentioned earlier prove to be a disincentive. I think it's a question of watch this space.

The MOU was signed in January of this year, it's just a few months old. They've invited the Telecom operators and existing registrars to become involved in the project. They're having meetings in the next couple of weeks with the interested parties. They haven't got all their rules and principles and things together yet. The rules are being designed. They have plenty of open questions. I'm not going to offer it to the meeting to ask questions because I can't answer them but this is an interesting point of information.

So we skip over that slide and we go to the other one.

At each of the Working Group sessions I give this ENUM status update and this is simply a reflection of the information that has been provided to me by the people who are responsible in the different countries that have already set up ENUM delegations. And it's the data  this data is reflected on the website enumdata.org, which was set up by Kim Davies. It depends on data from the responsible agencies. Sometimes there's a time lag. Kim has been hosting this privately for a number of years and we're looking for a new home for that website. I give this summary report at each meeting. We look at the request archives which show the paper trail going between the people who are requesting to be ENUM TIER1 registries, the relaying of those requests to the ITU and the responses from the ITU after consultation with the relevant authority in the country involved. Sometimes those are objected to. Sometimes they go ahead. Sometimes there have to be changes. Here are the statistics. There are, at the moment, 11 production ENUM domains. Eight of them are in a strange intermediate stage. This is probably a prudent step for ENUM TIER1 registries to take when the market doesn't seem to be ready yet but they don't want to drop out and go through the whole procedure of requesting redelegation again. Some of those are Australia and also the six French countries, some of which are small islands in the middle of oceans. The number of active trials has increased from four to five and the change there is the Portugal. The number of ENUM zones which are merely delegated  delegated is the catchall categories for ones we don't know any better about. It doesn't mean they've disappeared, but moved into production and I'll have more details about that in a minute. There are 49 delegations in the zone. Five of those are covered with DS and as Wolfgang said there's a sixth one that hasn't been signed and there's no changes in the not delegated or objected. That refers to ENUM zones who have had a trial and decided to stop, such as plus 1 for this north America plan. And Switzerland.

Portugal trial, we mentioned. The one from Brussels they've moved from delegated to production and I'm showing the new statistic. And some please and some thanks. Please, if you're involved in ENUM in your country, get in touch with me at enumwgchairs [at] ripe [dot] net. That will reach Carsten and me and we'll tell you what information we have to get from you or process the information you give. And thank to Kim who's been hosting this privately for a number of years. If there are questions this time around you can ask me because I can answer those ones.

Right, then you must excuse me for a minute so I can get my cheat sheet to see what we need to do to wrap up the meeting.

I see there's one other piece of short news that I noticed today or in the last couple of days on the request archive, plus 86 has extended their delegation until middle of 2012 and that's China. I don't have any other detail but they had the correspondence, the paper trail through the ITU recently. And Pavel mentioned the iPhone app, I was going to mention that too. We seem to have reached the stage of the meeting of any other business? And here 

AUDIENCE SPEAKER: Apologies for not being here at the beginning. But I wondered about what happened with ENUM 61.3?

NIALL O'REILLY: That's the next item on the agenda where I review the surviving action points. 62.1 which is last call, the outstanding minutes. And have opened 61.3 and we expect Carsten and I have to work to make that happen. I spoke to some people earlier who I expect will be in Vienna and we aim to have that panel discussion as the main agenda discussion at the next meeting.

AUDIENCE SPEAKER: Any idea who  would you be able to comment on who those are?

NIALL O'REILLY: Well, the first head's highest is Robert [Shiska], who everybody will recognise as being one of the people who have been around the ENUM scene for a long time. Ever that I think you and I and Carsten have to chase some of the other obvious suspects. So we revowed the action points and it falls to me to thank the scribe, Alex; the stenographer, Anna; Chris, Sander's colleague and all of you for being here and our speakers who put in a lot of time and effort to prepare the material. We're ten minutes early for the coffee. I hope it's ready for us.

(Applause)






42