enum-wg

Note: Please be advised that this an edited version of the real-time captioning that was used during the RIPE 56 Meeting. In some cases it may be incomplete or inaccurate due to inaudible passages or transcription errors. It is posted as an aid to understanding the proceedings at the session, but it should not be treated as an authoritative record.

RIPE 56 ENUM Working Group 9:00am, Thursday, 8 May 2008

CHAIR: Okay. I think we can start with the administrative part of the meeting. You're welcome to the ENUM working group session of RIPE 56. If you thought you were in a different working group you need to be in a different room. My name is Niall O'Reilly. I'm one of Co-chairs of the group. You've gotten in your registration pack green sheets with the then version of the draft agenda and that's been updated a little bit since and on the mailing list and on ROSIE you'll find the one that's here now on the display screen. I've already welcomed you but for the ones who missed that bit, you're very welcome. We have a scribe and jabber monitor on their way. We have microphones for people we have a jabber monitor hiding in the back, much better place for a jabber monitor. We don't have stand mikes, we have hand mikes if people want to ask questions. Please identify yourself. If your affiliation is relevant to your question, please disclose it but you don't have to. Someone is reminding me you should turn your phones off, or at least to silent, just as I'm doing now. And that's all the sort of minor practical arrangements. The next thing we have to do is confirm that the agenda that you see on the screen is the agenda we're going to use for the meeting. So if there are things that need to be there that haven't been included, now is a good time to say so. We'll be skating very quickly through the minutes of the last meeting. Then we have three main presentations. On a crawler tool, we'll have a presentation on the now in production Dutch country called plus 31 and also the UK country code in a short number of months. After that we'll have two items on ENUM operations, a report from the RIPE NCC, and some stimulating suggestions from Carsten on performance and availability of Tier1 name servers. If time, short news and interaction with other working groups and any other business. Anything that you note that needs also to be discussed? No hands. Good.

You also notice that item G doesn't arise because we didn't have any ENUM related plenary sessions this time around. So moving quickly on, the next thing is the action list. All of the actions have been closed since the previous meeting. They were mainly by very bad planning things for Carsten and me to do. We try to share out the action list a little more what am I missing? Never mind you can see it well enough even if I don't go full screen. We're sharing the time slot with the address policy working group and this was something that we were asked if we were happy with a couple of meetings back and I was to get back to the other working group chairs and I did. Carsten and I corrected some typos in the minutes of 55. And sorry in the minutes of 54. And Alexoffered at coming up to 55 to give the presentation that I'm about to ask him to give but we didn't have time at 56 so he's kindly come to 56 instead. The minutes of the last ENUM working group have already been blessed on the mailing list, so no need to discuss them further now. That done, I'll move back to the agenda and we'll start with the main presentations and the first of these, Alex.

ALEXANDER MAYRHOFER: Thank you. Good morning, everybody. I have worked for ENUM.IT. What I'm going to talk about today is actually a website and the service behind it, which is whose name is crawler.ENUM.AT you can take a look at it now but please don't overload it. What is the ENUM crawler thing about? If you have seen it already you might know what it's about. The idea behind it is to explore the E 164.ARPA name space and find all the numbers with NAPTR Cisco out there. The reason I started this is one of the most frequently asked questions that we encountered was, how many people can I actually reach using that ENUM thing right now? And I thought that was a good question and let's find out. And also it's always fun to play around with large databases so that gave me an opportunity as well.

So how does it look like? This is a screen shot from, I think, three days ago, something like this. So it's a very simple website where you can see the number of countries in where the number space contains ENUM domain names and some statistics about those countries, recently discovered numbers and stuff like that. So as you can see from that, my crawler has found 22 countries right now with ENUM delegations where there are actually numbers in [unclear]. If you see yourself on the list, very good. If you don't, add a couple of ENUM domains to your delegation.

So how does it work? I mean, if you look at the E 164.ARPA space, it should be reasonable easy to crawl because the labels are predictable. It's simply all number from his zero to nine. You have a certain number length, up to 15 digits. Still it's rather large name space, it's ten to the power of 15, so it's about 200,000 times larger than the IPv4 space. It's quite a bit smaller than IPv6 space.

So there's one property of DNS which comes to the rescue of nailing down the name space to the name space that is actually filled with numbers, which is the nonempty terminals. The original idea was stolen from Peter Koch who told me that idea once. There's actually an RFC about this, 4592, which mandates a server to return no error if there's something below an empty label. The old behavior was to return an exdomain, the new behavior is to return no error, which means you can distinguish a domain name where there's labels below from a domain name which is empty.

I have an example here, so if you look at the zone or the snippet of the zone on top and the queries below, if you query 1.3.4 you get no error. If you query for 2.3.4 where there is a label below, you get back from the name server no error and empty. So the answer section doesn't contain any answers, but the response code is no error. So that's an indication that there's something below. Same, for example, for 5.2.5 because there is still in the first record a label below so you get no error and there's an indication that there's something below. And on the other hand if you then query for 7.5.2.5 you get an X domain which means you've reached the end. That's the only slide using animations.

