The ENUM session commenced as follows:
NIALL O'REILLY: I guess everybody was late get to go coffee and had problems with the T‑shirt queue and our agenda isn't exactly packed so we can give people another couple of minutes. I am Neil O'Reilly you are sitting in the session of the ENUM Working Group so if you wanted to be in a different one now is your chance to leave. Somebody suggested I should welcome you all choosing some random language, the lot fell on English so you are all very welcome to this session of the ENUM work Working Group. We go a little behind but that shouldn't matter because we don't have too packed an agenda, this time.
We won't run into the coffee break for the simple reason that the next break is a lunch break. So, but moving along. I have made you all welcome ‑‑ I have tried to make you all well come, we have from the RIPE NCC nationally and Marco taking notes and watching out for the remote participants by Jabber. As you know if you come to the microphone you should say who you are, you may say what your affiliation is, you may wish to disambiguitative if you have several or just not do any. And Marco will dot same thing as proxy sends in by Jabber as well. Now, here is the first three session, three sections of the agenda. If we ‑‑ I won't move on to the next part of the agenda just yet because I want to deal with these ones first. The minutes of the last session, Dubai at RIPE 57 were sent out to the list and the deadline for comment on the minutes has long passed, also the date when I promised I would announce that the minutes were final, I didn't. So, unless somebody stands up and adds a very late comment, somebody stands up ‑‑ ‑‑ the stenography display isn't working. Hopefully we will get that fixed in a moment. But nobody is standing up to say that they have any objections to the minutes so I am declaring them final. OK. I am going to assume nobody is absolutely depending on the realtime scribing and I will move on. We have one action on the item list and on ‑‑ one item on the ah list. That was with Jim Reid to act as the editor for inputs that would come from the mailing list about the operational problems that we were perceiving I think about a year‑and‑a‑half ago. Jim tells me that he hasn't had any input so, as I think I mentioned on the mailing list already that, being the case since nobody is interested in contributing to that document, we will close the action item.
I won't call on Lawrence until we get the scribing thing fixed, but I will just in any case scan the rest of the agenda so that you know what is coming up. Lawrence Conroy who is been as, you know, very active in the IETF on ENUM side is going to tell us something about implementation issues and experiences. We will have the usual report from the RIPE NCC. Some short news and we dont' a plenary presentation relevant to ENUM so we won't have item G and we have one ‑‑ we have one interaction item with our groups and then we will have time for any other business and we will close in time for lunch.
So, now, I will call on Lawrence to give us our, if I can just find ‑‑ it should be this window, I guess. It's the 23 hour time‑lag from Dublin, it gets me like this. You want to use our own laptop. No, I want to use that one but I need the notes.
LAWRENCE CONROY: Obviously it's a paperless conference. Well, Lawrence Conroy, that is me. Those are the folks that paid for me whilst I was working on this and this is about experiences in ENUM.
I should point out a quick note, this work was done with the promise that the culprits would remain anonymous. So I am not going to say who did this, who did what and how they managed to screw up, but it was fine.
It started a long time ago when we realised that the specifications were writ in Marshal or something, I don't know. Jim Reid and I ran an ENUM plug test in I think 2005. Jim may have better memories than I have of that. And that was mostly ‑‑ to see how people could interpret the same specifications in different ways. And I hope it helped implement, that has been the aim. It's now RFC out for this and this is really a quick runthrough of what we had in that.
Here is a list of some of the more important documents specifying this stuff and a list of the some of the acronyms used. Obviously, the slide ‑‑ you can look at these in detail later. I think that is all the acronyms I have used. I hope people here know about DNS.
Well, let's go through the ‑‑ what is this stuff. ENUM was designed to map from phone numbers to URI via DNS using naptas, 2916 was the first one, you basically had a phone number that then you translated into a domain them and that included some new URIs.
The URIs we usually SIP but sometimes you need more than a single SIP and in the later version this was changed to phone numbers that mapped to ENUM services and URI. The real difference there was that the ENUM service was added, this identifies the kind of session reaction that you get when you use this URI. From an implementer's point of view, this actually tells you the kind prove gram you are going to need to run for this URI which is sometimes important.
Now let's look at the nap at that in detail. There are six fields there. It's an application of the dynamic delegation discovery system, I always have to read that because I can never remember it, DDDS. That specified in RSCs 401 to 3403 give or take a half. If you notice the documents are not that easy, could you argue that part of 3404 is included but then part of 3403 isn't included in the standard, so hey, you pay your money, you take your choice. If you see numbers in brackets these are the specifying RFCs.
For DDDS there are a few key things that defined how the application works. The first is what database it uses and how it stores the rules. Well for ENUM it's used DNS and it stoves its rules in nap at that. It's input is telephone numbers and using application unique strange that is an international phone number with everything except the number stripped out but still with the plus at the beginning. It generates its first key into the database by these steps, strips out non‑digits, reverses the character sequence, inter percents dots between each of those digits and then appends E 164 D Arpa and that gives awe domain name, you look that up in DNS and you get the NAPTRs out.
That sounds simple, what could go wrong? Well, we will skip this one but trust me, you are going to spend time on policies.
As I say there are six fields in a NAPTR. The order and P priority are numbers. The flag services and regular expression fields are strings and the replacement is domain name. Strings are UTFA, but the flags and the services are defined as as key only, sour not going to find any non ASCII characters there.
The regular expression is in two parts, it's an extended regular expression field, ERE, subfield and a replacement or repl subfield. The ERE doesn't need non ASCII, but it could have non ASCII in there if the person is doing provisioning is a muppet. It was pointed out that there is (AS K I.)you can have alternation and it's possible you could have a Nap at that with non ASCII characters in it in the bit of the extended regular express that does alternation which obviously is not the phone numbers. Phone numbers tend to be as key. But someone could, you know, trust me on this ‑‑ somebody will do it. So your system should not die if it sees something which is non ASCII.
The repl field should be just URL characters which means, again, it should be as key. If you are going to go for IR Is in the future encode them as describe in the IR ‑‑ URI document, international domain ‑‑ international resource identified, sorry. Looking at these fields in turn, the sort fields, there are two of them are the order and priority fields. These, again again people have managed to interpret these in a different way. Just make this one clear: The order is the major sort term; the priority is the minor sort term. Please do not get them around the wrong way, people have done that. Also, to be clear, that number one is the best, OK, so the numbers ‑‑ the lower numbers are good. Again, people have done it the other way.
The specks are confusing or let's be honest, unrealistic in places. They say that the losing order NAPTRs are not considered. To which my answer is, well, the clients don't ever just look at the order field. If they can't support ENUM service in the URI it's going to get discarded anyway it's a bit dangerous saying you should ignore them because you don't really ignore anything, in the end.
It also says that the sort for priority is optional; well, again, everything is optional. All the clients I see do use this as sorting so I think you should assume that is what is going to happen. And finally there are some subtle bits. Is the order and priority only considered in the current RR set? It's pretty obvious that that is the case but don't assume that it's obvious to everyone.
Now we get to the kind of amusing bit: Clients we have known. I should point, most of these things are now fixed, OK, but these are things where we have looked at different implementation and people have interpreted them in a different way. Some clients process the first record they see and discard the rest. I think I can say this because I don't ‑‑ I can't remember that the author was mentioned. In the early asterisk implementations of the ENUM service, before Otmar upgraded it, it grabbed the first NAPTR and processed it, if there was more than one it ignored the rest. It didn't bother working out the sort it, just grabbed it and did it. That has certainly been fixed but that is actually not, for the really, really old ones, that is not uncommon.
Some, as I say, just take the records in turn, don't bother sorting them, just process them one at a time. Some of them get confused when they find non‑terminal NAPTRs and just give us. Some discard every has thank has a lower order than the one they see even if they have rejected all of the ones with winning order which is interesting choice. This is particularly bad if the top one is, H 323 and all of your clients don't handle A323, they disregard that one did you don't reconsider they just stop. It's a great way of forcing people to go out over PTSN, don't do it, it's naughty. There is also a problem in the order in one domain is different from that in another one, you have a non‑terminal tap at that. Do you discard everyone in the domain that you follow a /T* to or if that one has got a better order do you discard everything after it? It's not that clear.
Let's look at the nice simple string field. The flags and the services field should be pretty simple. There is only one ENUM service ‑‑ correction, only one flag type in ENUM, that is you. That is defined in 3404 and basically, get what we get a URI out of this NAPTR. The syntax which looks pretty hideous there but is not that difficult, is E2 U followed by plus followed by ENUM services possibly followed by another plus, by another ENUM service and so on. The ENUM service itself could be broken down into accept rale elements using a colon character as internal delimiter, some do and some don't. This is important: There can be more than one ENUM service in a NAPTR, there is only one URI. And these basically tell you the kind of actions that you can do with this URI. And also, there is ‑‑ because it's a DDDS application, all DDDS applications ininherit the MT flag which is non‑terminal NAPTR or rule. In this case, I will come on to that in a little while because non‑terminal are a good idea in some ways but really painful in others.
OK. These are odd things I have seen in the field. As you can see, some people assume that the syntax of the services field is always that way even if it's a non‑terminal. That is bad news because that isn't the case. They then expect to find something in the services field, find it's empty and fall over. Or at least just abandon the query. Some of them misinterpret the services field, as far as I can tell what they do is look for the ETU, then for the plus and then assume that everything after that is a single ENUM service. And surprisingly, that fails. (Unsurprisingly). Also those that did, this one was only a temporary problem, but it did happen, so I will mention it. The ones that did handle more than one ENUM service, they ‑‑ it they didn't like any of the ENUM services in there they would just give up at that point. The real action you should do is that if you don't understand or don't want to use one of them, go on to the next one. Which might seem obvious but apparently wasn't. And some of them decided to do this in a left to right order; some in a right to left order. This actually does matter. If you look at the example there I have got which is voice plus SMS plus fax, does this mean that the person provisioning this actually wants you to have a voice call with them if, that doesn't work, OK, go for SMS, and if that doesn't work, go for a fax? Or do they really, really want to have a fax and if that doesn't work send them a text and if that doesn't work, send them a voice call. So, you need to know whether to deal with these on right to left or other way around.
Finally there was, polite word is simple clients, that ignored everything, that grabbed a URI and that will do. These didn't look like these things were doing the old style 2916 processing, but they may have been. It wasn't obvious.
Now, we get ‑‑ that was relatively simple. Now we get to the regular expression field. This one has lots and lots of enjoyable things for implementers. It's fairly well‑defined in 3402 and 3403. As I say, for ENUM, we are generating a URI out of this lot, and possibly at least in theory you could generate a non‑terminal key wastefully qualified domain name in our case. You have a delimiter, you should have three, all together, followed by extended regular express, then another delimiter, followed by replacement field and possibly followed by I flag. I should point out the colour is is a bit less vivid in the version that there is on‑line you will see that as bright red, it should be bright red and flashing. Please do not use this.
The entertainment of this field is the fact that it is almost impossible to find a delimiter which is not valid in a URL or is not significant in extended regular expression. So trust me, you are going to get really used to putting scaping in for this. That means that you have to put in the back slash. However, we are talking about DNS here, so that actually means you need to put in two back slashes. A very, very common problem is actually that you look at the ‑‑
AUDIENCE SPEAKER: I think you are mixing up problems with quoting in provisioning system with quoting in the DNS. And I think it's important that you keep those things separate.
LAWRENCE CONROY: I agree. I downed stand the difference. The point is that I understand it but an all of lot of the implementers don't. As far as they are concerned, there is only one back slash, that is what you get in the zone file.
AUDIENCE SPEAKER: In that case I think it's even more important that you use this correct terminology when you try explain the problems. So your question is, what did I say? What you said but this is DNS, so you have to quote it ‑‑
LAWRENCE CONROY: Fine, OK.
AUDIENCE SPEAKER: That is the DNS issue. If you would have said, in most provisioning systems specifically if you had the zone file as a text file then you might have to quote once again to get the characters in there. It's fine for me but it's not a DNS problem.
LAWRENCE CONROY: OK. I am being lazy and I apologise.
AUDIENCE SPEAKER: You don't have to apologise.
LAWRENCE CONROY: Oh, I do. Remember, these guys are usually telecom implementers. They can just about grasp the fact that they have got text files that they have got to put into bind or something. If you try and explain to them why they have to do what they have to do, I just wish I had Patrik there to explain it because co‑put it so much bet. (He could) if you say I don't care what it is and what time of the night it is for you in Taiwan, just put two back slash characters in the text file. They understand.
Patrik: One of the reasons why I think this is important is that the problem is actually much worse than what you explain. Because when you said just put a back slash there, that implies that all provisioning systems works the same and you need the same quoting, which is not true, unfortunately. So it is a royal nightmare.
LAWRENCE CONROY: That is such a polite way of putting it. I am going to skip this one and go on to the things we have found because ‑‑
AUDIENCE SPEAKER: Do some additional nitpicking here. The back slash problem, we will say is to do with primarily with provisioning and the context here we talk about bind in many cases and confuse that with DNS and the bind passing of text based zone files has its own characteristics and you may have other mechanisms where you may have a text based file which is then fed file which is fed into back end database. So Patrik is quite correct to say that but we have got to be careful here that delimiters and back slash, yes, you have to be careful with them but the caution is not necessarily DNS; it may be a DNS implementation. (ADNS).
LAWRENCE CONROY: I don't know about ADNS, I think thinking of another non‑bind with databases, yes indeed. Just be careful out there, guys. I think that is the short summary.
Now things we have found. As ‑‑ I have ‑‑ I stand corrected, I should be much more precise in these things, but escaping or the lack of escaping and formats, master file formats and things like that are an issue. I have to say that a large number of clients don't actually bother with the extended regular express, they assume that it's just going to be as you see there, dot star. Then some of them assume that the URI is going to be static test, i.e. there are no replacements with sub expressions. A large number of clients, although I don't know if this is true now but it was certainly true about two, three years ago, assume that the delimiter will be exclamation mark. They are hard‑wired to do that. Now, that that can become a real challenge if you don't happen to use exclamation marks, so in general I would strongly strongly recommend that people actually use that. You don't have to if you know that the clients and the provisioning systems are going to use the same one but I would strongly recommend it because most implementers seems to look at the examples and every single example using exclamation mark as a delimiter. I think that one can occur in a URI so if it does you have got a problem there.
Speaking of problems, (URI) you will see that at the risk of getting Patrik and Jim to stand up again, a lot of the clients don't seem to deal with back slashes, or rather escaping when these things do exist in the DNS response. I think that is ‑‑ I have got to be careful here. You can occasionally see a ‑‑ escaping in a DNS response, however it got there. Some clients don't expect to see that character and ignore it, which then means that they just see a delimiter without noticing that this has been escaped, usually in the Repl field which means they don't actually work right. And again, I did say that things with big red flashing lights do not use the I flag, it is pointless. Numbers, which is what we are going to shall matching against, are case incentive, they are also as key but case insensitivity flag doesn't help anyone. And it does break some clients, particularly those that are just looking for static test. What they actually do is they get to the delimiter in the middle, having got to that, they just grab everything except for the last character. You can tell this particularly for web URIs because those are the clients that will still an exclamation on the end of the web URI and then try and use it, it's a subtle one but it's quite amusing to debug. And then of course, there are the really primitive ones that just grab ‑‑ ignore everything in the NAPTR and grab the URI anyway.
Patrik: As many people in this room now, I am one of the evil inventors of this crap thing that Lawrence is talking about
SPEAKER: It's not ugly, just ‑‑
Patrik: This is a little bit drastic of course, but one of the things of course that I have noticed and that you might have seen in some of the RFCs, I am strongly encouraging people that invents standards to not use the NAPTR record. That is the first statement. The second one: Is it the case that the last slide of yours is is a question should we do ENUM version two without NAPTRs while we don't have any real dig deployment? Is that the question you are going to end this session with because I think that is an interesting thing to spend sometime and talk about.
SPEAKER: That is indeed but I would quite like if we got NAPTRs fixed because I think they are fixable. But that is ‑‑ I know the agenda is fairly empty at the moment but that is a long discussion and you know it's a long discussion.
AUDIENCE SPEAKER: Should we have the discussion?
LAWRENCE CONROY: Of course we should. But do you want to have it today? I would quite like to eat lunch.
AUDIENCE SPEAKER: If we are going to have it today maybe we should wait until after the dinner and see you all in the bar.
LAWRENCE CONROY: I think ‑‑ you know and I know it is going to take a lot longer than just a few beers to sort this one out. One of the reasons I think we don't have wide deployment is because it's taken so long to get the standards done (long to) and even then the standards are unreadable. But over a beer.
Again, if wasn't complex enough, there is the regular expression field versus the replacement field. This is in partial answer to your question about not using NAPTRs, I think the problem is not so much that as DDDS is over generalised and actually deals with URNs and URLs and the problem we have got in ENUM is that we have domain names that are in the reversed character direction from the application unique string. This means that in principle, you should be able to use the regular expression field to generate a domain name in practice, this is pretty much impossible. It is certainly infeasible. This is maybe the most contentious bit but in some ways the most difficult bit. If you happen to be in North America, you don't have a problem because I can generate a regular express and produce a tell foam number based in ENUM domain name from that, but if you try to deal with Austria and Germany and Switzerland where they have open number plans you don't it or at least it's extremely hard for you to do it. And actually, Germany, Austria and Switzerland do exist.
So, we give some guidance in the up date versions to say, well, you use the regular expression if you have got a non‑terminal NAPTR and you use the replace the field which, guess what, holds fully qualified domain name when you have got non‑terminal. You don't try and do both. I have had engineers claiming they can do it, writing a whole bunch of hideously complex provisioning stuff to try and produce regular expresses to do that, and for getting that Europe exists, to which the answer is no, that isn't good enough. In this particular case in the update it looks like we are probably going to ignore this or just say please don't try this because it won't work.
And that is my last slide. As Patrik said, NAPTRs are very, very flexible, but they are also (NAPTR) but they are lass challenge, should we update this, should we fix the specks (N) particularly 3401 through 3404, or should we just try and throw it away and start again. Questions.
NIALL O'REILLY: I am inviting questions.
AUDIENCE SPEAKER: Thank you, Peter Koch. I know you would rather wish you had Patrik here. I you have been picking on NAPTR for quite a while and there are operational reasons to do that and I am not questioning your motives here but one observation, maybe: The reason that this whole DDDS thing came into play was that someone found out when NAPTR ‑‑ and Patrik might correct me later ‑‑ the RFC for NAPTR was reissued, it was embedded into the whole DDDS scheme, right so, there is no ‑‑ there is no protocally correct way to just use, you can only Tuesday with K DDDS or A NAPTR and UNAPTR, what ‑‑ what seems to be missing and what seems to make the life harder for the programmers and implementers of these provisioning systems is that there is no generic DDDS library. If that would exist, things would likely be easier because it seems people are running into these bit stuff and implementing the gory details over and over again which is the same as if anyone would have to implement their own IP stack.
LAWRENCE CONROY: I did say that DDDS is over general. If you want add general DDDS library, it would probably be larger than would fit on a mobile phone. Probably be larger than all of the software that fits on a mobile phone. Also, there is this wonderful EU term subsidiarity, and in the case of DDDS, it is unclear which is the core bit and which is application‑specific, because understandably, DDDS tries to sort of leave the specification off to the individual DDDS applications. The problem is that in, things like non‑terminals, they are common, so ‑‑ they are. They are only specified in 3403 and 3404, in any detail at all. If you went through and generated a DDDS library, you would then need to sort of have some modifications to deal with the individual application you are going to do because in some ways they are overgeneral and in some cases the applications almost override what is possible in DDDS and certainly the case I was making in this slide, sorry in this slide, for generating fully qualified domain name, you really cannot do it realistically, OK. And the biggest problem, I think, is going to be the provisioning system. That is not so much just a basic library; the provisioning system is going to be a real pain in the neck whatever you do, in my opinion.
Patrik: I don't think it's possible to do a generic DDDS library either. I think that is a waste of time. What could be interesting and what I have seen are some sort of application‑specific things which are implemented for ENUM. But a more generic question regarding these various issues that you have found, specifically as they are either NAPTR or DDDS specific, both of those ‑‑ both DDDS and the cause of that NAPTR is used if RFID space and ONS. Have you been in contact with the ONS people and stuff to see whether your findings are similar to theirs, whether some of your suggestion are things that help them or maybe ‑‑ or is making life harder for them?
LAWRENCE CONROY: No, the short answer is no no because I have been focused often the pure telecom side of it.
Patrik: Is there anyone in the room that work with ONS?
LAWRENCE CONROY: Which is interesting in its own right, by the way. I think it's interesting that there is nobody who has actually been working on RFIDs and things like that, within this room, although you'd right, you are right ‑‑
AUDIENCE SPEAKER: It's an e‑mail ‑‑
LAWRENCE CONROY: I think ENUM will be the major user of NAPTRs and DDDS, you would kind of people that ‑‑ the fact that I don't think anyone has is slightly worrying.
JIM REID: Maybe all the RFID geeks that are here at the RIPE meeting in the EIX Working Group think about thousand get into the computer rooms with badges.
I think the question is that there is lot of useful information you have gathered for this but I think to my mind, maybe for this Working Group, the question might be is what can we use or capitalise on that? For example, maybe there could be attempts to try and produce some more test cases, even test bed. Patrik was on the back end on the provisioning side of things but also need things for clients and just as you were talking, I was thinking back of some of the tests we did, and we were able to sort of push the boundary as little bit and get clients to break various interesting and entertaining ways and I have this thought, if we use the regular express substitution fields we could results from the Napster procession turn 53 bites long and that could be entertaining to try something like that. And I wonder if there is anybody here interested in trying to put together some sort of test bed to try and do torcher testing on clients as well as torcher testing on back end provisioning systems?
LAWRENCE CONROY: I think that is an extremery good idea. When we did the plug test, we collected a lot of information about how clients fail. I will say no more than that about the plug test because that was all done under chat a.m. house rules. But both Jim and I, at the time, and I feel that even more so now, both of us think that it's a very good idea to have on‑line torture tests and a maintained set of evil NAPTRs to see what you can break. The buffer overflow one, I wasn't going to mention here live on the microphone, that was going to be an Easter beg if thank people could find if they bothered looking at the latest version of the standards and RSC 5483 because it's certainly mentioned there. It's about the first thing I did, actually. And yes, it did crash the mobile phone with ENUM client on it. But that is their fault for using fixed buffers. But it certainly is something that can happen. Don't always assume that these things are mistakes on the part of people. It's quite easy to misconfigure things in such a nasty way that they do break a lot of clients. I mean, if you could break an Acmi packet just by making do a phone number lookup, wouldn't that be fun? Because could you take out a very significant proportion of all of the next generation networks. Should we do have inter op testing? Yes we should. Should we have torture testing, yes, definitely.
NIALL O'REILLY: Thanks, Lawrence. (Applause)
That was an amazingly thorough, at times it seemed to be almost nostalgic lookback on things you have had to struggle with. Thanks, too, to the questioners who tried to keep you on track or divert you on to theirs, I am not sure which. So let's move onto the next ‑‑ let's see if I can find the agenda again. That wasn't the thing I was looking for but I will members it now. One of the the ongoing actives has been the ENUM data .org website and essentially we put their stuff that people responsible for tier 1s or people responsible for planning pilots in their country or in their international country codes or whatever will send us so the data that is there is only as good as what you send us in and I am happy to say it was updated earlier this morning because I got some data from the latest country to go live, who went live a few weeks back, about what, six weeks ago? Yes. So there are now nine country codes which have proclaimed live ENUM production ENUM in their number spaces. And the latest one of course is plus 44, which is the UK.
Now, if anybody else has activity that they want to (activity that) keep us informed of, send it to the e‑mail address on the slide and this site has kindly provided by Kim Davies who is a former chair of this Working Group and he has continued to host it, even though he has passed on the baton to cars sten and me.
AUDIENCE SPEAKER: Co‑chair of this question. It's not really a question, it's rather extension of the first plays, not only if you are responsible for tier 1 ENUM registry but also if you know somebody who is responsible of a tier 1 ENUM registry that would be absolutely helpful if that person could poke the other person to send us updates. If you look at the website coming up object the screen here. If you spot something wrong or not entirely correct please be in touch.
CHAIR: There is a standard list of questions and the responses are best sent in as plain text, please. And that done, let's move on to the RIPE NCC report, the tier 0 report from Anand and this should be the 11:54 one.
ANAND BUDDHEV: Yes. Good morning, everyone. I am Anand bud deaf DNS services manager at RIPE NCC and here to provide update about ENUM operations. (RIPE NCC).
So the RIPE NCC is the tier 0 ENUM registry. We manage the E164. Arp zone and we have done this since 2002. Operations are quite stable. It's not a particularly busy zone. The server that we operate here in the Netherlands receives about half a query a second. So it's not particularly busy.
Since November 2007, this zone has also been signed, so we accept secure delegations.
And what we aim to do is a review of the DNSSEC policies and procedures for this zone after RIPE 58.
Changes in delegations: There has been one new delegation since RIPE 57, and that is Taiwan, and this was delegated in 2008, November. So there are current total of 46 delegations. Two of these are signed and have delegation sign records and that is Poland and the Czech Republic.
The RIPE NCC has a project, a lameness measurement project, and we also monitor the ENUM zone in this project and I have got some numbers here to present.
We have discovered that 6 of the zones have at least one lame delegation and 3 have all lame delegations. And this is presented here in a pie chart. And finally, a little plug for the DNSMON service that my colleagues in the information services department run; they are now able to offer monitoring for ENUM zones, there is a special category for this and it costs 500 euros a year. And if you have questions about this, please contact our colleagues at DNSMON‑sales@ripe.net. And that is about it from me, brief update and I am happy to take questions.
AUDIENCE SPEAKER: Co‑chair of this Working Group. You used to have statistics on non‑delegated country codes. Is that still something you are running because that would sort of ‑‑ give us an indication what ‑‑ some demand would be for.
ANAND BUDDHEV: I remember that, we presented the statistic at RIPE 57, but it was more one of exercise rather than a continuous monitoring, so I don't have numbers for this meeting, but if it's something that people feel we should do on a continuous basis, you know we are happy to take that away as input and make it an action item.
AUDIENCE SPEAKER: Possibly, that came across with a question already. I am interested in that but obviously I cannot speak every participant here.
ANAND BUDDHEV: Perhaps I could have a show of hands if other people think this is useful and would like to see the statistic.
NIALL O'REILLY: I think the ‑‑ since the Working Group exists outside of the meeting on the mailing list, I think the action item in the first place should be with cars sten to try to gauge from the mailing list what the interest is, and if you ‑‑ if you want to go ahead in the background preparing for an anticipated result, of course we won't forbid you.
ANAND BUDDHEV: Great, thanks. Any other questions? In that case, thank you for listening.
(Applause)
NIALL O'REILLY: And that brings us to the last page of the agenda. There is item X which is the interaction with other Working Groups. There is nothing for to us do about policy proposal 2008 ‑ 05 because that is working its way through the Address Policy company and I think that one nearing completion (Working Group). We will be quite happy when it comes through because it means that ENUM operators at tier 1 will also qualify for accommodation in the Anycast, in the Address Policy which allows special allocations for Anycast.
And that brings us to any other business: Deneche Babuta would like to say something.
SPEAKER: Just a quick update about UK ENUM. Just in case people don't know, UK ENUM is run by the UK ENUM consortium and not for profit, governing body in the UK and with the blessing of the department for business, and we have given NomiNet a contract for the next five years to do the registry services. So since Dubai, there has been some changes, we have been keeping an eye on a new group that are looking at infrastructure ENUM with a view to having them come into the UK ENUM consortium fold. We also have a official secretariat that we appointed recently, political intelligence, they also like after ITSPA stuff and another thing we are doing before the AGM, which has to happen by the end of June and we are looking at memorandum and articles of association and tying them down quite strongly and that will go to a vote for the membership. And the AGM is going to be basically an open information day in the morning, for the public, and during the afternoon we will have the AGM with the voting and the new directors to be voted in. We also now have ‑‑ in Dubai we didn't' have any validation agents on the board and at the time NomiNet were looking at becoming a validation agent of last resort. Luckily by the end of the year we had a few applications, we now have two accredited validation agents and another two being processed. ENUM launched for registrations on 11 March and as far as I believe there is only one registration at the moment. And that is it. Any questions? No. Thank you.
(Applause)
CHAIR: One other item under any other business is your co‑chairs have been poked or one or two private e‑mails wondering if there is scope for talking about infrastructure ENUM in this Working Group, and if there is interest among the Working Group we are happy to see that line of discussion develop as well. I don't ask for anybody to ‑‑ I don't forbid anybody to stand up now but I don't expect it but if people want to throw some that have into the agenda for the next meeting, that would be fine. And if there is other ‑‑ any other business? Nobody is standing up, so it remains for me to thank all of you for coming but especially nationally and Marco. Nothing from Jabber, Marco? No. All is quiet. Natalie and Marco and all the meeting things for making things run smoothly and when all the things that didn't happen at first. Thank you and enjoy your lunch.
NIALL O'REILLY: I guess everybody was late get to go coffee and had problems with the T‑shirt queue and our agenda isn't exactly packed so we can give people another couple of minutes. I am Neil O'Reilly you are sitting in the session of the ENUM Working Group so if you wanted to be in a different one now is your chance to leave. Somebody suggested I should welcome you all choosing some random language, the lot fell on English so you are all very welcome to this session of the ENUM work Working Group. We go a little behind but that shouldn't matter because we don't have too packed an agenda, this time.
We won't run into the coffee break for the simple reason that the next break is a lunch break. So, but moving along. I have made you all welcome ‑‑ I have tried to make you all well come, we have from the RIPE NCC nationally and Marco taking notes and watching out for the remote participants by Jabber. As you know if you come to the microphone you should say who you are, you may say what your affiliation is, you may wish to disambiguitative if you have several or just not do any. And Marco will dot same thing as proxy sends in by Jabber as well. Now, here is the first three session, three sections of the agenda. If we ‑‑ I won't move on to the next part of the agenda just yet because I want to deal with these ones first. The minutes of the last session, Dubai at RIPE 57 were sent out to the list and the deadline for comment on the minutes has long passed, also the date when I promised I would announce that the minutes were final, I didn't. So, unless somebody stands up and adds a very late comment, somebody stands up ‑‑ ‑‑ the stenography display isn't working. Hopefully we will get that fixed in a moment. But nobody is standing up to say that they have any objections to the minutes so I am declaring them final. OK. I am going to assume nobody is absolutely depending on the realtime scribing and I will move on. We have one action on the item list and on ‑‑ one item on the ah list. That was with Jim Reid to act as the editor for inputs that would come from the mailing list about the operational problems that we were perceiving I think about a year‑and‑a‑half ago. Jim tells me that he hasn't had any input so, as I think I mentioned on the mailing list already that, being the case since nobody is interested in contributing to that document, we will close the action item.
I won't call on Lawrence until we get the scribing thing fixed, but I will just in any case scan the rest of the agenda so that you know what is coming up. Lawrence Conroy who is been as, you know, very active in the IETF on ENUM side is going to tell us something about implementation issues and experiences. We will have the usual report from the RIPE NCC. Some short news and we dont' a plenary presentation relevant to ENUM so we won't have item G and we have one ‑‑ we have one interaction item with our groups and then we will have time for any other business and we will close in time for lunch.
So, now, I will call on Lawrence to give us our, if I can just find ‑‑ it should be this window, I guess. It's the 23 hour time‑lag from Dublin, it gets me like this. You want to use our own laptop. No, I want to use that one but I need the notes.
LAWRENCE CONROY: Obviously it's a paperless conference. Well, Lawrence Conroy, that is me. Those are the folks that paid for me whilst I was working on this and this is about experiences in ENUM.
I should point out a quick note, this work was done with the promise that the culprits would remain anonymous. So I am not going to say who did this, who did what and how they managed to screw up, but it was fine.
It started a long time ago when we realised that the specifications were writ in Marshal or something, I don't know. Jim Reid and I ran an ENUM plug test in I think 2005. Jim may have better memories than I have of that. And that was mostly ‑‑ to see how people could interpret the same specifications in different ways. And I hope it helped implement, that has been the aim. It's now RFC out for this and this is really a quick runthrough of what we had in that.
Here is a list of some of the more important documents specifying this stuff and a list of the some of the acronyms used. Obviously, the slide ‑‑ you can look at these in detail later. I think that is all the acronyms I have used. I hope people here know about DNS.
Well, let's go through the ‑‑ what is this stuff. ENUM was designed to map from phone numbers to URI via DNS using naptas, 2916 was the first one, you basically had a phone number that then you translated into a domain them and that included some new URIs.
The URIs we usually SIP but sometimes you need more than a single SIP and in the later version this was changed to phone numbers that mapped to ENUM services and URI. The real difference there was that the ENUM service was added, this identifies the kind of session reaction that you get when you use this URI. From an implementer's point of view, this actually tells you the kind prove gram you are going to need to run for this URI which is sometimes important.
Now let's look at the nap at that in detail. There are six fields there. It's an application of the dynamic delegation discovery system, I always have to read that because I can never remember it, DDDS. That specified in RSCs 401 to 3403 give or take a half. If you notice the documents are not that easy, could you argue that part of 3404 is included but then part of 3403 isn't included in the standard, so hey, you pay your money, you take your choice. If you see numbers in brackets these are the specifying RFCs.
For DDDS there are a few key things that defined how the application works. The first is what database it uses and how it stores the rules. Well for ENUM it's used DNS and it stoves its rules in nap at that. It's input is telephone numbers and using application unique strange that is an international phone number with everything except the number stripped out but still with the plus at the beginning. It generates its first key into the database by these steps, strips out non‑digits, reverses the character sequence, inter percents dots between each of those digits and then appends E 164 D Arpa and that gives awe domain name, you look that up in DNS and you get the NAPTRs out.
That sounds simple, what could go wrong? Well, we will skip this one but trust me, you are going to spend time on policies.
As I say there are six fields in a NAPTR. The order and P priority are numbers. The flag services and regular expression fields are strings and the replacement is domain name. Strings are UTFA, but the flags and the services are defined as as key only, sour not going to find any non ASCII characters there.
The regular expression is in two parts, it's an extended regular expression field, ERE, subfield and a replacement or repl subfield. The ERE doesn't need non ASCII, but it could have non ASCII in there if the person is doing provisioning is a muppet. It was pointed out that there is (AS K I.)you can have alternation and it's possible you could have a Nap at that with non ASCII characters in it in the bit of the extended regular express that does alternation which obviously is not the phone numbers. Phone numbers tend to be as key. But someone could, you know, trust me on this ‑‑ somebody will do it. So your system should not die if it sees something which is non ASCII.
The repl field should be just URL characters which means, again, it should be as key. If you are going to go for IR Is in the future encode them as describe in the IR ‑‑ URI document, international domain ‑‑ international resource identified, sorry. Looking at these fields in turn, the sort fields, there are two of them are the order and priority fields. These, again again people have managed to interpret these in a different way. Just make this one clear: The order is the major sort term; the priority is the minor sort term. Please do not get them around the wrong way, people have done that. Also, to be clear, that number one is the best, OK, so the numbers ‑‑ the lower numbers are good. Again, people have done it the other way.
The specks are confusing or let's be honest, unrealistic in places. They say that the losing order NAPTRs are not considered. To which my answer is, well, the clients don't ever just look at the order field. If they can't support ENUM service in the URI it's going to get discarded anyway it's a bit dangerous saying you should ignore them because you don't really ignore anything, in the end.
It also says that the sort for priority is optional; well, again, everything is optional. All the clients I see do use this as sorting so I think you should assume that is what is going to happen. And finally there are some subtle bits. Is the order and priority only considered in the current RR set? It's pretty obvious that that is the case but don't assume that it's obvious to everyone.
Now we get to the kind of amusing bit: Clients we have known. I should point, most of these things are now fixed, OK, but these are things where we have looked at different implementation and people have interpreted them in a different way. Some clients process the first record they see and discard the rest. I think I can say this because I don't ‑‑ I can't remember that the author was mentioned. In the early asterisk implementations of the ENUM service, before Otmar upgraded it, it grabbed the first NAPTR and processed it, if there was more than one it ignored the rest. It didn't bother working out the sort it, just grabbed it and did it. That has certainly been fixed but that is actually not, for the really, really old ones, that is not uncommon.
Some, as I say, just take the records in turn, don't bother sorting them, just process them one at a time. Some of them get confused when they find non‑terminal NAPTRs and just give us. Some discard every has thank has a lower order than the one they see even if they have rejected all of the ones with winning order which is interesting choice. This is particularly bad if the top one is, H 323 and all of your clients don't handle A323, they disregard that one did you don't reconsider they just stop. It's a great way of forcing people to go out over PTSN, don't do it, it's naughty. There is also a problem in the order in one domain is different from that in another one, you have a non‑terminal tap at that. Do you discard everyone in the domain that you follow a /T* to or if that one has got a better order do you discard everything after it? It's not that clear.
Let's look at the nice simple string field. The flags and the services field should be pretty simple. There is only one ENUM service ‑‑ correction, only one flag type in ENUM, that is you. That is defined in 3404 and basically, get what we get a URI out of this NAPTR. The syntax which looks pretty hideous there but is not that difficult, is E2 U followed by plus followed by ENUM services possibly followed by another plus, by another ENUM service and so on. The ENUM service itself could be broken down into accept rale elements using a colon character as internal delimiter, some do and some don't. This is important: There can be more than one ENUM service in a NAPTR, there is only one URI. And these basically tell you the kind of actions that you can do with this URI. And also, there is ‑‑ because it's a DDDS application, all DDDS applications ininherit the MT flag which is non‑terminal NAPTR or rule. In this case, I will come on to that in a little while because non‑terminal are a good idea in some ways but really painful in others.
OK. These are odd things I have seen in the field. As you can see, some people assume that the syntax of the services field is always that way even if it's a non‑terminal. That is bad news because that isn't the case. They then expect to find something in the services field, find it's empty and fall over. Or at least just abandon the query. Some of them misinterpret the services field, as far as I can tell what they do is look for the ETU, then for the plus and then assume that everything after that is a single ENUM service. And surprisingly, that fails. (Unsurprisingly). Also those that did, this one was only a temporary problem, but it did happen, so I will mention it. The ones that did handle more than one ENUM service, they ‑‑ it they didn't like any of the ENUM services in there they would just give up at that point. The real action you should do is that if you don't understand or don't want to use one of them, go on to the next one. Which might seem obvious but apparently wasn't. And some of them decided to do this in a left to right order; some in a right to left order. This actually does matter. If you look at the example there I have got which is voice plus SMS plus fax, does this mean that the person provisioning this actually wants you to have a voice call with them if, that doesn't work, OK, go for SMS, and if that doesn't work, go for a fax? Or do they really, really want to have a fax and if that doesn't work send them a text and if that doesn't work, send them a voice call. So, you need to know whether to deal with these on right to left or other way around.
Finally there was, polite word is simple clients, that ignored everything, that grabbed a URI and that will do. These didn't look like these things were doing the old style 2916 processing, but they may have been. It wasn't obvious.
Now, we get ‑‑ that was relatively simple. Now we get to the regular expression field. This one has lots and lots of enjoyable things for implementers. It's fairly well‑defined in 3402 and 3403. As I say, for ENUM, we are generating a URI out of this lot, and possibly at least in theory you could generate a non‑terminal key wastefully qualified domain name in our case. You have a delimiter, you should have three, all together, followed by extended regular express, then another delimiter, followed by replacement field and possibly followed by I flag. I should point out the colour is is a bit less vivid in the version that there is on‑line you will see that as bright red, it should be bright red and flashing. Please do not use this.
The entertainment of this field is the fact that it is almost impossible to find a delimiter which is not valid in a URL or is not significant in extended regular expression. So trust me, you are going to get really used to putting scaping in for this. That means that you have to put in the back slash. However, we are talking about DNS here, so that actually means you need to put in two back slashes. A very, very common problem is actually that you look at the ‑‑
AUDIENCE SPEAKER: I think you are mixing up problems with quoting in provisioning system with quoting in the DNS. And I think it's important that you keep those things separate.
LAWRENCE CONROY: I agree. I downed stand the difference. The point is that I understand it but an all of lot of the implementers don't. As far as they are concerned, there is only one back slash, that is what you get in the zone file.
AUDIENCE SPEAKER: In that case I think it's even more important that you use this correct terminology when you try explain the problems. So your question is, what did I say? What you said but this is DNS, so you have to quote it ‑‑
LAWRENCE CONROY: Fine, OK.
AUDIENCE SPEAKER: That is the DNS issue. If you would have said, in most provisioning systems specifically if you had the zone file as a text file then you might have to quote once again to get the characters in there. It's fine for me but it's not a DNS problem.
LAWRENCE CONROY: OK. I am being lazy and I apologise.
AUDIENCE SPEAKER: You don't have to apologise.
LAWRENCE CONROY: Oh, I do. Remember, these guys are usually telecom implementers. They can just about grasp the fact that they have got text files that they have got to put into bind or something. If you try and explain to them why they have to do what they have to do, I just wish I had Patrik there to explain it because co‑put it so much bet. (He could) if you say I don't care what it is and what time of the night it is for you in Taiwan, just put two back slash characters in the text file. They understand.
Patrik: One of the reasons why I think this is important is that the problem is actually much worse than what you explain. Because when you said just put a back slash there, that implies that all provisioning systems works the same and you need the same quoting, which is not true, unfortunately. So it is a royal nightmare.
LAWRENCE CONROY: That is such a polite way of putting it. I am going to skip this one and go on to the things we have found because ‑‑
AUDIENCE SPEAKER: Do some additional nitpicking here. The back slash problem, we will say is to do with primarily with provisioning and the context here we talk about bind in many cases and confuse that with DNS and the bind passing of text based zone files has its own characteristics and you may have other mechanisms where you may have a text based file which is then fed file which is fed into back end database. So Patrik is quite correct to say that but we have got to be careful here that delimiters and back slash, yes, you have to be careful with them but the caution is not necessarily DNS; it may be a DNS implementation. (ADNS).
LAWRENCE CONROY: I don't know about ADNS, I think thinking of another non‑bind with databases, yes indeed. Just be careful out there, guys. I think that is the short summary.
Now things we have found. As ‑‑ I have ‑‑ I stand corrected, I should be much more precise in these things, but escaping or the lack of escaping and formats, master file formats and things like that are an issue. I have to say that a large number of clients don't actually bother with the extended regular express, they assume that it's just going to be as you see there, dot star. Then some of them assume that the URI is going to be static test, i.e. there are no replacements with sub expressions. A large number of clients, although I don't know if this is true now but it was certainly true about two, three years ago, assume that the delimiter will be exclamation mark. They are hard‑wired to do that. Now, that that can become a real challenge if you don't happen to use exclamation marks, so in general I would strongly strongly recommend that people actually use that. You don't have to if you know that the clients and the provisioning systems are going to use the same one but I would strongly recommend it because most implementers seems to look at the examples and every single example using exclamation mark as a delimiter. I think that one can occur in a URI so if it does you have got a problem there.
Speaking of problems, (URI) you will see that at the risk of getting Patrik and Jim to stand up again, a lot of the clients don't seem to deal with back slashes, or rather escaping when these things do exist in the DNS response. I think that is ‑‑ I have got to be careful here. You can occasionally see a ‑‑ escaping in a DNS response, however it got there. Some clients don't expect to see that character and ignore it, which then means that they just see a delimiter without noticing that this has been escaped, usually in the Repl field which means they don't actually work right. And again, I did say that things with big red flashing lights do not use the I flag, it is pointless. Numbers, which is what we are going to shall matching against, are case incentive, they are also as key but case insensitivity flag doesn't help anyone. And it does break some clients, particularly those that are just looking for static test. What they actually do is they get to the delimiter in the middle, having got to that, they just grab everything except for the last character. You can tell this particularly for web URIs because those are the clients that will still an exclamation on the end of the web URI and then try and use it, it's a subtle one but it's quite amusing to debug. And then of course, there are the really primitive ones that just grab ‑‑ ignore everything in the NAPTR and grab the URI anyway.
Patrik: As many people in this room now, I am one of the evil inventors of this crap thing that Lawrence is talking about
SPEAKER: It's not ugly, just ‑‑
Patrik: This is a little bit drastic of course, but one of the things of course that I have noticed and that you might have seen in some of the RFCs, I am strongly encouraging people that invents standards to not use the NAPTR record. That is the first statement. The second one: Is it the case that the last slide of yours is is a question should we do ENUM version two without NAPTRs while we don't have any real dig deployment? Is that the question you are going to end this session with because I think that is an interesting thing to spend sometime and talk about.
SPEAKER: That is indeed but I would quite like if we got NAPTRs fixed because I think they are fixable. But that is ‑‑ I know the agenda is fairly empty at the moment but that is a long discussion and you know it's a long discussion.
AUDIENCE SPEAKER: Should we have the discussion?
LAWRENCE CONROY: Of course we should. But do you want to have it today? I would quite like to eat lunch.
AUDIENCE SPEAKER: If we are going to have it today maybe we should wait until after the dinner and see you all in the bar.
LAWRENCE CONROY: I think ‑‑ you know and I know it is going to take a lot longer than just a few beers to sort this one out. One of the reasons I think we don't have wide deployment is because it's taken so long to get the standards done (long to) and even then the standards are unreadable. But over a beer.
Again, if wasn't complex enough, there is the regular expression field versus the replacement field. This is in partial answer to your question about not using NAPTRs, I think the problem is not so much that as DDDS is over generalised and actually deals with URNs and URLs and the problem we have got in ENUM is that we have domain names that are in the reversed character direction from the application unique string. This means that in principle, you should be able to use the regular expression field to generate a domain name in practice, this is pretty much impossible. It is certainly infeasible. This is maybe the most contentious bit but in some ways the most difficult bit. If you happen to be in North America, you don't have a problem because I can generate a regular express and produce a tell foam number based in ENUM domain name from that, but if you try to deal with Austria and Germany and Switzerland where they have open number plans you don't it or at least it's extremely hard for you to do it. And actually, Germany, Austria and Switzerland do exist.
So, we give some guidance in the up date versions to say, well, you use the regular expression if you have got a non‑terminal NAPTR and you use the replace the field which, guess what, holds fully qualified domain name when you have got non‑terminal. You don't try and do both. I have had engineers claiming they can do it, writing a whole bunch of hideously complex provisioning stuff to try and produce regular expresses to do that, and for getting that Europe exists, to which the answer is no, that isn't good enough. In this particular case in the update it looks like we are probably going to ignore this or just say please don't try this because it won't work.
And that is my last slide. As Patrik said, NAPTRs are very, very flexible, but they are also (NAPTR) but they are lass challenge, should we update this, should we fix the specks (N) particularly 3401 through 3404, or should we just try and throw it away and start again. Questions.
NIALL O'REILLY: I am inviting questions.
AUDIENCE SPEAKER: Thank you, Peter Koch. I know you would rather wish you had Patrik here. I you have been picking on NAPTR for quite a while and there are operational reasons to do that and I am not questioning your motives here but one observation, maybe: The reason that this whole DDDS thing came into play was that someone found out when NAPTR ‑‑ and Patrik might correct me later ‑‑ the RFC for NAPTR was reissued, it was embedded into the whole DDDS scheme, right so, there is no ‑‑ there is no protocally correct way to just use, you can only Tuesday with K DDDS or A NAPTR and UNAPTR, what ‑‑ what seems to be missing and what seems to make the life harder for the programmers and implementers of these provisioning systems is that there is no generic DDDS library. If that would exist, things would likely be easier because it seems people are running into these bit stuff and implementing the gory details over and over again which is the same as if anyone would have to implement their own IP stack.
LAWRENCE CONROY: I did say that DDDS is over general. If you want add general DDDS library, it would probably be larger than would fit on a mobile phone. Probably be larger than all of the software that fits on a mobile phone. Also, there is this wonderful EU term subsidiarity, and in the case of DDDS, it is unclear which is the core bit and which is application‑specific, because understandably, DDDS tries to sort of leave the specification off to the individual DDDS applications. The problem is that in, things like non‑terminals, they are common, so ‑‑ they are. They are only specified in 3403 and 3404, in any detail at all. If you went through and generated a DDDS library, you would then need to sort of have some modifications to deal with the individual application you are going to do because in some ways they are overgeneral and in some cases the applications almost override what is possible in DDDS and certainly the case I was making in this slide, sorry in this slide, for generating fully qualified domain name, you really cannot do it realistically, OK. And the biggest problem, I think, is going to be the provisioning system. That is not so much just a basic library; the provisioning system is going to be a real pain in the neck whatever you do, in my opinion.
Patrik: I don't think it's possible to do a generic DDDS library either. I think that is a waste of time. What could be interesting and what I have seen are some sort of application‑specific things which are implemented for ENUM. But a more generic question regarding these various issues that you have found, specifically as they are either NAPTR or DDDS specific, both of those ‑‑ both DDDS and the cause of that NAPTR is used if RFID space and ONS. Have you been in contact with the ONS people and stuff to see whether your findings are similar to theirs, whether some of your suggestion are things that help them or maybe ‑‑ or is making life harder for them?
LAWRENCE CONROY: No, the short answer is no no because I have been focused often the pure telecom side of it.
Patrik: Is there anyone in the room that work with ONS?
LAWRENCE CONROY: Which is interesting in its own right, by the way. I think it's interesting that there is nobody who has actually been working on RFIDs and things like that, within this room, although you'd right, you are right ‑‑
AUDIENCE SPEAKER: It's an e‑mail ‑‑
LAWRENCE CONROY: I think ENUM will be the major user of NAPTRs and DDDS, you would kind of people that ‑‑ the fact that I don't think anyone has is slightly worrying.
JIM REID: Maybe all the RFID geeks that are here at the RIPE meeting in the EIX Working Group think about thousand get into the computer rooms with badges.
I think the question is that there is lot of useful information you have gathered for this but I think to my mind, maybe for this Working Group, the question might be is what can we use or capitalise on that? For example, maybe there could be attempts to try and produce some more test cases, even test bed. Patrik was on the back end on the provisioning side of things but also need things for clients and just as you were talking, I was thinking back of some of the tests we did, and we were able to sort of push the boundary as little bit and get clients to break various interesting and entertaining ways and I have this thought, if we use the regular express substitution fields we could results from the Napster procession turn 53 bites long and that could be entertaining to try something like that. And I wonder if there is anybody here interested in trying to put together some sort of test bed to try and do torcher testing on clients as well as torcher testing on back end provisioning systems?
LAWRENCE CONROY: I think that is an extremery good idea. When we did the plug test, we collected a lot of information about how clients fail. I will say no more than that about the plug test because that was all done under chat a.m. house rules. But both Jim and I, at the time, and I feel that even more so now, both of us think that it's a very good idea to have on‑line torture tests and a maintained set of evil NAPTRs to see what you can break. The buffer overflow one, I wasn't going to mention here live on the microphone, that was going to be an Easter beg if thank people could find if they bothered looking at the latest version of the standards and RSC 5483 because it's certainly mentioned there. It's about the first thing I did, actually. And yes, it did crash the mobile phone with ENUM client on it. But that is their fault for using fixed buffers. But it certainly is something that can happen. Don't always assume that these things are mistakes on the part of people. It's quite easy to misconfigure things in such a nasty way that they do break a lot of clients. I mean, if you could break an Acmi packet just by making do a phone number lookup, wouldn't that be fun? Because could you take out a very significant proportion of all of the next generation networks. Should we do have inter op testing? Yes we should. Should we have torture testing, yes, definitely.
NIALL O'REILLY: Thanks, Lawrence. (Applause)
That was an amazingly thorough, at times it seemed to be almost nostalgic lookback on things you have had to struggle with. Thanks, too, to the questioners who tried to keep you on track or divert you on to theirs, I am not sure which. So let's move onto the next ‑‑ let's see if I can find the agenda again. That wasn't the thing I was looking for but I will members it now. One of the the ongoing actives has been the ENUM data .org website and essentially we put their stuff that people responsible for tier 1s or people responsible for planning pilots in their country or in their international country codes or whatever will send us so the data that is there is only as good as what you send us in and I am happy to say it was updated earlier this morning because I got some data from the latest country to go live, who went live a few weeks back, about what, six weeks ago? Yes. So there are now nine country codes which have proclaimed live ENUM production ENUM in their number spaces. And the latest one of course is plus 44, which is the UK.
Now, if anybody else has activity that they want to (activity that) keep us informed of, send it to the e‑mail address on the slide and this site has kindly provided by Kim Davies who is a former chair of this Working Group and he has continued to host it, even though he has passed on the baton to cars sten and me.
AUDIENCE SPEAKER: Co‑chair of this question. It's not really a question, it's rather extension of the first plays, not only if you are responsible for tier 1 ENUM registry but also if you know somebody who is responsible of a tier 1 ENUM registry that would be absolutely helpful if that person could poke the other person to send us updates. If you look at the website coming up object the screen here. If you spot something wrong or not entirely correct please be in touch.
CHAIR: There is a standard list of questions and the responses are best sent in as plain text, please. And that done, let's move on to the RIPE NCC report, the tier 0 report from Anand and this should be the 11:54 one.
ANAND BUDDHEV: Yes. Good morning, everyone. I am Anand bud deaf DNS services manager at RIPE NCC and here to provide update about ENUM operations. (RIPE NCC).
So the RIPE NCC is the tier 0 ENUM registry. We manage the E164. Arp zone and we have done this since 2002. Operations are quite stable. It's not a particularly busy zone. The server that we operate here in the Netherlands receives about half a query a second. So it's not particularly busy.
Since November 2007, this zone has also been signed, so we accept secure delegations.
And what we aim to do is a review of the DNSSEC policies and procedures for this zone after RIPE 58.
Changes in delegations: There has been one new delegation since RIPE 57, and that is Taiwan, and this was delegated in 2008, November. So there are current total of 46 delegations. Two of these are signed and have delegation sign records and that is Poland and the Czech Republic.
The RIPE NCC has a project, a lameness measurement project, and we also monitor the ENUM zone in this project and I have got some numbers here to present.
We have discovered that 6 of the zones have at least one lame delegation and 3 have all lame delegations. And this is presented here in a pie chart. And finally, a little plug for the DNSMON service that my colleagues in the information services department run; they are now able to offer monitoring for ENUM zones, there is a special category for this and it costs 500 euros a year. And if you have questions about this, please contact our colleagues at DNSMON‑sales@ripe.net. And that is about it from me, brief update and I am happy to take questions.
AUDIENCE SPEAKER: Co‑chair of this Working Group. You used to have statistics on non‑delegated country codes. Is that still something you are running because that would sort of ‑‑ give us an indication what ‑‑ some demand would be for.
ANAND BUDDHEV: I remember that, we presented the statistic at RIPE 57, but it was more one of exercise rather than a continuous monitoring, so I don't have numbers for this meeting, but if it's something that people feel we should do on a continuous basis, you know we are happy to take that away as input and make it an action item.
AUDIENCE SPEAKER: Possibly, that came across with a question already. I am interested in that but obviously I cannot speak every participant here.
ANAND BUDDHEV: Perhaps I could have a show of hands if other people think this is useful and would like to see the statistic.
NIALL O'REILLY: I think the ‑‑ since the Working Group exists outside of the meeting on the mailing list, I think the action item in the first place should be with cars sten to try to gauge from the mailing list what the interest is, and if you ‑‑ if you want to go ahead in the background preparing for an anticipated result, of course we won't forbid you.
ANAND BUDDHEV: Great, thanks. Any other questions? In that case, thank you for listening.
(Applause)
NIALL O'REILLY: And that brings us to the last page of the agenda. There is item X which is the interaction with other Working Groups. There is nothing for to us do about policy proposal 2008 ‑ 05 because that is working its way through the Address Policy company and I think that one nearing completion (Working Group). We will be quite happy when it comes through because it means that ENUM operators at tier 1 will also qualify for accommodation in the Anycast, in the Address Policy which allows special allocations for Anycast.
And that brings us to any other business: Deneche Babuta would like to say something.
SPEAKER: Just a quick update about UK ENUM. Just in case people don't know, UK ENUM is run by the UK ENUM consortium and not for profit, governing body in the UK and with the blessing of the department for business, and we have given NomiNet a contract for the next five years to do the registry services. So since Dubai, there has been some changes, we have been keeping an eye on a new group that are looking at infrastructure ENUM with a view to having them come into the UK ENUM consortium fold. We also have a official secretariat that we appointed recently, political intelligence, they also like after ITSPA stuff and another thing we are doing before the AGM, which has to happen by the end of June and we are looking at memorandum and articles of association and tying them down quite strongly and that will go to a vote for the membership. And the AGM is going to be basically an open information day in the morning, for the public, and during the afternoon we will have the AGM with the voting and the new directors to be voted in. We also now have ‑‑ in Dubai we didn't' have any validation agents on the board and at the time NomiNet were looking at becoming a validation agent of last resort. Luckily by the end of the year we had a few applications, we now have two accredited validation agents and another two being processed. ENUM launched for registrations on 11 March and as far as I believe there is only one registration at the moment. And that is it. Any questions? No. Thank you.
(Applause)
CHAIR: One other item under any other business is your co‑chairs have been poked or one or two private e‑mails wondering if there is scope for talking about infrastructure ENUM in this Working Group, and if there is interest among the Working Group we are happy to see that line of discussion develop as well. I don't ask for anybody to ‑‑ I don't forbid anybody to stand up now but I don't expect it but if people want to throw some that have into the agenda for the next meeting, that would be fine. And if there is other ‑‑ any other business? Nobody is standing up, so it remains for me to thank all of you for coming but especially nationally and Marco. Nothing from Jabber, Marco? No. All is quiet. Natalie and Marco and all the meeting things for making things run smoothly and when all the things that didn't happen at first. Thank you and enjoy your lunch.