These are unedited transcripts and may contain errors.
Notice: Use of undefined constant steno - assumed 'steno' in /var/www/html/ripe-60/steno-transcripts.php on line 24
ENUM SESSION, 7TH MAY, 2010, AT 9 A.M.:
NIALL O'REILLY: Everything is ready and most of the people have arrived. Good morning. My name is Niall O'Reilly. You have come to the ENUM Working Group session, so if that's not where you wanted to be, there isn't a parallel session, so there is no escape, and probably all of the couches are occupied.
So, my co?chair in this Working Group is Carsten Schiefner, who most of you will know. But there might be one or two new people in the room who haven't been here before. You have probably seen the agenda on the mailing list and on the meeting website, and that's not the agenda I am going to use, but there is nothing ?? there are one or two changes to the agenda and mainly this is re?ordering the items so that we have a more convenient flow to the meeting. I am going to start with administrative matters. I am still welcoming you, and that's item A1.
We have Natalie [Trainerman] is our scribe, who has nicely bowed, and somebody is looking ?? is monitoring the Jabber. It's Henk. Thanks. And I emphasise to all of you the microphone etiquette because it's very important. As you see we have some remote participants from Malaysia who have recently started their ENUM project there and they won't be able to hear you unless you approach the microphone. It's also important for the archive as usual.
So, if anybody has any proposals for changes, additional items in the agenda, they should speak now.
Nobody budges, nobody speaks, great.
We move to item B of the agenda which is to note the minutes of the previous Working Group session in Lisbon, and quite a long time ago now, I put it out on a mailing list that the draft was ready. And that Carsten or I would call a closing date comments on the draft and I got around to this a couple of days ago and the closing date is the 21st May at 12 UTC, so you have until then to make comments. Otherwise the minutes will be declared final. Does anybody wish to make a comment on them now? That's a good indicator. I hope the list will be equally quiet.
Item is C is to review the action list and there are no action items on the action list so there is nothing to do there.
I move back to item A and say a little bit more about the agenda because this is a good moment to ask Carsten to tell us about an agenda item which has been withdrawn.
CARSTEN SCHIEFNER: It is with great regret that I have to tell you that it's been decided that it would be premature at this very point in time to give an update a presentation about PH NUM, so I hope that I should be able to give you an update during the next ENUM Working Group session in Rome, but unfortunately I am not able to talk about PH NUM today, sorry.
CHAIR: We'll look forward to that in Rome then, Carsten. Thank you.
The way I want to take the remaining items of the agenda are to go immediately now to item F which is short news and then make way for item E, which is the tier zero report from Anand Buddhdev of the RIPE NCC and then go to the main presentations and then follow up with the tail of the meeting in the traditional way, that's to say discussion on Plenary presentations, which is empty because we didn't have any ENUM?related Plenary presentations, interaction with other Working Groups which we may discover during the course of the meeting, but I am not aware of any that have to be covered at this stage. And any other business and closing the meeting.
So, now, if I can move to the next, the first presentation, and I am going to keep talking because it's my own one.
It's a little longer than the traditional one that I usually give at the Working Group meetings, because, this time around, I am going to talk a bit more about where you can find the information that I use for the statistics, and give a little more detail than the very short presentation that usually fits this slot.
So, those are the sources ?? here is what I am going to cover: The sources of the information that I use for preparing this report; what activity has happened both in terms of new delegations and in terms of correspondence on the ENUM announce list and one or two statistics and then this will lead naturally into the presentation from Anand about operational matters at tier zero.
Here are the sources of the information. There are three sources, essentially, which you can all find if you want to verify that I am not spoofing when I tell you stuff. There is the RIPE ENUM Working Group maintained page hosted by Kim Davies at that website. There is the RIPE NCC's ENUM operational pages, or registry ?? registration services ENUM pages, where you can find general and procedural information about what they do about ENUM and you can find the request archive where all the correspondence relating to the requests for ENUM delegations is put and also on the ITUT website you can find other general and procedural information from that point of view.
What we have seen on the ENUM announce list since the Lisbon meeting is that the Swiss delegation has been withdrawn. The Ukrainian delegation has had some paperwork troubles and has finally been confirmed. This can happen if the request for an ENUM delegation goes to the ITU before all the preparations have been lined up properly, and, in that case, the ITUT has to refuse the delegation request because it's not properly prepared, and, happily, the colleagues from the Ukraine got their paperwork in order and it was confirmed subsequently.
Malaysia has been confirmed and we will be having a presentation from that team later in the meeting. Moldova is under objection at the moment, because I guess the wrong people applied for the delegation. And Lithuania has had a change of administrator and has actually gone into production. We'll see that in a moment.
This ?? the website which ?? the enumdata.org website depends on updates from the field, and if anybody is representing an ENUM operator or somebody who has authority for ENUM in their country and who hasn't sent me an update, then if what we are showing there doesn't match their current status, it's because they haven't given me that update and there is nothing ?? the ball is in their court, as we say, it's up to them to act.
So, we have had recently, in the last few days, we have had updates from Malaysia and Lithuania and a little earlier from Jordan and I'd like to thank the teams in those countries for letting me have that information and I have put in a place holder for the Ukraine, because once we have a delegation, we need to have a place holder on the website to make it function properly.
And here is the statistics from the enumdata.org website. And I have noted that the statistics may lag the reality, that's because we depend, Carsten and I, on getting the returns from the people who are actually responsible for ENUM in their countries. There are now 10 production delegations. Two countries are in a strange state, which we call a hiatus, which is what happens when they close their trial but decide to maintain the delegation without going into production. Six countries are in trial. I think one of them may even be in production, but they haven't told me yet, at least formally, so I can update it in this website. And 30 more are delegated. So there are 48 ENUM delegations in the zone and two countries are not delegated and those are the north American number code plus 1 and the Swiss code, both of those countries have had trials and they have decided to step back out of ENUM until they have a stronger demand from their constituency.
Here, the production countries, sorted in numerical order ?? well, one version of numerical order, the numbers are going up, and the latest one there is Lithuania, and here are the trial countries at the moment. And some of those trials are ?? one of these countries has explained to me that their trial is in a sleeping phase, which is an interesting state.
So finally, I am done with this now, and I want to say, please, if you are responsible for ENUM in your country, send me the updates so that I cannot be misrepresenting this situation. And special thanks to Kim Davies who has took the initiative to set up this website when he was my predecessor as one of the co?chairs of this Working Group and he still hosts the website. And I can pause for questions.
And if not questions, then we'll move onto the next presentation, which is from Anand Buddhdev from the RIPE NCC.
ANAND BUDDHDEV: Good morning everyone. I am Anand Buddhdev and I work for the RIPE NCC, and this morning I am going to give you a short update on ENUM operations.
Since the last RIPE meeting in Lisbon, there have been two new delegations, that was from Malaysia in February and Ukraine in April 2010. There is one other code that has been approved for Voxbone, but the delegation has not been done because it's still pending delegation checks. So, that's going to happen at some point, I guess, in the future.
There are four signed zones that we know about: Poland, the Czech Republic, the Netherlands and Lithuania. The Netherlands does not yet have a DS record in the zone and I am told that it's coming soon.
So we have this lameness measurement project going on where we query all these reverse servers to check for lameness, and this includes all the name servers for ENUM zones and here is a graph showing the lameness in the ENUM zone. 28 zones are completely okay, which means all their name servers are responding just fine. 17 are partially lame, and this means that some of their servers are responding okay and some are not. At the last RIPE meeting, this number was 7 and this time it's 17. So, I was a little bit concerned, and I discovered the reason for this and talked to the appropriate party, and, in the meantime, they have fixed it, but I couldn't update this chart quickly enough.
So hopefully, by the next meeting, that will have gone down again. And there are 3 zones that are completely lame, which means that none of their servers are responding at all. We do occasionally contact these operators and inform them about this DNS lameness, and sometimes they do fix it, sometimes they don't. But we do keep reminding them.
Something else that this group has been interested in, and we have been doing for a few meetings now is reporting on undelegated country codes queries; what we do is we capture PCAP traces on our server NS Pry, we use a tool called DNS Cap for this purpose which lets us specify relevant expressions and then we analyse the results using DNS top to figure out what the top NX domain queries are. At the moment, we find that the largest number of NX domain responses are for the country code for Portugal, followed by the USA, Belgium, Turkey and Spain. At the last RIPE meeting, Portugal was also dominating this list. And we find that the resolver which does most of these queries for the Portuguese country code is actually resolver at FCCN Portugal, so that's not too surprising. We had a presentation last year from the Portuguese ENUM people to say, to talk about their trials, and so, obviously, their resolver is very busy.
So here are the results presented in a graph. So the blue quarter on the top right is Portugal, the green one below that is for the USA and orange is Belgium, yellow is Turkey and next to that is Spain. I have also plotted two other interesting codes. That's 00, I guess people from Europe trying to call places and dialling 00, and 011 which is the international dialling code from the USA. So those also feature prominently.
Some upcoming improvements to your DNS infrastructure which also affects the ENUM zone. The ENUM zone has been signed since 2007 and we have been signing it using our old DNSSEC infrastructure. At the RIPE NCC, we are busy replacing this DNSSEC infrastructure with new signers, and so they will also start to sign the ENUM zone on the 14th of June this year. As you may have heard, the arpa zone is now signed, so we have plans to include the ENUM zones DS record in the arpa zone soon after we have switched to the new signers in June.
And lastly, we are busy replacing our DNS infrastructure as well. We are moving to a new DNS cluster with its own AS number which happens to be a 32?bit AS number, and we are also planning to Anycast our DNS infrastructure from a second site later this year, and we are moving to a multi?server architecture for redundancy.
And that's it from me. Any questions?
PETER KOCH: Good morning. Anand, could you go back to slide 6, please. That was the one with the pie chart. The big grey area to the left ? no pun ? that's roughly a third of these NX domain responses? Could you put this kind of into perspective; first of all, the DNX domain versus the referral responses not talking about absolute numbers maybe, so, how do they relate and what is hidden in this big grey area? Is there anything ?? let me put it another way: Do you see particular resolvers injecting significant amounts of garbage or is there strange stuff happening all over the place?
ANAND BUDDHDEV: The total of all the NX domain responses is about 20% of all the responses, so about one fifth are NX domain. This big grey area, which I have labelled at others, really consists of a wide variety of responses for all sorts of names, many of which are not even sort of valid ENUM?like names, as in they're not numeric labels we would expect to see. They contain text labels and lots of garbage. There isn't anything particular that stands out. I haven't looked at the sources to see if there is any particular dominant source for these, but I can look at that and report back on the list.
AUDIENCE SPEAKER: Thank you. Maybe for next time one could differentiate others in others that might still be country codes and others that's random garbage.
ANAND BUDDHDEV: Right. Okay, the others does contain some country codes but the numbers were very, very small so I have left them as others.
AUDIENCE SPEAKER: Sure, fine. Thank you.
CARSTEN SCHIEFNER: Not really a question, but rather a comment on the Voxbone delegation 8835100, and I have been briefing in touch with these guys and they just ?? they told me they just haven't had time to set it up yet but they will do so sometime soon, and might be ready for Rome, even with a presentation about what they are going to do and with that ?? well, country code and the sub?delegation, so I hope that we are going to have a chance to learn about it a little bit more in Rome.
CHAIR: Any further questions? Then I'll thank Anand on your behalf and we will move onto the next presentation.
(Applause)
Which will be from the colleagues in Malaysia by a remote magic called Skype.
SYARUL EMY ABU SAMAH: Hello.
CHAIR: If you wave at me when you want a next slide. We are showing the title slide at the moment.
SYARUL EMY ABU SAMAH: Okay. Thank you, Niall and Carsten. Let me introduce you to my colleague. Both is doing the ENUM from Malaysia, we are doing with our regulatory, and then on my left is [Nizar] and the other ??
NIALL O'REILLY: Excuse me, I'll interrupt you for a moment. We have to put the picture that shows the three of you up on the screen. We have your presentation up instead and then I'll ask ??
SYARUL EMY ABU SAMAH: On my left is this one, three of us is in touch with the ENUM from Malaysia and then we have ?? we work closely with our national form of communication and multi?media commissions. This is considered a project by us and obviously by our regulator, so we have a good relationship with them, and this is my colleague who is doing the front end of our ENUM, and, as for the back end, he is doing it.
So, sadly, we don't have our regulator with our presentation today, so let's proceed with the second slide.
We have seven agendas inside this slide, so, briefly, we will talk about our project and then our close test bed, actually Malaysia is also, we have ?? we already are in the phase 1 and phase 2. So after this, we are going for phase 2 and then we have a target participants for ENUM and some of the services that we are introducing in this and some are architecture and some update of the participants and the 7th agenda is the website.
The next slide. Our project objective is to accelerate between and facilitate between the PSTN and the IP networks by using the DNS that we are specialising in to store E164 number using the E164 number. And then we have roughly nine objectives inside our clusters. Basically, this objective is for to give the user of Malaysia, what is ENUM, to feel, to experience and then to come in and then to give their trustworthy in our services. So, let's go to the target participant.
Our target participant is telecommunications service companies. That is, we have two big companies who like to join us. There is DG and TM and we would like to have our IP telephone service provider certainly in phase 1. We don't have any participant from them. And we have Internet service provider, we have GITL, and then we have a ?? apart from our Government agency, that is our regulator and our ministry there is KPKK and then we have our from the university that we have half of our participants.
So this is the services that we are going to introduce to our closed test bed. We are going to introduce five only, so we have a breakup of the services into two phases. The first phase is ENUM to SIP and ENUM to e?mail. For the second phase, the rest of the service plus inclusive of the phase 1 services.
So you can see these are phases that we have ran, actually, we have just reran it so that people find is easier to understand.
The architecture: This is our general architecture of our ?? my ENUM closed test bed. So basically, this is our user and then we have our university, we have our own team and then other public user and then what we do is we ?? we would like the user to have other ?? so we can similarly do the ENUM queries.
SPEAKER: Actually, we have our own video IP structure in the ministry and we encourage another party to have their own video IP connector to us. That's the way we do the first phase of closed test bed.
SYARUL EMY ABU SAMAH: Okay. Next slide. This is the scenarios ?? we have two scenarios: The first scenario is before delegation and the second scenario is after delegation. The difference in these scenarios is, for the first scenario, we have, because its a server, so everyone who wants to do an ENUM call or ENUM query, they have to go to the recursive server and then the recursive server points to our DNS server. So if you can see the scenario 2, the next slide ?? the difference is that we use the route server to go to our ENUM DNS. That's the difference.
SPEAKER: Actually, before we get ?? we use our own legacy server to answer the 60.E164 arpa. That's the only way to answer the ENUM query for 6.0. After that, we have our delegation. Then we can demonstrate using ?? to answer 6.0 E164 for the arpa. That's the only difference.
SYARUL EMY ABU SAMAH: Okay. If you go to slide 18, this is ?? slide 19 ?? this is a proposal from us to our regulator for the MYENUM closed test bed phase 2. This architecture will only be in place if we can get the green light on our regulator because we need participants from the ISP, and the provider is the GM TM.
SPEAKER: For your information, DG and TM is our local telephone provider, our local main telephoning provider.
SYARUL EMY ABU SAMAH: Most of the customers, they have a big range of customers.
Slide 20 and then 21. For the fifth one, that is ended on 24th February, 2010, we have 80 participants. Below are the distribution of the participation. So you can see for the TSB we have an invitation of 38, but we can only get 16 participants. And for the IP telephone server provider, we don't have. And then we manage to send to the device vendor, then if you can see we have a very overwhelming participants from the university, we only managed to send 5 invitations, but the response is 19.
Next slide: This is some of the discretion for the phase 1. We were given a block of 10,000 numbers by our regulator, the numbers start from 01543 XXX X. And then our numbers, we can call to other ENUM numbers that is in trial or production, so we already tried it before. And there are some tools suggested that we mentioned to our participants, is the Wi?Fi phone or Smart Phone, SIP client and PC or phone. Then we already get our delegation from the RIPE NCC.
From our phase 1, some of the regulatory issues that we found are based on the discussion of meeting face?to?face with our participants and some outside. And then what we can summarise is two things that really taking care is the personal information and what is the pricing scheme for each ENUM services.
For our closed test bed, this is what we found on our ?? some of the recommendations that we need to go for ENUM trial etc., that we need a dedicated infrastructure. We need support from the Government agency. We need some natural body, we mean that who is going to have the ENUM dot base, who is going to hold all the personal data etc., and we would like to have ENUM countries that information on trial to work together to support each other.
This is what we found in our closed test bed for the phase 1, and therefore, this is the next slide shows you ?? slide 25 ?? shows you all the services that we are going to introduce. Please take note that the phase 2 is only start on July 2010. It's a three?month trial, but, for now, we are actually waiting for our regulator to give us green light to go for the phase 2.
Next slide 27: If you have time, we would like to invite you all to visit our website, that is www.enum.my. And for our phase 2, it's already there but we have to have something from our regulator before we can start.
Thank you.
CHAIR: Would you like to take some questions now?
AUDIENCE SPEAKER: Chair of the IETF Working Group. The slide when you showed some service quite in the beginning around 14, I thought: I see here ??
CHAIR: We are looking at slide 12.
AUDIENCE SPEAKER: If there is some mobile and service field, this is not a valid ENUM service. I recommend you to either use X dash service, use one of those that are registered at IANA, or, if you can't find register 1 on your own, but as it is, it won't go through, I can tell you, because it's already three levels, it only has two levels. Just a comment. So if you have that, it's kind of unfortunate because it's not standardised.
CHAIR: Perhaps it would be with helpful to the Malaysian colleagues if you dropped them an e?mail, Bernie.
BERNIE HOENEISEN: We can do that.
CHAIR: Now, the next up at the microphone is Carsten Schiefner.
CARSTEN SCHIEFNER: Hello, Carsten again. I have a question regarding your participants during your first phase. I was amazed by the number of telecommunications service providers; it was like in its 20s, 25 or something. And I just wonder whether ?? how should I phrase that, because you are working very closely with your regulator on ENUM, whether some really, say, convincing arguments have been presented to the telecommunications service providers to participate in the trial or whether it was fully and entirely voluntary? It's 16 only, but still it's an impressive figure, from my point of view.
SYARUL EMY ABU SAMAH: Thank you for your question. Actually, we have a full support from our regulator. What we did was the regulator, something like, we actually we are one part of their committee, that is called here see gone, grow of numbering which we are participating with them so we mingle with them and then we promote our services to them, so there is maybe the highest number of participation from them.
SPEAKER: We have meeting with them for every 13 weeks.
CARSTEN SCHIEFNER: Very good outcome. The other one is in terms of, say, additional, that it was, I guess, on the very first slide, about ENUM linking to multi?services. Can you maybe explain on the the notion of that term, like what kind of services would you have in mind, apart from those being named already, or is that basically ?? is that basically the amount of services you are going to link from ENUM for the time being?
SYARUL EMY ABU SAMAH: For the five services, do you mean? Is it the five services?
CARSTEN SCHIEFNER: There was a very early slide, I guess it was the second or so, where it read that ?? the second bullet point ?? slide 6, second bullet point, the capability of /*UPL providing one number with multi?services concept and I just wonder whether the multi?services is the five services you have listed or whether there is something more coming?
SYARUL EMY ABU SAMAH: Currently, this one is based on the closed test bed. It's the five services we are focusing on, only five services. What we'd like to do is to prove it. You can reach the person with one number, we are using one number to all his communications services as well.
CARSTEN SCHIEFNER: Okay. Thanks.
BERNIE HOENEISEN: This time I have a question. Did you already think about how you were doing the validation, like to ensure that only the whole of the phone number is inserted in on the domain?
SYARUL EMY ABU SAMAH: For the time being, not yet. Not decided.
BERNIE HOENEISEN: It just will strike you one day.
CHAIR: Are there any more questions? No, we have no more questions. So we are going to move onto the next presentation. Can you kill your mike, please. And the next presentation is from Bernie Hoeneisen, who has introduced himself.
Thank you very much. That was the applause to thank you. Bernie is coming to give his presentation. He has been putting a lot of energy recently into a second DDDS called E2MD which complements ENUM in some kind of way, and I'll let him explain that.
BERNIE HOENEISEN: Good morning. In the beginning, I have a question: Has it ever happened to you that you opened your laptop and the computer is booting and it was booting Windows? Well, nothing wrong with that, per se, but if you never installed Windows on that computer, then you are in trouble. Well, my computer decided, after security screening, that it travels anywhere else, he didn't want me to go to Prague. That's why I am here without computer.
Okay. So I am Bernie Hoeneisen, I am Chair of ENUM Working Group and I run my own company and doing their consultancy services for Internet standardisation technical consulting. Recently, I have been involved in an approach to complement ENUM by something else, which I am going to talk about now.
So I am talking about what is this new proposal E2MD. Then I will show you some use cases, talk about similarities and differences to ENUM. I will talk about results we had in the last IETF, we had a BoF there presenting the proposal. Come to the conclusions and then there will be a question and answer section and discussion.
So, may I ask you, whenever you have a question for clarification, so clarifying questions you can ask immediately, please ask clarifying question immediately, but if you want to contribute to the discussion, wait until the point questions and answers discussions. Thank you.
Okay. So what is E2MD? Who of you has heard before the RIPE of E2MD ? can you raise hands? Okay. That's about five. So it's worth on introducing what I am talking about more.
So, E162 mapping is something like ENUM, but something more, the use cases are about providing further information about the ?? so if it's so close to ENUM, why not to use ENUM? ENUM has limitations for usage of Meta?Data. The result, all this needs to be a URI and indicate the resource. And it is also seen that it should establish or at least be intended to establish a communications session.
So, this is the easy way to explain it, the evolution from ENUM to E2MD. We start with ENUM, just like bringing the old world that had only numbers for dialling or for colleagues on one and the new world that has also digits and electors, mixed like SIP addresses or so to bring them together, you can dial a number and you can reach an address that has some letters in it. So this is how it started with CNUM.
Then it evolved, peopled started to using prefix for recards for anything else than just for like pure mapping from phone number to VoIP services, and what we see here at right side is what I now introducing to you. It's kind of additional tools for ENUM.
So, I'll explain further these four basic use cases in the next slides. This is unused and [SENN], CNUM and the global service provider identifier.
Starting with unused: This is a service that indicates whether a number is allocated and whether or not the number is in use or, like, assigned to an end user at the service provider. This gives a hint to the one that's calling that you don't even need to go further, this number is not in use and just give it up. The E2MD you look up is faster than a SIP invite and with this property you can produce an announcement that says actually what's happening to this number, what's wrong with this number and why he doesn't get to the end. It has been documented as an ENUM service in the draft, which is outlined on the slide, and it was originally made for ENUM but it had a hard time there.
Send?in. This is a bit new thing. It's similar to the last one. It's basically saying when you are dialling, when you are in the middle of dialling, you get to know how long the number will be at the end. The VoIP telephone systems is the problem, they never know when the number is complete. The [send N] is basically helping with ENUM look?ups, how many more digits you have to dial before you have a complete number, before you have any chance of getting a complete number. So this is deployed in the leaf nodes. In this figure, you can see how it's supposed to work. Like, you dial the plus 44 and there is an entry that says send N4, which means you don't send until you have four more digits and this goes on until you reach the final leaf node.
Then another service that has been tried in ENUM is calling name. Like, how to explain it: If you have, in an ordinary telephoning system, you usually do not have name information associated with the number. This can also happen with a call is coming from SIP and going back to SIP. And in SIP clients, you usually want to show the name and not only the number and CNUM is a way of adding the name when the name is going from a plain calling system to a SIP?based number. This also has been tried in ENUM and is documented in an Internet draft.
This is a use case, global service provider. This has not been documented yet, but it has a lot of potential, this use case gives you an indication who is the service provider behind this number. This has some interesting usages. I can show you one. If I have a subscription at sunrise, I have a mobile subscription at sunrise and if I call to another mobile subscription at sunrise, the call is free of charge. However, if I call to Orange or Swiss Com, or anything else, I'll be charged loads of money, but I have no way of determining in advance whether or not my destination phone number if it is sunrise or not because of local number portability you have no way of determining by prefix and such a service could give an indication before you call, and before you get your bill loaded with calls that go outside of your provider.
It can also be used to optimise the routing and for many other potential use cases.
There have been more use cases proposed. I am not going into detail of this. Its service capabilities, payment type, network type, region code indicating a region within a country, or like the least cost routing information.
There are more potential use cases like charging information, how much is this premium rate number going to cost me? Or like, who is the assignee of a premium rate number. Emergency call routing could be one use case like location information or the public safety answering point for a fixed phone number.
So, what are the differences between ENUM and E2MD. They are basically three differences and they are shown in this slide. In ENUM, we have the E2U label. In E2M we have the E2M label. In ENUM the result must always be a URI. In E2MD, it can be a short ASCII string or a URI.
ENUM needs to indicate the recourse and establish a communication session. In E2MD, it just provides further information, the Meta?Data, to a full number.
Now, to the things that are common, that are shared among ENUM and E2MD. Basically, the standardisation approach has been proposed would be exactly the same in terms that there is a triple DS application and the field syntax and the process for registering these service.
A new service follows registration process. For ENUM, you have specification required, that implies expert review. For E2MD, we could do the same or something stronger, like standard section required.
And ENUM and E2MD share the same tree. So you make one query and you get back the ENUM services and the E2MD services.
Both use Nap direct calls and both have implications on privacy. So they need to be handled.
To summarise it, E2MD is so much like ENUM that we can reuse almost everything we know about ENUM from operational experience to standardisation stuff. It's pretty much the same, standardisation?wise, when the small differences I outlined before.
So we took the proposal and organised the IETF 77. We figured out, is there a need? The answer was yes, there is a market need. Net Head and [Bell Heads] expressed a need.
We figured out that the approach is feasible and easy to implement and the benefits are this approach are seen in all kinds of ENUM, primarily it's in infrastructure ENUM and in private ENUM instances. Then the question is the IETF the right place? Most people think yes, due to the close connections to ENUM. However, there was also some push?back coming at these BoF. Some were concerned that the scope is too large and the framework approach opens a direct hole that you can put anything you want to DNS. Some DNS purists claim that DNS may not be a good place for E2MD or NAPTR was already the wrong choice for ENUM, so don't even continue with this, there are multiple problems with with NAPTR, it was claimed. Well, in the practical deployments, we haven't seen or we haven't faced any real difference ?? sorry, we haven't faced any real difficulties with ENUM deployments, NAPTR, so we might as well choose this for E2MD, as well. I see Peter, he doesn't probably like what I am just saying. I just see you...
So, people are afraid that DNS ?? get too large. Yes, we might get large, but we already face the problem with DNSSEC nowadays. Some use cases are claimed not to be specific to phone numbers but to the DNS as a whole. This is debatable. Some claim that if you want to do this for private instances of ENUM, why are you here at the IETF? It's also something that could be debated but usually the cases have applicability in private and public instances. And the security in privacy is always a topic that comes and is thrown in such cases.
So, come to the conclusions: There is a wide support in favour of working for the E2MD problem, at least among the people who know what it is.
All the arguments that were coming in the E2MD BoF in Anaheim, they were known in advance, there was nothing new coming up.
What concerned me was that most of the arguments that made against E2MD equally apply to ENUM so I got the feeling that some people misused the BoF for E2MD to just express their discord with ENUM, they never wanted ENUM so let's shut down E2MD now. Not making the problem worse. I don't know, I just got that feeling. Some other people might have a different perception on this. And many arguments were about fear, uncertainty, doubt, and many arguments were beyond layer 9 in OSI protocol. For those who don't know it, the OSI protocol stack has 7 layers and we added it with a different layer; like, layer 8 is economic layer, layer 9 is political layer and layer 10 is religious layer. So we are on the political and religious layer in many arguments, which is not a good thing.
Due to all this push?back, we did not form a Working Group in the Anaheim IETF, but the Working Group is going on. There are mailing lists and conference calls going on and there is a bunch of people still working on that. We don't know what we are doing for Maastricht yet, but we know we will be doing something.
Okay. Now, we are coming to the question?and?answer section, and I invite you now to ask all the questions you would like to ask about and to contribute to the discussion. Thank you.
CARSTEN SCHIEFNER: Could you go back to the slide where it says about ?? ENUM and E2MD may share the same tree, for example, E164.arpa. That may ?? is that an IETF may in capital letters or because, or should it rather be should or must or is that just your wording?
BERNIE HOENEISEN: Well, it's certainly a 'may' in small letters. So it's basically an operational issue, a deployment issue, how we want to use it.
CARSTEN SCHIEFNER: Okay. Thanks.
AUDIENCE SPEAKER: Excuse me, in one of your slides you spoke about private ENUM. Can you explain again, please?
BERNIE HOENEISEN: Well, that goes into the two dimensions of ENUM. We have, on one side, we have private and public ENUM, and on the other side you have user end infrastructure ENUM. E164.arpa is public user ENUM, but many telecommunications providers do not want to get information to the public, so they are making a closed DNS deployment and put their ENUM entries that can only be read by trusted parties. And this is called private ENUM.
AUDIENCE SPEAKER: And also, I want you please explain about end?to?end scenarios about ENUM and almost today most of the providers have MPLS back 1, how is ENUM works in these networks.
BERNIE HOENEISEN: Now we are on different layers. MPLS is basically on the network layer or somewhere around this and ENUM is far away up in the layer. So ENUM works over IP and doesn't care about MPLS. So, I have difficulty to answer this question in that sense because they do not have anything to do with each other.
Of course, you can always contact me and specify your question further, or follow up in the coffee break.
BILL MANNING: I don't know that I would be considered a DNS purist ?? I am not a DNS purist or the DNS purists in the room would not consider me so, but I have some concerns about adding large objects into the DNS, for two reasons. One of the concerns raised was that you may have ?? if you are using NAPTRs or equivalents, you are going to have nested look?ups, and we talked about this actually at some length with the IPv6 deployment and got rid of certain DNS attributes to prevent long time to look up from one server to another server to actually get the responses back. So there is a latency in actually constructing something if you are going across multiple parties. The second is, is that the large DNS messages are problematic, because the DNS protocol hit for a very long time limited your response to 512 bytes and there is an awful lot of infrastructure out there that says any DNS thing over 512 probably isn't DNS; it's somebody trying to do bad things and will drop things. We have seen that with DNSSEC and we are seeing more of it. And so as the larger responses come in, how do you deal with the bigger DNS messages and the potential for extended look?ups before you get the answer back? Those are the two sort of DNS types of questions which I have never heard an answer for on the mailing list. I haven't participated in the calls, but they haven't answered on the mailing list.
BERNIE HOENEISEN: Okay. I start with your second question about the size of the answers. I personally, I do not think the answers should be large in E2MD look?ups. It should be something small. If it is large, it should be a URI which has more information. I know, however, that some people do not consider it a problem to have large answers in a DNS. In .tel they have used that and they didn't face any problems. In private instances of some tele costs they used it heavily, including caching, and they didn't figure out it is a problem as long as it's in the cloud. We need to figure out if there is a real problem, if that is in public using this large items. We don't know the answer yet.
BILL MANNING: What is large? Is 4K large? Is 9K large? You know, what's large?
BERNIE HOENEISEN: Well, in DNS, anything that is a K is probably large, but maybe Jim Reid can say something about that.
JIM REID: Just as a rule of thumb, a rough approximation at the moment is that it's roughly 60 bytes per NAPTR resource record, so if we are talking about this to E2MD depending on what actually data is going to be there, you could have many tens of them without getting to really concerns about packet fragmentation issues which would be around about the one?and?a?half key mark. TelNet experience was, I think, the worse case scenario we came across where someone had of the order of, I think it was, 25 or 30 NAPTR records given nodes inside a tel. domain name and that didn't cause any great problems at all, and they were using for that, just, essentially stock bind and, of course, for some of the stuff that the E2MD is being aimed that that would be the toll could he market where you are probably using much more sophisticated software than bind with database back ends and the rest of it where the issue of skies and data management would be easier contained than that he would be contained text?based zone files and configuration files. So I don't think that's too much of a concern. One of the potential issues for E2MD is just going what are the use cases and what kind of Meta?Data is expected to be returned, and, as you rightly pointed out, Bernie, that's still very unclear and because of that we still don't know yet if there are scaling issues around the size of the data that's either going to be managed or returned in the response.
BERNIE HOENEISEN: Thank you.
PETER KOCH: I actually tried to stay away from the mike, but since Bernie was confused by my ?? what you did you say? ?? non?verbal language anyway. I think, in this discussion, the counter?arguments have been represented in a, say, interesting way. We have heard the discussion about the sizes, and so on and so forth. I think the point that was missed a bit is that you were saying in the beginning that these proposals had a hard time in ENUM in the first place, and I would like to add that yes, for a reason. And some of these reasons may be addressed in a different DDDS application, but what appears to happen here is that those ?? and I appreciate, as the Chair of the Working Group now, you have a very thankless task of doing this whole stuff and we are not going to rehash all the history of ENUM because we all have our scars already. So these things were pushed back in the ENUM Working Group at that time, for example unused. Many people understood that there was a necessity for that, but this is not a service and it is trying to steer the look?up process that actually leads from the E164 number to something through that maybe in hindsight batch ?? record to some Meta?Data to /URI. So this is going a bit to the reasons why these were pushed back then. Same with [Send N], even more Send N is trying to steer at the ENUM level, so a level above DNS to steer and control the DNS lookup process that is lying underneath, which is an interesting thing going back and forth up and down the stack multiple times there, and these were the concerns that were expressed in ENUM, and, quite frankly, my personal opinion is that by relabelling something from E to U to E2MD, these concerns don't go away. It is just something that makes the architecture more complex. And if you consider architectural considerations and concerns as a layer 9 issue, then we just need to agree to disagree here.
BERNIE HOENEISEN: Thank you.
AUDIENCE SPEAKER: Fergal Cunningham. I have a question on Jabber from Richard [Posiess] of the Lithuanian tier 1 registry. He asks which use cases are seen as needed in public tree?
BERNIE HOENEISEN: Well, all use cases that have been proposed obviously have a certain need in different areas. I cannot really answer these questions generally, but at least the Telcos have expressed need for the service provider ID. Some people, many people have expressed the Send N to unused need, I can't give an answer in general to this, but I remember there was one question open from, what was it, it was about this co?located look?ups ? or what was that question? If you could rephrase that because I didn't get it. Bill? If you could rephrase the first question, if you want an answer to that, because I didn't get it. You said something, I just couldn't catch.
BILL MANNING: The first question had to do with the potential of, I guess, nested records, where you do a look?up and you get something ?? this is not the complete question, I have to go somewhere else for more data.
BERNIE HOENEISEN: So Send N, for example.
BILL: Right. Then it's go get the next record, and, oh, I have to go get the next record, and there was actually a thread on the mailing list called the 200 RRs of Bartholomew Kubbins: You take one off and there is another one and then there is another one and you can ?? at what point do you expect, practically or rationally, to be the depth of that lookup? Is it 20? 200? 2,000? 20,000? What's the reasonable number? What do you think that depth is going to be and can you justify that assumption?
BERNIE HOENEISEN: So, if I understood you correctly, you are asking how many dots there will be in the tree? Basically how long the entry could be or how many delegations in between or what was that?
AUDIENCE SPEAKER: Bill. . Not necessarily the number dots. That's a part of the Send N. It's when you actually do the evaluation inside the NAPTRs, there is something there that says I have to go look somewhere else. Because you don't necessarily know what's inside the NAPTR until after you get it.
BERNIE HOENEISEN: Okay. The Send N is deterministic, in a sense, unless you put the star there, but that's another issue. But it will be as long as and E164 number can be. It might be Send N entries that indicate don't even try the next few steps in between, just go to the next where you can find a useful result.
BILL: You are making a presumptive ?? you are making an assumption that a single look?up will give you a single valid result as opposed to I do a look?up, I get a result that does not terminate there, I have to go somewhere else to get the actual data.
BERNIE HOENEISEN: I now talk about non?terminal NAPTRs or NAPTRs that have this property?
BILL: Peter Koch is now stepping to the microphone to answer that question. Because you are answering it sitting there at the front table. I believe this is depending upon how you construct ?? you could say this would be a non?terminal NAPTR.
BERNIE HOENEISEN: Okay. I do not expect that is in two digits. I would say a few more steps will be performed. I have not seen any use cases that has more than five other look?ups.
AUDIENCE SPEAKER: Put it in the spec.
BERNIE HOENEISEN: Well, the spec needs to make that clear. The spec is not there yet, but it needs to make that clear. It needs to talk about DNS considerations and possible threats and things you shouldn't do. That's already there in ENUM and in E2MD it needs to be even stronger, if that answers your question.
CHAIR: I guess that means you have a lot of work to do before Maastrict.
BERNIE HOENEISEN: Yeah. In the slides there are some links for this work. Otherwise, if there are no more questions, I'd like to thank you.
CHAIR: And thank you, Bernie, thanks for coming along and thanks for taking this interesting series of questions. I'd like to thank the questioners as well.
(Applause)
CHAIR: And that brings us pretty well to the end of the meeting. There are a few Fastrack formal items to do before we release you for coffee.
We don't have the PH NUM presentation as Carsten already explained. We don't have discussion on Plenary because there wasn't anything in the Plenary. Are there any other Working Group group chairs that think there should be sub?items under X: Interaction with other Working Groups. Nobody is raising their hands. Would anybody like to add any other business to the agenda?
I see Denish Babuta approaching the microphone.
AUDIENCE SPEAKER: Just a general comment. I have to say that I really liked the Malaysian presentation, it showed some real thought having gone into releasing ENUM to that country. And thinking about the future of ENUM.
The thing that struck me and has struck me over the past few years has been that although within Europe, a lot of the countries are going into production with ENUM, there doesn't seem to be any concerted effort between the countries, because all the countries go yes, we are going into production but then there doesn't seem to be any further movement in that. The UK itself, even though I am speaking as an independent here, not as a director of U check, there hasn't really been any movement. The UK has been in production for two years and there is only real two numbers in the database in use, which doesn't seem to be very good. A lot of evident has gone into ENUM for no real results.
I am wondering also, if that's the same in the rest of the Europe, in the other European countries, and if that is the case, maybe one thing to do would be to, as the future of the ENUM Working Group is, maybe have a panel of people from the different ENUM countries within Europe and have an open and frank discussion about where we are going.
CHAIR: Would anybody like to react to those comments? Then I'll do it from here. I think you have proposed an item for the Rome meeting then, and Carsten and I will take that into account when we are putting together the agenda. Thank you very much.
Any other business then?
Then, we don't have any open action items, apart from preparing the agenda for the next meeting as I just mentioned, and I think I can thank you all. Thanks especially the stenographer, the Jabber monitor, the notetaker and the speakers, especially those who came by remote control from ?? to give the presentation on what's happening in Malaysia, and release you all for coffee.
Thank you all very much.
(Applause)
(Coffee break.)
LIVE CAPTIONING BY MARY McKEON RPR
DOYLE COURT REPORTERS LTD, DUBLIN, IRELAND.
WWW.DCR.IE