For example, we start at 4.E 164.ARPA. I get back no error. I queue the ten numbers below it for crawling then I go through those numbers from 0 to 9, and for nine of those numbers in that example, I get back no error. There's something below. And for one of the numbers, namely the ENUM domain corresponding to the country code 45, I get back an X domain which means to me the tree under that number is empty, nothing there anymore. The crawler continues then, for example, on the second level I get 90 numbers in that case, so on and so forth until it actually gets back no error and records. In that case I store the records in the database and still I need to look whether there's something below because there could still be more numbers below. So that's actually the idea behind it.

Some name servers still return an X domain for empty non-terminals. That was clarified in the RFC I mentioned before. That means the ENUM space below such a domain name is not being discovered because an X domain means stop here. And also the crawler deletes existing information below that. If you remove ENUM delegation it returns an X domain which means everything below must be deleted in the database. Some other bind versions, Some power DNS versions, specially you have that behavior.

The bad thing about this is that when I ran the crawler for the first time one of the name servers for E164.ARPA was a name server with some behavior, which led to a temporary loss to the domain name in the crawler of course not in the DNS. So there's a safeguard now in the program, never delete anything would delete more than one thousand nodes. That's fixed for 4.E164.ARPA.

So what does the crawler actually store for a number? I have number status. You can see from the list. The most interesting thing is that N and W there is a wild card in it. I tried to discover wild card by issuing a second query with underscore label in front of the number. So if I get back something for that and it's the same as for the number itself, I assume it's a wild card.

Of course I save in the database when there's a problem with the number and something that I called creative number spaces. There are some number spaces in ENUM, actually in our country code, where there are dynamically generated Joan zones. They return the same set of numbers. I do store in the database the full NAPTR records, the query time and last time the number was queried, plus the time when the number was discovered.

Some fun results, you can go to the website and browse through it for yourself. We have about 600,000 numbers with 700,000 NAPTR records. Out of those there are about 20,000 wild cards number. 22 countries as I said before. The top most country Romania, mainly because there's a service provider who entered ENUM records for 400,000 numbers, that's his own number block. On the second place is UK with 50,000 [unclear] and reasonable behind is Austria with 32,000 numbers. The shortest number is a number in Romania, with 778. There's lots of number with his 15 digit where the crawler stops because it says numbers should be at maximum 15 digits. And the average number for normal length is little bit above 11 digits and the average number for wild card is even higher which is interesting because I thought that wild carded numbers would probably be shorter because they cover a larger number space.

Popular ENUM services, interesting enough. The old RSC29 service number notation is still very popular. That's actually mainly because there's one service provider out there in Romania who uses that. Of course the most popular is SIP, then TEL. And then there's E 2 U. I don't know it looks like some kind of encrypted information. So that's pretty interesting. Rare ENUM services, there are a lot of ENUM services which appear once and a couple of them appear sometimes but don't really have wide spread use.

The average query time is 86 milliseconds overall for empty name delegations and about 65 milliseconds for numbers with NAPTR records which is measured from a server in Austria. China is a lot slower than Germany for example. There is one NAPTR record with a SIP, and my colleague is to blame for that. It was a test record. Nearly all NAPTR records use the sorry, delimiter. There are some creative ones out there. There's some using spacers and there's a couple of them using plus and whatever.

16 of the top 20 have the color red in their flag.

So software and hardware behind this, short overview, it's a stoneage CPU server, the database post GRE Cisco QL, there are eight million rows and some queries on those rows are challenging and very interesting sometimes. That's the reason some of the numbers I explained before are not displayed because the query takes ten minutes. The crawler and the webfront is written in PHP. I'm using the net witness module. A CSS frame work for the fancy we be design and cute icons just to create the web page.

It took me about two weeks for the initial version to come up with that and then four or five days to create the second better version of that. So that's about the time span that it took me. And probably interesting it takes about three weeks currently to do a full run through the whole number space. If you put some numbers in there, then you have to wait about three weeks until the numbers show up in the crawler.

Well, that's it. Thank you very much. I hope I'm in time. I think so. Any questions?

AUDIENCE: About the wild card numbers being longer. About your comment about wild cards being longer, one thing you might be running into is people putting wild cards in front of a fully qualified number for over dialing.

ALEXANDER MAYRHOFER: I have investigated that a little bit and one of the reasons is one of the service providers in Austria is using, simply wild cards for normal numbers, even he has not any extensions behind that number. It's very easy for a single provider to have changed the statistics significantly.

AUDIENCE: I have a question too. One thing about the UK figures, maybe you can explain a little bit about that, is that because of the carrier registration in ENUM, the 55,000, is that the reason for the figure?

ALEXANDER MAYRHOFER: I think the number is 51,001 and the other one is Jim's number. Yes. I think it's because of crew [unclear] there are number ranges where all 10,000 numbers within the number block have the number.

Anymore questions? If you have any ideas about what you would like to have what you would like to see on the web page being displayed for a number, let me know. I'm hope for suggestions. It's intended as some kind of monitoring service for the ENUM community.

CHAIR: Thank you very much. That's very impressive and I'm sure everyone was fascinated by it.

(Applause)

If I can ask the next presenter to tell us how things are going in the Netherlands.

ANTOIN VERSCHUREN: Good morning everybody. An update on what happened to ENUM in the Netherlands. Last time I gave an update on this was three R.I.P.E.s ago. Let's start where we left off there. We in the Netherlands we had this is a short history of what happened before. We had a report back in 2001 about if you were going to deploy ENUM in the Netherlands, what were the conditions that it should follow. Shortly after that, we had a protract I have delegation of the Dutch ENUM zone to our ministry and then came a period where there was hardly any interest from the market to start a trial which was something that was suggested in the report. Then in 2005 we got a VOIP boom, a lot of operators started to offer VOIP services and there was a sudden interest and they said the first thing we need is a registry, we as IDN which is the registry started the ENUM initiative, and this is basically where I left you all a [unclear] RIPE meetings ago.

Some special observations, quite an innovative market, high broadband penetration, one of the highest in the world I guess. There's a lot of VOIP, I know the number from last year was 28% of all voice is VOIP. I think it's a lot higher already. We have a government that promotes competition, so they also have a policy doing that. Our regulator and that is something that is a bit different from other country they supply number blocks directly to end users, not only to operators F I'm a large company and I want to have a number block I can go directly to the regulator and say give me a number block and I can go to Telcoto be able to deliver that also operators in Netherlands already have a central number portability database and that's for all the numbers, not only for the mobile or land line. Every operator in the Netherlands is using that.

So where we left off, we started an initiative and we needed to get support for that. We got some support from BTG which is an interest group for large Telco users, most of them with their own numbers, companies like Philips, Shell, those are the countries in the interest group, we had some support from Cisco OC and RIPE NCC and no constructive objections from cable operators because they already started their own VOIP peering and we had to find a way for Telco to give input but they were not in a position to get a joint position to say, okay, this is what you should do or shouldn't do.

So what we did then was we had to get a sort of like a stick to get this moving. So where he requested redelegation of the Dutch ENUM zone which was the first delegation done by RIPE and there was no process by the between the ITU and RIPE so we had to invent that ourselves. And the ministry had six weeks to consult the market for objections from the redelegation which was the stick to get things moving. There were some consultation results, it needed to be an open and transparent policy. That was one of the results we had to follow.

That's basically it. There should be a compulsory market consultation about policy and technical requirements. That was something that we agreed to. Because it should only be about public user ENUM and no infrastructure ENUM was involved. There was also some request that our government said okay we don't follow this because it conflicts with our own policy, one of the things, for example, that operators wanted to the fact that only operators could do registrations, so that was sort of like a closed market and our government didn't agree with that.

So those were sort of like the things we needed to do. We have a between the ministry and the [unclear] we had to do in June we consulted the market and we got that report back on the 26th of March this year. And that was also the date that we did our first ENUM registration, which was more like a ceremony where we gave our director general of the regulator the first ENUM registration.

So what were the results of this invasion platform? There should be strong validation agent requirements. That was clear. They wanted this to be very tightly regulated in terms of who owns a number and who can register it. That gave us the chance to have an open registrar market. There should be a low threshold to become a registrar so you have a lot of competition in that market to start offering or invent services. There should be a clear complaint procedure. That was a requirement from mostly the operators which if a number got registered wrong, it should be an easy complaint procedure to get the number out of the ENUM zone. You can only register numbers through a registrar, so it's a registry, registrar, registrant set up. Almost all numbers can be registered. There were cases for premium numbers, examples were given that when you look at the TV during the night, I don't know what they show in your country but we usually have these erotic advertisements with numbers to dial where you have to pay a high fee. And the thing that strikes me always is next to the number they also have a website. So ENUM could possibly have something there for premium numbers.

We do predelegation DNS checks. We use a validation token between a validation registry. Validation methods will be invented by the market but approved by the registry. We allow number block registrations and in the beginning no regular who is service. It's not the registration who determines who owns a number. And we will do DNSSEC and IPv6 within one year and we already have IPv6 six and DNSSEC will probably be there at the beginning of two thousand nine. Some market observations after that. We already expected interest from these large Telco users or organisations with their own number blocks. But the signals we're getting now is they're really interested and ready to register large blocks, so a lot of numbers, more than we anticipated for in the beginning. To give an estimate, we expected maybe 5,000 registrations but they already ask us things like can you do 100,000 registrations in a month, which is actually quite high. Regular ISPs are hesitating. They sort of like are waiting for that to happen. Telco operators are interested, but it takes them because they're a massive organisation it takes them a long time to get this innovative idea running so they will outsource validation to trusted third parties. And this is one of the most important observations, there is surprisingly much interest from banks and on line traders and those sort of [unclear] organisations to use ENUM as a distribution channel for public keys for identity management. What they want to do is you public a public key somewhere and you need a signal identifier to get to that key of a person, well ENUM is a way that everything user most of the users above a certain age all have a mobile number, why not use that as an identifier, it's globally unique distribution channel. And we're working with them to sort of like see where this is going to.

Registry, separate foundation. Procedures and documentation, stuff like that, takes more time than we anticipated. We start with a limited number of known registrars because we have a temporary registry system to get things going. We will use the same registry software as ENUM.AT and IENUM in a few months. The next step is just go for any registrar can enter. We will have DNSSEC and IPv6 in two thousand nine and DNSSEC specially a requirement for those banks and on line traders who want to have the secure delegations.

Something about pricing. This is more marketing but it gives you an impression of what we're about to do. So where are we now? Ten registrars have started. That means that we have ten registrars. Basic interface online. We started implementation of the real registry system. First validation agents have started. We have the first validation method approved. And we have two nurturing projects. One of them is with these banks and online traders and another one is well, basically some security in general. And the result will be evaluated by the end of two thousand nine which is specific something that we're obligated to do according to our covenant with the ministry. If you have any questions?

CHAIR: Carsten is minding the clock. Any questions?

No. Thank you very much.

(Applause)

CHAIR: We move to the next presentation.

DENESH BHABUTA: Just a very very quick update on what's happening in the UK. There's been some changes recently which I'll go through. And we're hoping to� Just a quick recap, UK ENUM was set up in 2006. There were four interim directors, our own Jim Reid sitting over there and three others and they took the company to where it was until the AGM that was held last month. UKEC is recognised as the government body within the UK. We are the people who talk about ENUM, we know about ENUM. So in a sense we're like a regulator although we're not statutory, because we're recognised by the department of business enterprise and regulatory reform, that's why I use a small R there to show how important UKEC is within the government structure. And late last year the Tier1 registry was appoint and had that's Nominet.

What's happened is we've decided on a member based model, one member one vote, plain and simple. However, the membership fees, we're like a trade organisation, your membership fees depends on your turnover so a 1000 pounds a year, �5,000 a year, it doesn't matter how much you pay you get one vote. To entice people to become members is what we've said is within the first year you get a discount, up to 50%. If anyone wants to join us, please do so. We had the AGM, the 25th of March was important for us also, we had our AGM and none of the interim directors get reelected but we have four initial directors. And we had 12 members who signed up for membership and were able to vote us in. So thank you very much for that.

What's happening now, we're fitting in, let's put it this way, things are taking time. There's a lot of work that was done by the interim directors and we're having a knowledge dump by that, lots of transfer by them, all the documentation, legal stuff. As well as the four directors on the board, we have to we just appointed a representative from Nominet, [unclear] Daley to be on the board and also looking for an independent chairman. An interim secretary was appointed to get things up and running and a tender process will be going out and started the outreach with this meeting basically.

The governance frame work needs to be completed the policy advisory committee needs to be formed. All that they do is have an advisory role. Whether we listen to them or not is a different matter. We need to create the dispute resolution process, basically if there are any disputes with numbers like a number that's been registered incorrectly, then we have to come up with a dispute resolution process and go through that. The other thing we need to do is come up with a code of conduct for registrars.

Also what's happening is we're forming a joint review committee, two of the directors from UKEC and two directors from Nominet are going to sit on this and go through the consultation, the registrar contract needs to be ratified and the RPP, what still remains to be done is the 4.4 delegation, that needs to move from Jim over to us. And one of the issues is enticing the VOIP providers to bring their existing numbers into the ENUM tree. That seems to be a bit hard at the moment but we're working on that.

The next stage is Nominet is going to launch registration in the summer of this year. From what I gather the registration prices are going to be around five pounds for the first one and then ten pence for each and everyone in a contiguous block.

Any questions?

CHAIR: I guess the lack of questions indicates how clear the presentation was. I'd like to make one little comment. I love the logo, reminiscent of the steam phone.

DENESH BHABUTA: More information in Dubai.

(Applause)

CHAIR: Plug for the next meeting. We have the update from the Tier registry which is run by the RIPE NCC.

ANAND BUDDHDEV: Good morning everyone. I'm the DNS services manager at the RIPE NCC and I'm here to do a little presentation telling you what's been happening in the ENUM operations since RIPE 55.

A little bit of history for people who might be new to this working group. The RIPE NCC has been operating the ENUM zone since 2002. We have the master server in Amsterdam and we have five secondaries elsewhere in the world. Provisioning for this zone is done in the same way as the rest of our provisions for reverse DNS and that's through the RIPE Database.

A list of changes since RIPE 55. In January 2008 Tanzania was sad added. In February we added Slovenia and in February 2008 plus 1 in the USA was removed.

One of the significant changes since RIPE 55 was the introduction of DNSSEC into this zone. In July last year the NCC made a proposal to the IAB about its intention to sign the zone and the IAB accepted this and informed the ITU. In 2007 August they approved this proposal. And in accept, the NCC made up a plan and announced this to the DNS working groups. On the 26th of November this zone was actually signed and finally on the 25th of March, very important date it seems, the NCC actually began accepting secure delegations in this zone.

So a time line there.

Some information about actually getting secure delegations. We have a key signing key published. If you want to request a secure delegation you have to do that by updating the ENUM object in RIPE database and introduce the DSR data and some details about this are available on the RIPE NCC website.

The current status, we have two signed zones, plus 48 for Poland and plus 420 for the Czech Republic.

The other significant development since RIPE 55 has been the introduction of DNS [unclear] monitoring for Tier 1 ENUM zone. There was a proposal to allow for DNS to monitor the Tier1 ENUM zones. And there was a lot of discussion on the mailing list, on the ENUM mailing list and the NCC working group mailing list and eventually that led to the publication of RIPE 429 on the 17th of April and Tier1 ENUM operators may request for their zones. This is a paid service so there's a charge for it. Please talk to our people if you have any questions about this.

That's it. Any questions from anybody?

CHAIR: Maybe the after breakfast slot inhibits people from asking questions.

AUDIENCE: Thank you. Thanks for this interesting update. I'm going to ask you some questions about the DNSSEC stuff. Have you been able to actually monitor the amount of DNS queries that are actually soliciting DNSSEC responses? Has there been any change to that? I mean, you gave a presentation or a presentation was given at the previous RIPE meetings about that. Have there been changes?

ANAND BUDDHDEV: We haven't actually looked to see if there's been any significant changes. We've only got the one secure delegation since last week. It's all very fresh at the moment. I can certainly provide more statistics at the next RIPE meeting. I think we'll have something to show at that time. At the moment, no.

AUDIENCE: And Peter Koch, sorry.

AUDIENCE: Hello. A quick update we did separate delegation of checking of zone and we did day before Polish, we were first.

ANAND BUDDHDEV: Thank you for that. I wasn't aware. I only heard from the Polish people. We now have two secure delegations. Thanks.

CHAIR: And a side effect is that we've also covered item X so we won't need to visit that afterwards. That's the moving through of the DNSMON, broadening of the DNSMON criteria through the NCC services working group.

No more questions? I'll ask the next speaker to step forward. It's Carsten Schiefner, the Co-chair.

CARSTEN SCHIEFNER: Good morning everybody. My name is Carsten Schiefner. This is a very short presentation about the Tier1 performance and availability. Most of the time, I hope so, will be consumed by a lively discussion about it. The status quo is as we heard it from the previous presentation is the RIPE NCC DNSMON service is also now available to Tier1 ENUM registries. Tier1 registries could and should come to the web NCC to get their DNS service for their respective ENUM delegation country, to get that monitored.

The question is shall we as the ENUM working group shall we leave it at this stage or try to take it further? If the latter, what is further and how? Any potential measures in this regard always had and still have political implications, possibly unwanted side effects. On the other hand, there also is an operational issue with technical implications as well and definitely unwanted side effects.

To spark off a discussion, I digged out an email from John about a discussion we had or a discussion on email, ENUM working group mailing list actually, about how to deal with lame or nonperforming delegations whatsoever. I've put it up here. I can also read it out. And this email is just meant to spark off the discussion.

What to do here, if anything is entirely up to this group, RIPE NCC and the IAB, although if it involves asking ITUT to adopt any procedures that are not now in place, I wouldn't hold my breath waiting for them to agree, nor would I predict that they would agree to whatever was asked of them without putting their... it is fine to encourage RIPE NCC to make periodic checks of server configuration and accessibility.

So this is not what I have in mind as a way forward, this is as I said and as the title of the slide tells you, this is just meant to spark off a discussion. And the very last sentence on it which was by or which came from Curtis yesterday on v6, but entitle and I both felt it's very much applicable to ENUM in that situation as well: The responsible team may think they're working in a [unclear] environment but other people are actually trying to run a service on top of it. This is actually the problem space and we should be discussing here in the working group. And having said so, the floor is yours.

Just to come up the basic question is, from my point of view: Shall we leave it at this stage or shall we try to take it further?

AUDIENCE: First question is you were introduced as working group Co-chair. Is this action on you as a person or is this action on you as a working group Co-chair? Just for clarity.

CARSTEN SCHIEFNER: That's a good one actually. I would like to take it as an action on me as a person, first of all, as an interested member of the ENUM community.

AUDIENCE: Thank you. That makes think things clear. Now I forget what I wanted to say for the second one.

AUDIENCE: Jim Reid. I was raising this concern about the potential political implications of monitoring things with the consent of the delegation holder. I think the way we may be able to finesse this is talk about it or communicate it but purely present it as an operational matter. And say, for example, operational reasons, security and stability of the Tier 1 delegation, RIPE NCC chooses to monitor this delegation to check things. That's what you have to do is a professional organisation would want to do that. As a side effect of that, we would be in a position to form the delegation holder if there was a failure in the delegation would you like us to do that? I think that might be some way to get around this. Doing anything more than monitoring and having some kind of formal acknowledgment or understood could be destabilizing in a political effect. It would be most inappropriate for RIPE NCC to say you have a lame name server, please fix it or I pulled your delegation because you have a lame delegation and it's created far too much traffic on the Tier 1 infrastructure. I think you should do either of those two things, something a little bit more couched in purely operational factors, nothing to do with anything that may touch on national sovereignty. And maybe just present it as a statement of fact to the ITU just as when they signed the zone, this is a purely operational thing. Just do it.

CARSTEN SCHIEFNER: Would you suggest something like a best practice document or informal recommendation or something?

AUDIENCE: No. I don't think it needs to go anywhere near as elaborate of that. Just send a letter, get this working group to send a letter, say here's what we're doing, giving this information purely to inform your delegates and other members what's going on, and make sure it's put in a way which is not going to start sending off alarm bells.

CARSTEN SCHIEFNER: Okay.

CHAIR: Niall O'Reilly wearing my Co-chair hat. I think that's a helpful suggestion and I think you walked yourself into an action item to work with Carsten and myself.

AUDIENCE: I might have some time to spare.

AUDIENCE: This time speaking as remember of the IAB. RIPE NCC is not in the business of sending liaisons to the ITUT. The way I see and now I'm speaking personally more than IAB member but the way I see the role is to provide RIPE NCC advisor operations but that I don't think it is leading. The ENUM service is a triangular so to speak. IAB and RIPE NCC are working tightly together and will take advice, but will base decisions on to that. So if this working group comes up with a text, please make sure it passes the RIPE NCC and RIPE IAB before it passes on.

CHAIR: Would you I think it would probably be helpful if you had sight of that document before it moves out of this working group.

AUDIENCE: That would be helpful.

AUDIENCE: This sounds very well. I mean, I really that this has political implications but it probably doesn't solve the whole problem. So I wonder which path we should follow to really solve the technical problem? I sort of like to compare it to the YouTube hijacking problem where there is one organisation or one country that basically to put it in harsher, screws the rest of the world and what can we do about this? There are a lot of countries which have their zones in operation and are still in trial and those in trial don't care about the ones in operations, that's sort of like how it feels to me. Now, what we probably see happen is that people are going to hard code in their software that these countries are not to be queried because it breaks things and it will be a very bad thing or a very bad thing and it will be very difficult to get it out of this software. Is there, perhaps another way? I don't know the solution here. I don't have a very strong opinion about it. Should we sort of like only do the administrative registration at RIPE for these countries and do something like a non-delegated administrative registration and only do the delegation when it works? I don't have the answer to that. But I do think that it's probably a very bad idea if people start programming in software to not query certain delegations.

AUDIENCE: I'd like to pick up on one of the things said. The nonworking delegations are really bad for this very fragile ENUM ecosystems. I'm happy to hear the market may be taking up in the Netherlands but in other countries it's hard work to get registrars into the system and to try to build up some confidence on this system. Lame delegation and every failure, will it disturb the kind of trust in the whole stability of the system? It's not a political issue, operational issue, how to deal with it. And the danger of having certain countries put on a kind of distributed blocking list, which is really a bad thing, is very real. We have this problem with Italy three or four times and certain Austrian service providers just put it on the block list and will never ask it again. That is a situation we should avoid. Another thing, I don't think that anybody is really trying to intentionally hurt the system. So it's not those kind of hijacking situation. It's more or less that there is no distinct separation between a delegation to a server which is operated under, let's say, industry production environment conditions and those who consider themselves still in a kind of phase of trial. And maybe it might be a good idea that every holder of a delegation might declare itself whether he considers his self service, production or something that is still just run on the best effort and don't rely on it. May not solve the problem but given that nobody intentionally wants to hurt others, might be a way to help a little bit.

CARSTEN SCHIEFNER: What you just said might even be part of the next presentation in that the registry operator might declare whether its in production already or should declare whether in production or trial mode or whatever else. That's going to come up during the next presentation.

AUDIENCE: I think we have to be very very very careful with the words here and I would like to have a clarification from when people talk about someone not managing the delegation, for example, for Italy and that destroys for all of us. That destroys the ability to Italy. If I make a phone call in Sweden, look up numbers in Sweden, that works. So this problem is screwing your own name space or delegation is something that is also happening all the time. It happens all the time on the internet as well both for routing and DNS. So I would urge people in this room to be a little more careful when they are saying that someone else by screwing up their delegation destroys their ability from a technical point of view, the ability to route phone calls to other domain names or other phone numbers. So I think you may be the last speaker made a more correct statement, what we really talk about here is the higher number of lame delegations we have, the harder it will be to convince people too get trust in the ENUM system, which is something completely different from potential implications regarding operations.

AUDIENCE: I want to just go back to something that Robert mentioned a few minutes ago, about the perception that certain ENUM delegations are for trials or test purposes whereas others are in some kind of production use. Again, we have to be very careful about the language here. I have the misfortune to go to Study Group 2 and be there when the interim procedures were there. They were set up for trials and only trials and explicitly says not for instruction use. Now, if you turn around and say some of you guys are only doing this for trial [unclear] and you're not doing a good enough job of keeping your name service structure right, that's going to create a fire stone, people will say we were only doing it for trials all along, how come you're doing it for something else now? Let's be careful if something is going to be said that you don't enflame that situation.

AUDIENCE: Peter Koch. Couple of things, first of all to Patrick, I tend to agree with you on the point that someone screwing up country who does not necessarily screw up ENUM operations in country bar accept in those cases where someone in country bar is calling country 2 and saying oh, this ENUM thing doesn't work. That's the point. Well, quite frankly, given the state of deployment of ENUM currently I'm not sure that the screwed up countries are actually the problem we have. They are a problem but probably not the biggest roadblock in here. I also don't think this is about the trial versus production thing, because even if you are in trial mode and gym Jim's remarks set aside for a minute, running a name server that somehow responds authoritatively isn't a big issue. If you run the trial mode and the data quality is bad, that's different. The issues at hand here are not the gap between the 95 and 100% reliability. It's explicitly not about chasing down every lame delegation, so any best practices and so on and so forth, that's too far a target and we shouldn't bother with that. It's the particular cases where one manages to have a perfectly lame delegation in one way or another. This is completely unresponsive. The way the DNS work it goes over timeouts and so on and so forth. I wonder whether these cases happen often enough to actually come up with a policy document, heavyweight proposal sending letters and troops to the ITU and so on and so forth, but instead have a very close look at these and it might be recurring at particular prefixes, might be a widespread disease but can be dealt with on a case by case very quickly.

CARSTEN SCHIEFNER: It's always a matter of definition. On the other hand, I guess I can say it happens on a more or less regular basis and it's on a continuing basis that one or the other delegation just gets lame and stays lame.

AUDIENCE: Again, perfectly lame is the issue.

CARSTEN SCHIEFNER: Perfectly lame.

AUDIENCE: When you say they're recurring events, is it repeated offenders?

CARSTEN SCHIEFNER: Yeah.

AUDIENCE: That can be dealt with in one way or another.

CARSTEN SCHIEFNER: Yeah and that is exactly why we're discussing the issue here as in should we come within a more or less generalized idea about it or really as you put it on a casebycase basis by more or less private individuals?

AUDIENCE: My suggestion is and there's no one in the queue behind me so I'll keep talking in the mike. My personal opinion is that repeated offenders suggests dealing with this on a case by case basis. If it's a widespread disease, it probably needs to or might be helpful to have a measure general approach. But repeated offenders, that's something for the shame and blame, but I didn't say that.

CARSTEN SCHIEFNER: Anybody else? Obviously not. So my oh, yes.

AUDIENCE: I just want to know [unclear] isn't working. It is on. I just want to know what the conclusion is at this moment of the discussion that we had? What is the takeaway of the Chairs?

CHAIR: Well, what this Chair is taking away from it, Niall O'Reilly, is we have an action item to produce a draft guidance document for the RIPE NCC about operational problems. And that action item, Jim has agreed he will lead and we will take care that you see the document at an early draft stage.

AUDIENCE: But I heard the last speaker suggest, well don't go into that amount of overhead had and treat thing on his a case by case basis. That can be the content of the document but if that's the sort of direction if that is the conclusion of this room caught by the Chairs as an instruction to the document author, it would be good to know.

CHAIR: I think that would fit my version [unclear] conclusion of the room. Can I have a show of dissent please? Anybody who doesn't agree, can you raise your hand. The conclusion is that there will be a document guiding the NCC about how it should cope with operational problems in ENUM; it should be a lightweight enough document because we don't need to make a male of this but it should be supportive of the RIPE NCC and coming from this working group. And Patrik has a comment.

AUDIENCE: I think that's good. I think that kind of document is good but I think you have to be careful on what you word it and what kind of intention you would like to have in the document because we have to remember RIPE NCC is doing this as a global service, getting instructions from the IP. The ENUM working group in RIPE is sort of a subset we have subset of the various kind of services that are happening here that it's not serving only the RIPE community, this service. So I just want this working group, it's pretty easy because all of us are here, I don't want this working group to start giving instructions to something or do something that makes IBM happy.

CHAIR: Clearly that's very much to be avoided. Something very surreal is occurring to me, although we want to make a lightweight document, the Layer 9 and above considerations in this document are actually quite heavy. So it's going to be a topheavy lightweight document. But I think the people who have the clearest sense of the balance and the sensitivity that needs to be brought to the preparation of this document are all in the room and all will have sight of the document at an early stage.

AUDIENCE: If it's going to be so light, why do we need the document because any document will have Layer 9 implications? This is me talking on personal title.

CHAIR: Because I think we need to have some document that is a point of record because the repeated offending has been difficult to deal with in the past. I think we need to do there's been a simmering irritation among a number of members of the working group that whatever we do whatever we've done each time on a casebycase basis hasn't quite done it and we need to write something down.

AUDIENCE: Peter Koch once again. I rather like to see this operational problems a bit more qualified, even in the light of the objective that you say it should be lightweight document, for two reasons. One is we can trust the RIPE NCC to deal with the usual operational basis in a very competent manner they have shown over the last couple of years. And the other one is we actually not after these singlelame delegations or anything like that. So just keeping a very narrow focus of this. And one design criteria is having a lightweight document but not start dealing with lame delegations because that's making bad

CARSTEN SCHIEFNER: Peter you've just volunteered yourself to be part of the documentwriting process and to give input to that. Thank you very much.

CHAIR: That gives us action point 56.1 and Jim Reid has kindly agreed to be the lightweight editorial reader for that document. And I think applause from the next room. Very timely. I think we've spun this out for today. Is that the case?

AUDIENCE: Not really. I just want to clarify a little bit. I think the only sensitivity that I might see is whether the receiver of this document that we are producing is the RIPE NCC or IB, that is a typical example that might have some implications. It might be the case that the document should be sent to the IAB and ask the IAB, maybe you have to talk to the RIPE NCC. We need to think about it.

CHAIR: We need to think about that a little further face to face and will do it by email either privately or by the list.

CARSTEN SCHIEFNER: That [unclear] finishes that.

CHAIR: The next agenda item, F1, short news.

CARSTEN SCHIEFNER: This is a short update on the ENUM data.org website, which is the, in quotation marks, official website when it comes to information on Tier1 delegations. This information is provided by the registries themselves. This is how the website actually looks like.

We heard it already, delegation of plus 1, north American numbering plan is withdrawn since RIPE 55. The delegation of Switzerland plus 41 is, according to rumors I heard, likely to be withdrawn soon.

Here's a couple of how should I put it? Requests, actually, from the two Co-chairs of this working group. If you are Tier1 registry please check your registry for correctness and send any updates to the email address here. And everybody else, if you feel that the entry for a certain delegation over time has become sort of incorrect or incomplete or needs updating, you may want to contact the respective Tier1 registry to have them update their entry on this very website. So as you can see here, the website also specifies whether this data is in production, in trial, in hiatus, so on and so forth. So anyone with an interest in the registry Tier1, you could hit the website and get information about that. Again if he or she feels the information is not correct any longer, you may want to contact the ENUM Tier1 registry for that.

Also you can see that underlined as a link there's a list of standard questions. That brings me to the next point. If you think that the proposed list of standard questions should be modified or extended, please also contact us and send your suggestions to the following website so we have an opportunity to sneak those additional questions in. Which brings me to the end of the update on ENUM data.org. Make use out of it in both ways. Keep it up to date and if you have question on his a particular registry, hit the website and try to find your answers. Thank you.

(Applause)

CHAIR: Thank you. That brings us to item Y of the agenda. Any other business? Everybody's keeping the head down. Good. Then we pass to item Z which is just to remind you of the status of the action items. We had no open action items going into the beginning of the meeting. We have one action item generated from the meeting and that's to generate this ENUM operational document for coping with the problems that we've been having on and off intermittently. Jim Reid has kindly agreed to lead that effort and Carsten and myself and Patrik and Olaf will be among the contributors. I'm not sure whether Robert is looking at me trying not to nod or actually nodding but I'm sure Elle's be interested as well. That brings us with a minute or two to spare to the coffee queue. Thank you all for coming. The next meeting will be in Dubai and Carsten and I look forward to seeing most of you there again and having an interesting agenda for you there at that time as well. Thank you all for coming. Special thanks to our scribe, our stenographer, our technical support person, our jabber monitor. Did anything come in on jabber?

AUDIENCE: Couple people there. No discussion.

CHAIR: Next time we're going to run into your coffee break again. We promise.

AUDIENCE: And thanks to the Chairs.

(Applause)