Real-Time Captioning
25 March 2003
Note: The following is the output of the real-time captioning taken during the ICANN Public Forum held 25 March 2003 in Rio de Janeiro, Brazil. Although it is largely accurate, in some cases it is incomplete or inaccurate due to inaudible passages or transcription errors. It is posted as an aid to understanding the proceedings at the session, but should not be treated as an authoritative record.
ICANN Public
Forum
Rio de Janeiro, Brazil
Tuesday, 25 March 2003
Morning Session
Contents
Stasney/Shockey Presentation (An IETF View of ENUM) (given by Richard Stasney)
Robert Shaw Presentation (ITU Perspective on ENUM)
Mark McFadden Presentation (ENUM in the United States)
Richard Stasney Presentation (Austrian and VISIONng Trial)
Address Supporting Organization Report
Proceedings begin shortly after 8:00 am.
Vinton Cerf:: Good morning, my name is Vinton Cerf. I'm Chair of the Board of ICANN. And I just wanted to let you know that we will be starting in about 2 minutes.
John Crain: Okay. Can the people on the telephone conference hear me? Linda, can you hear me?
Vinton Cerf: Good morning. I'd like to call the –
Linda Wilson: This is Linda.
John Crain: Okay. You're now live on the system. Vint, for your information, Lyman is also on the telephone conference.
Vinton Cerf: This is Vint Cerf. Good morning, everyone. I'd like to call the first public forum of ICANN in Rio here to order.
Vinton Cerf: We are going to start with a series of presentations, the beginning of which has to do with the ENUM standard developed by the IETF for the purpose of linking the public switched telephone network with the Internet.
I'd like to call on Board member Helmut Schink to introduce and to manage the presentations on ENUM. So Helmut, I turn the podium over to you.
Helmut Schink: Thank you, Vint. We will have a presentation on ENUM in the first two and a half hours of this public forum, and may I have my presentation on the – screen somewhere? How does this work? That's on the web. Is someone here to operate this? Or should I take my laptop to –
Or is it easier that I go to the speaker booth maybe? Oh, they're working on this.
In the meantime, let me tell you that approximately one year ago, we had a presentation on ENUM by Tony Holmes. And in the meantime, we observed that a lot of progress was made in terms of standardization, regulation, and especially in terms of implementation. And that would also be a focus of this meeting today. May I have the next slide, please.
So that does work. Next slide?
Okay. Thank you. So that's okay. So the agenda of the day will be that we will have an overview about what is going on in the various activities concerning standards and regulations, especially from the IETF, the ITU, and also from ETSI. We will have some overview about the forums and implementations from the us ENUM forum and from trials going on in the UK and in Austria.
Afterwards, we will have a brief demonstration to give you an indication about the ENUM and what kind of services ENUM can deliver to you, what kind of value ENUM can bring to the operators, to the ISPs, and to the end customers, because we have to understand that a technology is only worth a lot if value can be added to the system. I would like to add at this point in time that the (inaudible) will be continued in more detail during the entire day. There will be a setup in the hall just in front of the coffee place. So please have a look at this. If you are more interested in what is going on, what are the possibilities, what are the challenges, and want to have a better understanding about the real implementation issues.
We will also have a kind of an ad hoc wrap-up session this evening. Diane is still looking for an appropriate room. So we will announce the room at, say, the end of this session.
The purpose of this ad hoc meeting is to wrap up what are the comments at this public forum have been and also the feedback on the demos and we will give a short summary of the findings at the public forum tomorrow morning. I would also like to ask the experience to send me the presentations so the presentations will be posted on the web after the presentation.
The next slide, please. Just to make sure that we understand the rationale for this session, let's have a look to the mission of ICANN. The mission of ICANN is to coordinate, at the overall level, the global Internet system of unique identifiers and in particular to ensure the stable and secure operation of the Internet's unique identifier system. And since ENUM obviously uses the DNS, there is a reason for ICANN as an organization and for you as the businesses which are involved in ICANN, to understand what is going on.
Even understanding that the technical definitions, the policies are covered by other bodies. But we should at least be up-to-date with the situation and understand if there is any activity in ICANN required or everything is covered by the other bodies.
May I have the next slide, please.
And this is just a list of possible issues which might be of interest for ICANN. That is, of course, the enhanced load, since we have to understand that the number of domain names could significantly increase if ENUM is adopted on a wide basis or that might affect the stability. We have privacy issues to be covered, since, obviously, we have policy – privacy policy for the telephone numbering system and we have another privacy policy or privacy policies on the DNS, we have security issues. We have finally, also, financing issues, because ICANN is financed somehow, to a certain level, on a per domain basis and that could give us a broader basis for this aspect. We need to avoid conflicting implementations to make sure that we have an investment stability and I'm not quite sure whether there is a policy developed for global numbers, but I think we will go through this also in the presentation of the (inaudible).
Okay. That's all with my introduction. And I would like to start with Richard Stastny on the IETF situation. I would like to add that I am happy to entertain questions after the ENUM – after the presentation on the US ENUM forum, because that concludes, more or less, the presentations on, more or less, the theoretical side, before we go to the real implementations and demos and entertain another round of questions after the trial presentations and the demos.
Richard Stastny: Thank you. Good morning.
I am giving this presentation on behalf of Rich Shockey, who should have been giving this presentation. And we agreed last week in IETF in San Francisco said I will use the slides of a presentation which Geoff Huston has given. At exactly three weeks ago, there was a workshop of Australian Communications Authority, and it was lasting the whole day. And I presented there, Gary Richinecker presented there. He is chair of the (inaudible) forum and ITU study group two, question one, he is a representative there.
And Geoff Huston gave his view and the view of the Internet Architecture Board on ENUM.
So if you have any questions to the points stated here, you should direct them to Geoff directly. It's – not everything is exactly my opinion.
So we started, who is the IETF? I think I can skip this slide here, because I think ICANN is well aware of the IETF. Just shortly, IETF stands for the Internet Engineering Task Force. It has three meetings per year. The last one was in San Francisco last week. The next one will be in July in – I think one week before the next ICANN meeting in Vienna.
It's the organization that oversees the standard process for Internet protocols and technologies. It's an industry-based standards body with broad participation from vendors, operators, and researchers.
And IETF says we make standards that work. How you work them is up to you.
If somebody is interested more in the structure of IETF and what is the mission of the IETF, the best thing is to go to the IETF web page. So here is the principal organization. It's the Internet Society, Internet Engineering Task Force, the IAB, the IESG. And below the IESG are seven areas and working groups. And these working groups, one of them is the working group of ENUM.
IETF works a bit different than other standard bodies like ITU and ETSI. They have a statement, and this one – one thing I have a problem with, we believe in rough consensus in running code, but at the moment there's a discussion going on in IETF, some members have problems currently with the working of IETF and there's an on work group which has (inaudible) a problem, and you may look it up, they are doing a problem list now and trying to improve the work of the IETF.
But, generally, one can say the IETF, of course, is working well. But things are getting more and more complicated, so there also needs to be a reconsidering of how IETF works.
The general principle is – proposed work items launched in the BOF session, BOF means birds of a feather. Used to get interest and support of the community on this work.
If there is enough interest and support, a working program is chartered by the IESG and every group has a working group charter which may be looked up at the web site very easily. You have the work of chairs, and directors responsible for this work group. And, of course, the statement of activity and schedules of milestones.
And this, of course, charter is reworked if necessary.
The work done in IETF is done with Internet drafts. And there is two ways. One is individual submissions. And you see them as draft, dash, person, and then a name. Or work group documents, official – would say – most can be (inaudible) we will see, but working group documents denote some level of (inaudible) from the community of interest. And this draft IETF working group name. So if you see a working group draft of ENUM, it's starting with draft IETF, ENUM, and a title.
And official documents are RFCs. One has to know that not all RFCs have the same level of, let's say, standardization. This first informational and best current practice, and then standards, track the standards, the standards for IETF is going from BOF standard to draft standard and full standard for RFCs.
Regarding ENUM, one should consider that 2916, as it stands now, is a proposed standard. And it will be moved very soon from proposed standard to draft standard. So the new issue which is now running as an Internet draft, called RFC 2916b, version 5, will be draft – it is issued between now and Vienna, will be RFC, we will get a new RFC number, and will then be draft standard.
Here are some slides what you see on the IETF web page. If you look up ENUM.
So ENUM stands for telephone number mapping. Says – as explanations around for what ENUM means. Most people are using "e" for e 164 numbers. You have the chairs, Richard Shockey is one of them. And you have the description of the work group, the goals and milestones, Internet drafts, and RFCs.
So what is the reason for ENUM?
One reason is, there was a prerun of ENUM which was called tpc.int and it was used for mapping e-164 numbers to a records to emulate fax delivery. The problem was as it required new e.164 and IP address – one has to consider ENUM is a part of a broad IETF approach of splitting out the components of VOIP and PSTN interaction into discrete efforts and addressing each component as a discrete technology standardization effort. So it is not an end in itself, it has to be used with other classifications, with other (inaudible). What is – the good bits of ENUM. First, it's an e164.arpa. It's single mapping, and each mapping can be associated with a collection of URIs. The mapping may be statically configured or dynamically generated or both. And each end point of the DNS hierarchy populates the entry with the desired service entries.
Each application selects compatible service and – entries from the set.
So ENUM is independent of directory, call control, routing, and transport considerations. And it's just a mapping from e.164 domain to multiple URI service domains.
What is the not so good bits of ENUM? And, okay, another (inaudible) here in the room.
One problem of ENUM is, from DNS is the DNS at the moment is insecure.
So there is an idea that ENUM is only implemented with DNSSec. And (inaudible) one of the elements of DNSSec in ENUM and issue will not agree with this statement.
The problem with DNSSec is it's not ready at the moment.
What is this?
(sound in the background)
Richard Stastny: DNS is variably timed. It is generally not well maintained. It's not well synchronized. And there's one really problem is that DNS doesn't say no. It only gives you indistinct timeout.
ENUM is adding a very fascinating complication to DNS because ENUM really uses a regular expressions within the records. So this, in my opinion, far too much technical to go into detail here. But if somebody's interested in the real evaluation for expressions, you could contact me afterwards.
On the other hand, at the moment, we have nothing better in terms of a very large distributed database to go into this problem space.
And this was from Geoff Huston. He says DNS is a lousy kitchen sink. We have seen so many proposals, just put it in DNS. One should always be concerned if you hear this.
So this is also one reason of (inaudible) of DNS said a lot of people – of ENUM said a lot of people have concerns putting this application into the DNS and are very cautious. ENUM is not everything. It's not a directory, a search service, a transport service, a voice encoding method, a rendezvous protocol. It's just – it's for addresses as we will say in this terminology, to a set of service points identifying URI labeling.
So ENUM is mainly intended, of course, for Voice Over IP.
So most of the IETF work these days assumes a reference architecture. And ENUM's core architecture is Voice Over IP to Voice Over IP.
Gateway Voice Over IP model – okay.
– is very simple. A PSTN IP gateway maintains a mapping between IP and e.164 addresses. So you can go from a – from the PSTN here to a Voice Over IP gateway, and the Voice Over IP gateway is doing some mapping to the IP net.
So each gateway maps a set of phone numbers to a set of served IP addresses. Each gateway knows only about locally served devices. And gateway-to-gateway calls need to be explicitly configured in each gateway to use IP or some private connection, or use the default of the PSTN. So the PSTN is currently the glue that allows the Voice Over IP islands to be connected with each other. The idea of ENUM, this is the Voice Over IP islands. You have here this light blue sectors.
And the idea of ENUM is now to connect – this is a very rough architecture – to connect the gateways directly on IP. That's a core problem of ENUM. So the problem statement of ENUM from the working group at the beginning was it's getting more complicated now, but in principle, it was how to network elements, gateways, SIP servers, et cetera, find services on the Internet if you only have a telephone number, e 164 number. And the second problem statement was how can subscribers define the preferences for nominating particular services and servers to respond to incoming communication requests. The objective is to allow any IP address to establish whether an e-164 telephone address is reachable as an Internet-described service. And what the preferred service point actually is, with a pointing out of "preferred." We will see this later.
And if it's an Internet-reachable service, what IP address, protocol address, port address, and application address should be used to contact this preferred service point.
So what ENUM is, in principle, you have an e.164 address, use the DNS to get a set of URIs, send your select one URI and from this URI, again DNS, you get IP address, TCP/UDP port, and the protocol address. Since this is (inaudible) for first Internet also, to emulate this IP, IP services associated with a single e.164 number may be provided as a collection of different service points. And an ENUM request, a DNS request should return the entire set of service points and the associated services.
You will see in my presentation in more detail a bit what is returned, how these records look like. But first we have to define what is a URI. It represents a generic naming scheme to describe IP service points and generic format of the service, colon, service-specific-address. Everybody knows how you and I look like for example, mail to colon e-mail address is URI. HTTP is nearly a URI, usually called URL. A SIP address is usually a URI. SIP and something looking like an e-mail address. You have – we have tell URIs now. All of these are used in ENUM.
In the longer term, some years ago, everybody say we don't need their phone numbers anymore, it's now Internet addresses. But the Internet addressing scheme and URIs also have some drawbacks. Phone numbers are well-accepted, and, of course, they're easily to be used on devices which has only numeric keyboards. And everybody knows how complicated it is to enter something on a mobile phone which – with alphanumeric characters. And these URIs can be linked against an ENUM entry so it can be used for mail, web access, SMS and so on.
So what it's doing is, you have a phone number. You go with this phone number to ENUM and now you may get a SIP address, you or I looking like this, a main address. You may get a phone number, or you may even get it as a phone number.
And now it's up to the (inaudible) to map this – to see service wanted by the user. There's one important thing with IETF. And this is where the other bodies came into play. Issues where the IETF has an active interest. These points are who should manage the e164.arpa zone. It has been decided that this is RIPE at the moment.
Should there be one root for a single ENUM database or multiple databases for different functions, number ranges, area codes, or even numbers?
IETF has decided only e164 (inaudible) ENUM. You can (inaudible) make use of technology as domains or partial domains. But ENUM is only e164.arpa. How to secure the DNS to ensure that ENUM answers are valid, timely and authoritative. And this is where the DNSSec comes again into play. And this statement in the new draft said if DNSSec is finally out, said it should be used for ENUM. It's a bit complicated to formulate this.
What is even also important is, where the IETF has limited, if any, role to play in ENUM. And this is important because somebody else has to play this role. And this is at the moment, ITU and other standard bodies and national bodies. How to protect the privacy of ENUM database, how to verify the changes to the ENUM databases. Should telephone number holders opt in or opt out of the system?
Issues regarding portability and ownership of a phone number.
For example, which is discussed also, of course, in national (inaudible) about this from ITU and also from Tony Holmes, about these issues and, of course, compliance with legislative framework. And – as issues, which are also national (inaudible) in most cases. This ends my presentation. And is there any questions afterwards?
Helmut Schink: Thank you, Richard. I think we take the questions after the US ENUM forum presentation. So now the floor is open for the ITU presentation.
So that even happens to the ITU, then. It's locked up. (laughter)
Helmut Schink: So maybe we use the time if there is any question right now.
Vinton Cerf: Mr. Stastny, over here. Just an observation. The entry in the domain name system that supports the presence of the URI as opposed to an IP address is called an NAPTR, naming authority pointer.
There's nothing in that definition that would restrict the use of NAPTR's with other domain names than the ones that are in e164.arpa. So the only reason for bringing this up is to point out that we have the potential in the DNS with the introduction of this naming authority pointer idea to expand the functionality of literally any domain name to become possibly a lot more useful.
So I only bring this up because I don't think that the IETF restricted in its definitions the use. And that just means there's some interesting possible applications to look forward to.
Richard Stastny: This is correct. The new draft as stated you may use another, in other parts of the system. There's a lot of operators thinking of using this privately within their networks for IANA replacement and things also as private domains are thinking of using this.
What is open is houses private domains and public domains are interconnected, how they're interworking.
Vinton Cerf: An obvious application occurs when a company has its own internal communication system and has its own internal numbering plan. There's no reason why one wouldn't use this technique to incorporate an ENUM equivalent for a corporate application.
Helmut Schink: Richard, I have a question as well as you. You made some remarks about the quality of the DNS stability comparability with the kitchen sink. Did you ever contact the Security and Stability Committee here in ICANN?
Richard Stastny: I am not a DNS guy, so I wouldn't say this is a forum.
Robert Shaw: Murphy's law that whenever you're going to do a presentation your windows crash.
All right; okay. Good morning.
Richard, the reason why it crashed is you made such a thorough presentation on the IETF I felt compelled to start adding slides about what the ITU was doing so it crashed as I was adding slides so my presentation will be short.
Just to give an ITU perspective on ENUM, probably most of you know the ITU. I've worked there for over 20 years and I barely understand parts of the ITU, so I'll just be very, very brief overview.
Helmut Schink: We have real-time scribes, so if you can –
Robert Shaw: Slow down.
Basically, the ITU was established in 1865. It's an international intergovernmental organization, but it has private sector members too. We have 189 member states, 650 what we call private sector members or sector members, which are private companies and so on. These are the traditional telecommunications companies, but they're also a lot of it companies. The Ciscoes, the Moffetts, Intels, et cetera, et cetera.
It's the oldest specialized agency of the United Nations system. And of course that's our web site there where you can find hundreds of thousands of documents.
See if the pages turn here. Right. This is a very, very simple view of the ITU structure. There's more complex views, but this is a simple one and it's basically divided into three parts. The radio communication sector, which is actually the largest part. ITU, which manages radio frequency spectrum and coordination of geostationary satellite, things like that, global positioning systems, and this is an area very much dominated by governments.
On the right-hand side is the telecommunication development sector, that's sort of the newest sector of the ITU, the ITUD we call it. And they focus on providing technical policy radio assistance to developing countries. They do a lot of activities in IP networking, you know, running workshops and IPv6 or e-commerce strategies in developing countries. They establish centers of excellence and have straining projects, for example, in Voice Over IP in many developing countries. In partnership with companies like Cisco.
And in the middle part is probably the part, it's actually the smallest sector of the ITU but probably the most well-known, it's the xccut which is now called the ITU-T, the technical standardization sector, they do more policy-related standards that might be related to naming, numbering and addressing and tariffs, things like that.
So of course as you can imagine, support for Internet protocol related technologies is now a strategic element in design, standardization, deployment of telecom networks, and so this has had a very, very large impact on the ITU and its activities. So, for example, in the ITU-T there's probably 60 or 70% of its activities are related to IP networks and there's lots of, for example, delivering IP services over cable networks. We have something called IP cable com. So those standards are developed there about developing IP services, rearchitecturing cable networks for delivering broadband services, all the DSL standards, those are done here also, the B-DSL form has just become part of the ITU as a specialized fora.
A lot of Voice Over IP standards, work in access and transport networks, a lot of video encoding, decoding, codecs and voice codecs. You've probably heard of thing like MPEG 4 which will be used for streaming multimedia over the Internet. That's done by a joint video team which involves the study group 16 and folks from iso and other organizations.
So of course what's happening here, there's a general trend of integration, interoperability of IP-based networks and what we call the PSTN, Public Switch Telephone Network. And these are networks architectured in quite different ways. The voice network sets up virtual circuits that are – provide a guaranteed quality of service across the world to make a phone call, something like that, while the Internet is more of a best-effort network. And you want to deploy any type of device or real-time services over the Internet or what we call next generation networks, a lot of the work, standardization work going on is to make, let's say, IP carrier or IP dial tone, guaranteed quality of service, network management, making it much more robust for multimedia type applications.
So you need to do things managing end-to-end performance, and this is quite difficult in an environment like the Internet where it's made up of a lot of disparate networks that use different policies and protocols and so on.
So there's a lot of standardization work going on in this area.
So some of the issues of convergence. Well, we have the fundamental problem of how do you address – let's call the generic term, calls that pass from one network service to another. And now it's quite common to originate calls from IP-based networks to other networks. But it's very uncommon to terminate calls from other networks to IP address-based networks. And so you need some sort of a global addressing scheme across PSTN and IP networks.
Now, some – there's various possible approaches. One is you could assign e.164 resources to IP terminals. That's certainly possible. In some countries they're starting to take that approach. For example, with the rapid growth of broadband in Japan, something like Yahoo broadband where they're adding many subscribers every month and bundling Voice Over IP with those IP networks, this has called the policymakers, regulators in Japan and HTP to take a look at how to really make the PSTN and these new Voice Over IP services interoperate in a better way. And they've actually decided to allocate a prefix for IP terminals, Zero 50 so you can dial an IP terminal from a public phone let's say. But other people think something like ENUM might be a glue solution to tie these networks together.
So why is discussion of ENUM important? Well, of course because it's mapping telephone networks and telephone numbers into the Internet. It can allow a normal telephone to call a PC terminal, this device here. Of course, the obvious question is should telephone numbers used in this way be subject to government oversight and regulation as they are in the telephone, telephony world. And of course who should exercise control over telephone numbers that are used in this way.
There's a lot of ongoing work in this area, and it's a very complex topic. And so a certain caveat that what I'm talking about here is really much more focused at the e.164 infrastructure and policy issues, not ENUM services. And NAPTR services that Richard was discussing, and it's work in progress.
So what is the – that's not my phone. What is the e.164 numbering plan? Well, it's called e.164 because it's based on ITU-T recommendation. In the ITU, our standards are called recommendations to emphasize the non-binding status of those recommendations.
And it's very much tied to international treaty obligations which defines specific roles collectively for ITU member states for its 149 member states and for the director of the secretariat of the ITU-T which is called TSB, TSB director. And this e.164 numbering plan defines basically four principal categories of numbers.
The first is the one we're probably most familiar with, like Brazil plus 55. Or Switzerland 41, or the UK 44. So there's a correspondence with geographical regions, which typically has a one-to-one relationship with countries.
In some cases the number, the geographical number, is actually what we call part – it's an integrated numbering plan. So for example, the e.164 code plus one belongs to – mark, how many is it? 17, 18 countries, something like that. So United States, Canada, Caribbean countries and so on.
And I think there's a case in the ex-Soviet Union states where there's an integrated numbering plan.
In the case of another type of number is what we call global services. It's an international 800 number. We call it universal international free phone numbers or UIFN's, and this is sort of the international equivalent to a national free-phone number. Deployment has been difficult in this area.
Another type is what we call UPT or Universal Personal Telecommunications numbers. In fact, I believe some of my colleagues here are doing trials in this area with 878.
Networks, for example, global mobile systems. For example, some of the low earth orbit satellite systems that provide telephony, like global star or something like that, they obviously don't have an association with the geographical region, so they might have a separate prefix or same thing with NMAR SAT terminals, groups of terminals. And groups of countries, that's like the European Telephone Numbering System, ETNS, I forget what the acronym stands for exactly.
So some of the complexities in this space. Well, in the telecommunication numbering, of course there's a regulatory tradition with government involvement.
In the Internet, management, naming, addressing has traditionally been subject to self-regulation, quote, unquote. But of course there's increasing government interest in this area, especially when there's interoperability with the PSTN. And so national numbering, regulatory policy authorities are – will very likely be involved in coordinating ENUM servers and services, or be involved in the consultations for their portion of the e.164 numbering plan space.
So some of the national issues that might need to be considered, of course these are national matters, and how national authorities regard this can be very, very different in different countries. The integrity of their national numbering plan. You know, for example, certain numberings have certain connotations to the public, free phone numbers and so on.
Competition between service providers, security, things like number portability, which is a very part of pro-competitive liberalization policies. That includes things like carrier pre-selections, emergency services, privacy, control over personal records, slamming, changing your long distance operator without your consent and things like legal intercept.
So basically, it's pretty much of a no brainer, as they say, that most of these things are national issues. So most ENUM service and administrative decisions are completely national issues under the purview of it member states, and that's obvious because most of the e.164 resources are used nationally. As geographical codes.
So the role of the ITU is basically to ensure that the member state has specifically authorized inclusion of its geographic country code in the DNS. In other words, someone can't stand up and say please give me the country code for Spain, and it's not the Spanish government.
In an integrated numbering plan, of course, each member state within that integrated numbering plan may administer their portion as they see fit. In other words, Canada can administer its part of the resource one the way it sees fit. And same with the United States, and the same with Jamaica or who else is in that integrated numbering plan.
So what are our responsibilities? We are defining and implementing administrative procedures that coordinate these delegations into the agreed DNS name servers. And this is being defined by work, standardization work, and the lead study group that deals with numbering, naming and addressing issues in the ITU-T, ITU-T Study Group 2, and this draft recommendation is called e.a-ENUM. And they've agreed to interim procedures to let trials and national consultations and so on to move swiftly ahead, and those are defined at that URL there.
So some of the national consideration issues, and of course these are national issues so it's up to each regulator, policymaker, administration to decide, is perhaps to start or consider a consultation process with the parties who might be interested in this. And of course there's many national deployment issues which – for example, I think Mark McFadden will talk some about, being considered in the US. How do you authenticate the identity of subscribers for ENUM services? In other words, I can't say please direct this number over here unless this number belongs to me. Who are the registrars, how do they get selected, how do you validate NAPTR records, how is the data provision? Is it opt-in, opt-out, et cetera, et cetera. And there's a lot of competition policy issues here, obviously.
So governments have taken different approaches, and we actually have a web page that lists, has links to many of the national trials, consultations that have taken place and there's been some very good groundwork done by a lot of countries in this area. And it's always useful to learn from other's experiences.
So in the past what we've done is we've had some discussions with the IETF and with RIPE NCC on exactly who does what roles and responsibilities. Of course we're trying to bring a lot of countries up to speed on this, but particularly developing countries. So we've been asked to prepare tutorial materials and we've had at least two workshops in this area. We're producing something we call a supplement, which has a different status from a recommendation, on some of the issues that perhaps national authorities, administrations might need to consider. And there were some several SG, Study Group 2 meetings in 2001 and 2002 who are examining these issues. Issues, and of course they've also agreed on the interim administrative arrangements which I mentioned earlier.
What are we going to do in the future? We will continue to do some education, quote-unquote, outreach sort of activities, workshops. We're going to do a workshop in conjunction with the Asia-Pacific tele-community policy and regulatory forum which is Brunei in May. We're going to continue to have discussions, cooperate with the Internet Architecture Board and the IETF on what will be the final choice of the top level domain registry and some of the operations requirements that satisfy the discussions going on in Study Group 2.
The next study group meeting, Study Group 2 meeting, will be in may 2003, and they will work further on this recommendation. So there's some links to more information there. There's quite a lot of good tutorial material, and in fact we've worked with some very expert bodies, for example like companies, to examine the issues there.
Thank you.
Helmut Schink: Thank you, Bob, and the next presentation is by Mark McFadden on the USA ENUM forum. We'll take the questions after the presentation.
Mark McFadden: Okay.
Well, I hope you can see that from the back.
Helmut Schink: It's on our screens. It's only not on the wall. It's here, so the failure is somewhere in their system. It's not in yours.
It's not on the wall.
Amadeu Abril i Abril: We were just talking about the reliability of DNS.
Mark McFadden: The fact they're getting the signal....
John Crain: Can you try lowering your resolution?
Mark McFadden: Absolutely. Sorry about that.
All right. Thank you for your patience.
My name is Mark McFadden with the University of Wisconsin, in Milwaukee. Eliminated in the first round of the NCAA tournament.
I thought what I'd do is start this morning, instead of starting with my presentation, to instead tell you a story about one of my colleagues here who will remain nameless who was traveling through California just about a week ago, and he expressed some frustration. He actually discovered that his phone, which works perfectly almost everywhere else in the world, when he came to California, suddenly wouldn't work. And he sent us a very articulate and succinct and elegant message that was one line, and it said, "Here I am in the heart of Silicon Valley. I've got a phone, I've got a network, but you can't get in touch with me."
And I thought that story summed up the miracle of American networking. (laughter).
Mark McFadden: And that brings me to the American implementation of ENUM. (laughter).
Mark McFadden: And this is a story that starts sort of like that. It starts with a bit of a challenge, and then I hope to show you that in the last couple of months we've made some substantial progress.
One of the things to know is that in the United States, the operators, software developers, ISPs and people who are interested in ENUM have been working for a long time, but to be honest, and one of the themes of my talk today is that they are a little behind their colleagues in places like Japan and in Europe.
As long ago as December of 2000, the US government, through an agency called the NTIA, which is part of the Department of Commerce in the United States, actually held an informal meeting to bring together people who were stakeholders in both networking, network provision, the telecommunications industry, as well as the software industry to talk about ENUM and who would actually be the leader. Should it be government? Should it be the industry itself and so forth.
And out of that meeting in December of 2000 came a suggestion that a small ad hoc work group should be formed in the United States to actually provide some recommendations to the US Government on how ENUM should be implemented in the United States.
That group was convened in January 2001, and it met three times face to face, and it met, oh, about every three weeks via teleconference. It completed its work in May of 2001. And that was a report to the US Government which basically said, basically said, what we want to do is form a trade organization – not a trade organization but an industry organization that does sort of self-management of ENUM in the United States. We'd like to have a very, very light footprint for government. And instead, have sort of industry self-regulation in this space.
And what they proposed to do was actually form in the United States an organization, let's call it a consortium or a forum, that would actually do the work of solving the problems, some of the problems that Bob talked about in terms of responding to one of the problems implementing ENUM. And that group was called – that group was formed, then, in the summer of 2001, and that group was called the ENUM forum.
And what the ENUM forum is a group of interested participants from a wide swath of organizations. In fact, wider than what you might ordinarily expect.
The group includes the traditional culprits, the people who are network provisioners, ISPs, but also companies like registries and registrars and in intriguingly as well, companies that do software development.
Their work as well was to do work done in the ad hoc report and produce a roadmap, a blueprint for ENUM implementation in the United States. And the idea was to say who needs to do what.
What needs to be done in the United States to make ENUM work and who needs to do it?
Now, that ENUM forum, for those of you on the wireless or those of you using the blue tether, has a web site and has some of the documents that I am going to talk about, the documents that are out there are much greater detail than I'm going to be able to talk about today. Although I'll be happy to talk this evening when we get together at 5:30, here's the URL, www.enum-forum.org. This is the group in the United States that I was talking about. And it's their work that I am going to spend some time on this morning.
Bob did a good job of talking about the relationship between the work that's been going on in the IETF and the statements that have been made by the Internet Architecture Board and the ITU's responsibility. And he talked about study group's two interim recommendations and the ongoing work that the ITU is doing. So I'm not going to cover that in any detail except that the United States is taking its lead from that work, it's actually taking the recommendations that the ITU has made, which are at a layer that we'll see in a few minutes, an operational layer that controls how a numbering plan is actually delegated to a country or, in the case of the United States, country code one, a group of countries, and then how further implementations of ENUM actually take place.
One of the things to know and the reason I told that story at the beginning of my presentation, is that in the beginning in the United States, there was a substantial difference of opinion on how to implement ENUM. The words "substantial difference of opinion" is a euphemism for people knocking each other over the head. There was a substantial difference of opinion on how – there were people who proposed that there be competition at every layer in the ENUM hierarchy. That's a very, very difficult thing to pull off but something that was proposed. What the ENUM forum was charged with was, out of these widely divergent points of view about how to implement ENUM, to come up with a common point of view, and what you're going to hear me say later, a common architecture for ENUM provisioning and for how the services and information flows should take place.
In order to do this work, in the late summer and early fall of 2001, the ENUM forum broke up into task groups. It's a little bit like task forces. If you're used to the IETF, they would be working groups. In this organization, they were called task groups.
Here you see 6 out of the 7 created, there was architecture and infrastructure task group that was responsible for deciding how ENUM should actually be architected in the network and where the services ought to reside. Once that architecture was in place, you have to put the NAPTR records in, after all, so there was a work group that was responsible for deciding how in the United States provisioning should take place.
A smaller work group was set aside to talk about what kinds of applications would the users have, okay, taking from the point of view not from the provisioning of the network, not from the provisioning of the NAPTR records, but what are the users going to see from this.
A very, very important working group that – or task group that is continuing to do a lot of work in ENUM in the United States was the security and privacy task group. And I will actually talk a lot about them because a lot of work went on in the United States about the issues of security and privacy. Two other work groups that provided input were the interworking group and the legal group. Originally, the goal was for each of these task groups to go away, do their work and then share their work inside the ENUM forum. As time went on, about a year went by, as it turns out, as time went on, a little different strategy emerged. I'm going to talk about that strategy.
What the forum did was actually provide a work plan. That work plan, like all work plans that I'm familiar with, evolved over time. Or at least the dates did.
Originally, in August of 2001, the work plan established a set of deliverables for each one of the task groups. What changed over time was that not only did the deliverables change as the task groups got involved with the work, but the architecture group and the provisioning task groups tended to have most of the work. That's where a tremendous amount of the work went on at first. Now, in the discussions that we've heard so far, we haven't heard much about how implementation takes place. I am going to take a few minutes to talk about that.
One of the things that happened in the work groups in the United States was talk about how the delegation of the work for the ENUM zone files would take place. And the architecture task group talked about the tier 1 structure – and I'll talk about that in a moment, because that's an important thing to understand in order to understand how ENUM actually works in practice – and then also talked about how Tier 1 and Tier 2 registries would actually work, how they would talk to each other and what their operational requirements were.
Actually, putting the records out into the DNS was the work of the provisioning task group. And that work went on separately and parallel to the architecture task group.
There were other deliverables from other task groups. And rather than go through them, I'll just note here that the security and privacy task group did a tremendous amount of work on two major issues. First of all, the security of those records, both in the DNS and at the registry. Those are two separate but very, very important things. Also the issue of consumer privacy. And now I am going to simply point out to you that if we actually put records that have personal information, for instance, how to call Mark McFadden if he's not answering his phone, how to get in touch with Mark McFadden if he's not answering the phone, how to send mail to Mark McFadden if he's not answering his phone, issues like that, if we're putting that in the DNS, then anyone can do a DNS query and find that information. If anyone can do a DNS query and find that information, what's to protect the ENUM consumer from things like spam? What's to protect the ENUM consumer from unwanted telemarketing and so forth? Those kinds of consumer privacy issues were very, very important issues in the United States.
The applications task group wrote a paper on user application guide, which is actually at the ENUM forum at the URL that you can find.
The goal was to be done in the summer of 2002. And I'm happy to say that by the end of 2002, the ENUM forum was done with its initial draft of its work.
Each of the task groups met separately, and about every other month, the entire forum met together in a variety of places around the United States.
You can see the interim reports. They're available at the ENUM forum web site in a URL called "working docs.html." One of the things you will find there is the work of those task groups was iterative. It took place over a long period of time. And it's much like the IETF does its work, where you get a draft document, you submit that for comments, you take those comments, you build another draft document, and you move on.
One of the important things that happened at the end of last year was a decision was made to actually merge all of those draft documents into a single unified deliverable. And the idea was to have a single document, a single recommendation on how the United States should implement ENUM. And that unified deliverable is what I am going to finish up my talk on.
The unified deliverable actually identifies a series of roles, series of roles that people who participate in ENUM will play. And one of those roles is the role of a registrant. And, frankly, that's you and me. That's users, consumers of ENUM services.
Those people are responsible for electing to register their telephone number in ENUM. And let me be very clear about that. Take a look at that bullet. It says that the consumer is responsible for that decision.
The provisioning is not done by an anonymous telecommunications company, it's not done on your behalf by someone else without your knowledge. It's the registrant who's responsible for electing to register their number.
And they select – the second bullet that you see here, they select from a series of competitive registrars to accomplish that registration, much like we have competitive registrars in the DNS, so, too, in ENUM, it's envisioned in the United States that many people will be able to register people in the system and, in practice, what that will mean is not only do the database part, but build the zone files that contain the NAPTR records for the individuals that have contracted with those registrars.
Those people who are the consumers also will choose a Tier 2 provider. And I will talk about the tiers in a moment. But a Tier 2 provider that's actually hosting those NAPTR records.
The registrars are the people who are the first line in the United States, the people that the consumer sees, the agent of the consumer, if you will. They're taking the registration request from registrants and providing them services. For instance, one of the things that you heard that you can do with ENUM is establish a series of services that you want people to know about, establish preferences, and perhaps even, with regular expressions, perhaps do even more interesting things, like, say, if I'm not available at this SIP address, try me at this instant messaging address. And if I'm not there, do this. And actually give people not only preferences, but actual paths to contact people. A very, very important part of the security and privacy component in the United States will be at the registrar, the registrar will be a very, very important component in validating that the person or the agent has the authority to do that registration.
So for instance, if the had the number in the United States, area code [number deleted], and you registered that and you put NAPTR records in there, what the Tier 2 organization should do is make sure you have the authority, the permission to do that. And you wouldn't, because that's my phone number.
Also, it's very important to know that the Tier 2, the registry that is in contact with the consumer, is also the registry that works with the Tier 1 registry. The Tier 1 registry is going to be the one that actually does all of the pointers for all of the registries in the United States.
Now, the organization here in the last two presentations, there were a couple allusions to it, but let me make clear how this works.
At the very highest level in ENUM, we have to have someone putting DNS records into the system that will actually point to where the ENUM records reside. And the very highest level, as Bob indicated, is going to be what are commonly called country codes. Now, that's not their technical name, and there's much more going on than just simple country codes. But we have to have a place where we can find pointers to an individual country's Tier 1 registry. And we call that the tier zero registry.
Tier zero is nothing more than a fancy name for the DNS server or servers that have pointers to subsequent and I'm going to put this in quotes here, subsequent national Tier 1 registries.
Currently, the Tier 1 registry in the United States is envisioned as a single – a single environment that is contracted out, it's not a competitive environment. And this was a source of much discussion in the United States.
This looks like just a simple PowerPoint slide. But there were many hours of argument over the contents of this slide.
And the reason is, is because many people in the United States, being a sort of occasionally pro-competitive environment that it is, thought that at Tier 1, at the national level, there should be multiple competing Tier 1 registries. Other people thought that the synchronization problems, the security problems, and, for instance, practical operation problems that come with that were too great.
And so, finally, what emerged over a long period of time in discussion, in fact, this went on for quite a while, was that there would be a single Tier 1 registry in the United States, rather than multiple competitive ones, and that competition would be down a layer, at the layer where people actually interface with the ENUM system.
What the Tier 1 registry does is actually accept registrations from those Tier 2 registries, the ones that talk to us.
Also, the Tier 1 registry is responsible for arbitrating dispute resolution. We're so familiar with UDRP in this community, we know that there will be disputes that pop up in the ENUM environment. So what we have is a mechanism where Tier 1 registries actually arbitrate those disputes that come up. For instance, if I say that you didn't have permission to put a NAPTR record into the DNS on my behalf.
Finally, the Tier 2 registry is the interface with the end consumer, and it is also the source for when DNS – DNS queries are actually referred through the DNS system, it acts as the authoritative server for those NAPTR records. And that's the key job there. It's at these places where the DNS queries will finally be resolved and sent back to the client software or the client device.
Well, what's happened recently? I mentioned that a unified document was put together at the end of last year. That unified document then was sent around the forum and asked for comments. And I'm happy to say that the unified document, that draft unified document was actually published in February of this year, actually published in the second week of February.
This is quite a step in the United States, because although I made fun of network provisioning in the United States in the beginning, what this represents is quite a step for the United States.
It's a general agreement on how to do the architecture, provisioning, security, and privacy for ENUM in the United States.
The subtitle of the document is pretty humorous. It's the words "one step closer."
And those words are chosen – were chosen carefully, because they recognized the fact that the United States still does not have any significant ENUM trials under way, that the software designers in the United States have been waiting for this document to start doing work for – doing software design, either in embedded devices or software design for larger devices, larger client devices.
That one step closer also indicates that there's a significant relationship here between the ENUM forum, the US Government, and then, at the higher level, the ITU and the IAB. And that all of those relationships have to be worked through in order to actually bring ENUM into a production-class environment in the United States.
But what it does do – and if you're interested in it, I encourage you to read it, it's about a 130-page document that actually lays out all of the functional requirements for ENUM and all of the functional requirements for the organizations supporting ENUM in the United States. It identifies all the architecture, all the data flows, and all of the organizational capabilities that each one of those organizations, whether it's a tier 2 provider or a Tier 1 provider, have to have.
The major features here, I won't read through them, but the major features in the document is – there's a chapter on Tier 1 operational security and administration. There is a privacy – very, very lengthy privacy considerations statement. Privacy is an enormously complex issue in ENUM, requires an enormously complex solution, as it turns out.
The Tier 2 requirements and guidelines are also in the document.
Provisioning procedures are a separate section of the document.
And then authentication and verification, the fact that I am who I say I am, and I have permission to put this phone number into the DNS.
Finally, there's a small section near the end of the document on dispute resolution.
One of the things that I will say here is that the first tab that you see here, the first bullet that you see here, the Tier 1 operational security and administrative requirements, is one of the lengthiest parts of the document. And the reason for that from a practical point of view is because it's that document that is probably going to be turned into a purchasing document, like an RFP or something like that, to contract for those services on behalf of all Tier 2 ENUM providers in the United States.
One of the things that people here, especially operators in ICANN, will be interested in is that the Tier 1 registry is actually proposed to be an SRS registry. What this does is this – the proposal here is to support the thick registry model, where there's a lot of information that's actually stored. This also allows an unlimited number of registrars. The good news there is that this was the solution in the United States for solving the problem of competition, is that how do we make sure that there's competition in the provision of ENUM while we do it at the layer below, at Tier 2, and we let anyone be a competitor in that marketplace.
To actually communicate between the registry and all of the individual registrars, we're using the IETF standard for actually moving that data around, which is called EPP.
The unified document spends a lot of time on Tier 1. It actually talks about what the facilities of the database, for instance, it talks about things like data escrow for the database, what kinds of information has to be stored for the registrations, and so forth, how the generation and propagation of the zone files for ENUM takes place. All of those kinds of issues have actually been considered and specified in the document.
Touchy – That's the politically incorrect word – a significant issue here at ICANN that has been studied for more than a year is Whois. And an important issue with Whois, although not the only issue by any stretch of the imagination, but an important issue with Whois is the issue of privacy.
Privacy, of course, is an enormously difficult issue in the case of ENUM.
So what is being proposed in the United States is to not have a conventional Whois service in the same way that we're used to it in the traditional DNS. And instead what is being proposed is a much lighter-weight service that's been given the name "contact info."
What it is is, essentially, a third-party diagnostic service that allows registrars to talk to each – I'm sorry, registrars to talk to each other and find out information about who's put an (inaudible) NAPTR record in, what authority they have, and so forth. The idea here is to actually meet the needs of the providers while protecting the personal privacy of the registrants.
So the idea, again, is not to expose a lot of information about the registrants, but to provide enough information so that the people who are actually doing ENUM services can actually do the things that they need to do to make services work.
Down at the lower level, at Tier 2, we said, again, just for review that tier zero is the global level where the pointers are to the so-called national Tier 1 servers, and that the Tier 1 servers then point down to the servers that actually hold the NAPTR records. The Tier 2 specifications actually supply the mechanisms for building the NAPTR records out of the databases.
The mechanisms for actually building those zone files in the DNS.
And then actually checking – the third bullet here, what's going on here is to do some sanity checking, to make sure there aren't duplicate registrations, for instance.
Tier 2 is where the privacy and security issues get addressed, for the most part. The Tier 2 providers have to abide by privacy policies. They have to ensure consumer confidence in the ENUM system, because, after all, the consumers are going to come to this set of providers if there are privacy problems.
Helmut Schink: Mark, we are running a little bit out of time.
Mark McFadden: Let me just finish up here.
Provisioning is also specified in the document. And I think in the interest of time, I won't say much about it except that provisioning is a very, very – it seems like an easy problem, but actually putting the records into the database is harder than you might imagine. The provisioning section of the document is worth a look if you're interested in that.
I'll simply say that privacy considerations for any country that's considering doing an ENUM implementation are extremely important. And the group that worked on privacy and security worked very hard on this. And you can see the conclusions that we came to in the United States, that no telephone numbers would ever be registered without the consent of the owner. This – the rules very much look like the European data protection initiative. The registrants themselves choose exactly what information is out there. They always get to be able to see what information is out there. They have the ability to change what information is out there. And they have a choice in determining how that information is used.
Here are four key privacy issues that the United States ENUM forum actually identified. And what they did was try to address each of the four of them. There's a separate subchapter in the ENUM forum document on each of these four items.
Here they are. They're things that people who are interested in privacy know about, things like notice, choice, access, security information, quality and retention, relevance, timeliness.
Now, to finish up here, I talked about authorization, the fact that in a practical setting in ENUM, the person who's actually registering that either must be the person who has authority to register or is the agent of the person who has authority to do that.
And the proposal gives a bunch of scenarios, instead of actually providing an architecture, it says, in this situation, we want the Tier 2 providers to do this. In this situation, we want Tier 2 providers to do that.
Finally, the last two things to tell you, and, frankly, the good news here, is that at the end of February in 2003, the Department of Commerce in the United States said, "I think this is a good idea."
They sent a letter to the State Department, the United States thinks things are complicated by having three separate agencies – that's a lie, but three major federal agencies actually work with this. The Department of Commerce, of which NTIA is a part, the state department, because there's international treaties at stake here, and also the Federal Communications Commission. The Commerce Department sent a letter to state that basically said these three things. Go ahead and take advantage of e164.arpa, the current tier zero. The state department should work with the ITU to have the ITU complete its recommendations. You heard bob talk about that, the ITU is working on that right now.
And then take advantage of the set of principles that the ENUM forum has already done.
Those proposed principles you can see here. And as we said before, we'll make sure and post the presentation so you can go back and take a look at these.
But these are the principles that are in the letter that went from Commerce to the Department of State in the United States.
The letter actually said that before the official opt-in, because I don't know if Bob said this, but one of the things that happens is that a sovereign country actually has to say that they are opting into this system, they sort of raise a flag and say, "Okay, we're voluntarily going to take advantage of this."
And before the United States does that, these conditions need to get met. And if you'd like to see that letter, there's a URL at the bottom of the screen here that you can see that letter.
Finally, and this is my last slide, hold the applause, the ENUM forum itself is actually working on a response. So the forum itself is responding to the Department of Commerce, saying, "Here's where we are. Here are the things that we think need to be finished."
And the ENUM forum is also working on a series of other sort of complicated problems, for instance, I'll just raise one. The ENUM forum worked a lot on security and privacy. But there are a whole class of numbers, a whole class of telephone numbers that don't use the usual rules. In the United States, we call them toll-free numbers, for instance, numbers like 1-800 and then a phone number, or pay for service numbers like 1-900. And the ENUM forum is actually working on how ENUM should work with numbers that aren't geographically distributed in the north american numbering plan.
The FCC, one of the three agencies that I have talked about, has actually responded affirmatively. I put affirmatively in quotes, because if you take a look at their letter, which is available at www.fcc.gov, you will see that if you sort of read between the lines, the FCC wants to continue to play a role as well.
So, to sum up, what we have is a series of relationships, and what emerged in 2001 was, in the United States, an industry consortium that instead of having government impose a set of rules for ENUM and the implementation of ENUM, what the industry said, what we said, was, let's build the rules ourselves. And in the United States, the government said, "That's great. You go away and do it."
That work is done, or the first draft of that work is done and was finished in December.
Now government has said, "Okay, we think we're close. What are the last steps that need to be taken to sort of move us forward?"
That's where we are right now.
Now, one of the things you'll hear after questions is you'll hear about trials that are going on in other regions of the world. For instance, there are some great trials going on in the UK, some great trials going on in the Netherlands and Austria. I'm sorry I can't report much on that in the United States, because the ENUM forum has really been the precursor to that trial work.
But what everyone in the ENUM forum expects is those trials, like you're about to hear about, are going to start in the United States coming this summer.
Thanks.
Helmut Schink: So thank you, Mark. That was an interesting presentation.
Floor is open for some questions to the three presentations. If you have any, please feel free.
I have a question concerning the dispute resolution, Mark. You said you're creating a mechanism for dispute resolution. Is there lessons you learned from the UDRP process in ICANN? Any lessons you learned from this?
Mark McFadden: The answer to the second part of your question is yes. People working on the dispute resolution process are aware of the UDRP but the style will be different. Instead of having an independent body like the WIPO, the Tier 1 provider is going to provide the dispute resolution. So it's not really a disinterested party in the way it is in the UDRP.
Helmut Schink: Are there any other questions? From the Board, maybe? No?
I think, then, we continue with the presentation on the overview on the UK trial, then followed by the Austrian trial and by the demo. We have started a little bit late so I assume we have approximately one hour left.
Tony Holmes: Good morning, everybody. The good news is I'm not going to talk very much about ETSI and the structure, but a little more about ENUM.
You may wonder why ETSI is involved in this at all. We've heard from Richard about the role of the IETF and how the ITU fits into it. Within Europe, with the approach towards a single market, there are sometimes aspects that we need perhaps to do in a harmonized way, and that's where ETSI started working. They looked at a framework for the whole implementation of Europe, to provide a unified and coherent framework by which the administrations could work, that complied with the key goals that were set out from within Europe.
What it didn't do was dictate one way of implementing ENUM across all European countries.
If we tried to do that, well, we would have had an endless task. It would have taken years. But what we did do was set in place some key principles and sound management practices which everyone should comply with.
And this was really channeled through various European organizations whilst it was developed in ETSI, it was liased to other groups as we moved forward.
So the basic principles that everyone has to subscribe to, looking towards ENUM, the first of course is the integrity of the numbering space, the common numbering plans. Very much at the heart of a lot of the issues Bob raised earlier in the ITU.
We also realized we had to comply with all the European directives, particularly in terms of the data protection stuff and privacy, which again has been raised a number of times now in the other presentations.
And then strict adherence to the ITU recommendations and IETF specifications.
There are different ways of implementing ENUM outside of the RFC, but certainly as far as ENUM was going to be implemented on a common basis across Europe, then strict compliance with both of those recommendations and specs was a key point.
And then, of course, we all know we have to comply with our national regulatory requirements. And whatever we did, we had to ensure that we set up a competitive environment across all of the European countries.
The final point on this slide is the issue of opt-in. Certainly with the public provisioning of ENUM, any number that goes into the system has to be what we called opt-in. It has to be the choice of the person with the rights to that number to put it in the system. And then, of course, you have to form the right validation processes to ensure that that can happen.
As Mark said, there are a number of trials that are now being considered and advanced at varying speeds across Europe. I think it's probably fair to say that at the moment the UK and Austria are probably at the forefront of that.
But we realized that we could perhaps increase our understanding and shorten the learning curve on ENUM if we started to work together with some of the trials. So to do that, you have to accept that you need to do things in a common way to a certain degree, or otherwise you have huge problems of interfacing when you try to knit these things together.
So within ETSI, there was work on a technical specification that set out the minimum requirements for the interoperability. What did it cover? It covered things like common NAPTR formats. Vint has referred to these NAPTR records earlier. And we wanted to do it in a common way so we could minimize the interworking issues that came out of that.
What we set in place is purely for the trial. What happens after is an open issue. But I would suggest that if we get to the stage where the results of plugging these trials together is really positive, then probably some of this will roll through in the form of an ad hoc implementation guideline and format for the future.
ETSI is also starting to work on what is currently termed ENUM scenarios, and this includes infrastructure ENUM. It was the issue that was referred to earlier, the issue of perhaps using ENUM capabilities for rooting. There's lots of things you can do with ENUM and a lot is currently in the pub-like environment, but we realize we need to look at environments such as the rooting issues. The rooting of IP-based infrastructure where you look to provide Voice Over IP and other applications
With this, the key thing that comes through very quickly is the opt-in principle which I said was a key tenet of ENUM implementation changes. If you're going to use ENUM for rooting, you don't want to be in a position where the user decides whether they can put the number in or not. You need all the numbers in there. And if you're going to replace some of your basic routing functions within your network, it's absolutely essential that all the numbers are there.
So that means another set of issues comes to the fore, and they need to be tackled separately. Whether it's actually e164.arpa in the same way is an issue. What we're talking about is a classification of information that can be used to route networks that is possibly just integral to the network's concern. And obviously when they interface you have to exchange information and how you compile the actual DNS to do that is an open issue. So this has been taken forward as a separate piece of work. It will impact how ENUM is used in the private environment and set out a way of implementing ENUM very easily in a vpn type scenario.
So back to what's happened in the UK. Well, the starting point for this was a workshop that was sponsored by the DTI, Department of Trade and Industry, back in June of 2001. And they had sat in on some of the discussions in the various standards arena, and they wanted to test what the level of interest was in the UK. And what came out of that meeting was a feeling that it was pretty strong. And they suggested that industry formed a group to try to work through some of the issues to look at how ENUM could be implemented in the UK if ever we got to a stage where it was considered that there was a enough support to actually do that.
So we set up to try to scope out the work. The first thing is all we were going to talk about was the standards specification set out by the IETF, RFC 2916.
The goal was to look at the issues and to provide a report back to the DTI on what we should do, how we should do it and what were the outstanding issues that we'd need to tackle.
The preliminary report was set from the ENUM group to DTI in April 2002, and there's a link here from which you can see. And what was put forward was a proposal very much in keeping with some of the issues Mark raised earlier over the Tier 1 registry. There should be a single Tier 1 registry within the UK to handle the numbers behind the plus 44 country code. But to meet the competitive issues, we had to make sure we had a very open structure at the Tier 2 level.
The other point that came out of the report was that we would need to create some form of policy oversight committee to actually take some responsibility for some of the key issues such as privacy and to make some recommendations out of that.
We subscribed to the opt-in principle. Authentication is absolutely critical because if you're going to provide opt-in, then you have to do two things. "a," you have to substantiate that the person who wants their numbering is who they say they are, and, 2, that they have the rights to use that number anyway. So there's a key role in any ENUM implementation to make sure that that's resolved.
And the other two points I've already referred to here.
So this is a picture of the model that came out of that work. At the very top we currently have RIPE NCC who put the pointers into the dedicated country codes. The Tier 1 registry, and as I mentioned, it's a single Tier 1. Below that, we split the Tier 2 functions. On this particular slide it's shown as a registry function and a registrar function. And then we have the assignments entity on the side. It could be a telephony service provider, it could be the national regulatory authority, it could have been a third party. We haven't made any decisions on that at this stage. And then of course at the end of the chain, as there always is, is the end user.
Now, another way of depicting that is to try and look at the groupings that each entity could provide within the trial. You could link up the authentication agency with the registrar function. You could do what I've termed a registry function in the earlier slide, and on here it's shown as a DNS provider. And that's all it is, really; it's somebody doing some DNS hosting, holding the NAPTR records for each of the applications.
So for the trial itself, we suggested that it may be worthwhile trialing each of these scenarios to see what benefits you could get from combining some of these roles, but not prohibiting anybody coming into the trial who just wanted to do it in a singular manner.
The first trial seminar was in September of 2002. And we issued a trial pack. The trial pack said for each of these roles, these are all the things you'd be expected to do. And if you want to take part in the trial, come back with an expression of interest and sign this MOU. Well, that was an interesting experience. The group, the UK ENUM group be developed an interesting group, we had some legal advice. And when we got the expressions of interest back from people we gave them the MOU and said just take this away and get this signed. Which they did. And the first thing they got from their lawyers was what? Sign what? And then the next thing was, well, what sort of arrangements have you got between the players? How is this going to work? And everyone wanted to recreate the MOU that we'd actually drafted. But I'm pleased to say that through a lot of cooperation between the trial players that we eventually reached a stage where we had an MOU that everyone felt comfortable about. And it wasn't heavyweight. It was really just a set of guidelines to make sure everyone played in a fair way across the trial and that the information that was gained from that trial at each segment of the structure was shared equally among the trial participants.
And then the trial group finally met in 2002. We'd filled all the roles we set out. The expressions of interest had come back and we were able then to move forward.
But we had three applicants for a Tier 1 role. Interesting, when you only want to go down the path of providing one Tier 1.
So after some discussion, it was decided that all three applicants can share the role. And they agreed to that for the purpose of the trial.
For us, I think there were benefits in that because they will invariably do things in different ways and we can learn from the experience that each of them bring from the trial itself. It does lead to complications later, and I'll mention that as I go through.
So the trial group is set up as a separate group within the UK ENUM group itself. It's chaired by somebody who is at this meeting, Jim Reid. They develop their own terms of reference, and they're responsible for the detailed implementation of the trial, but obviously they liaise back to the parent group.
And they have to resolve the technical issues. Where they can't resolve things, then they'll come back to the parent group who will then look at some form of dispute resolution. We're also expecting to have a final report compiled by the trial group itself, which again will come back to the parent group for some additional work to be done on that before we report back once more to the DTI.
I don't intend to say very much about this. I think it speaks for itself. Just the outline terms of reference, I've mentioned what needed to be done so I'll just briefly move on and leave this within the trial pack itself.
But the objectives of the trial, maybe we should look a little bit closer. I've mentioned the need to evaluate the pros and cons of implementing ENUM and plus 44. To evaluate the processes. If we move to a commercial implementation, we do require a smooth set of processes, and the only way to make sure that you have that is to actually trial them. I think that that's a lesson we've learned within the ICANN process; that you frequently have to look at how you do things and try and improve it.
So out of the trial, we want to make sure we've got something slick and something workable as well.
And then there are other technical issues, looking at the DNS requirements, the implications for the provision of the services, the security and verification requirements, critical for any successful implementation.
An interesting point on here is certainly to evaluate and refine the economic benefits. I think that all the players have their own targets for that within the trial itself. And out of this work we'll then determine how we move forward, assuming that the support is there for commercial implementations. The lessons learned from this should help us along the way.
So just to run through a little bit more what each function is expecting out of the trial, for the Tier 1's, I've mentioned there were three. We've split them across the numbering range. There's a minimum set of requirements that each of those Tier 1 registries will be providing. And we have a two-phased approach. We look at how to map the numbers into the appropriate zones, to do the reversal of the number and to append it to e164.arpa. How we will run the name service, the validation processes. Simple low-cost interfaces for authentication and validation.
And then the phase 2 are the advance functions, and this is where the registries can differentiate a little bit, to look at how they do things differently. They won't all be required to do phase 2, but hopefully at least one of them will take on board all of the additional features that we want to get out of the trial. The support of IPv6 is something that some members of the trial group are quite keen on, and I think it would be of great benefit if we can look at some v6 applications across this work as well.
For the registrars, of course interaction with the registry itself is absolutely key. That's what you would expect to get out of this exercise, how you can interface, and what the benefits are perhaps of combining the DNS provision, the DNS hosting part with the authentication issue itself. And we have a couple of players in there looking at doing the authentication role.
DNS providers, placement of name servers, DNS software, compliance with the standards, configuration, all very generic standard stuff, but being trialed within the ENUM environment. There are some slightly different aspects here. So for those parties who hopefully move with us and move toward commercial implementation, this provides the capability of providing different ways of doing things so we're ready to go when we can press the button.
And again, back at the authentication agency issues. Authentication is key. I believe it's the most critical part of networking in the future. It's the key to so many things. But for the trial, we wanted something easy, slick, that we can just provide in a standard way.
What we've tried to do is to hook onto some of the existing processes. So for some parts of this, for the trial, we'll actually be using some of the capabilities where we check telephone numbers for number portability. We're using some of those standard processes. But as we move ahead with the trial, then we want to see how we can do things in a different way.
This is probably going to be quite a competitive area in the future. And there's a lot of lessons to be learned from this.
Whether there's a good business in providing digital certificates or how you actually want to configure this.
It's quite an exciting area of the whole thing.
And then the applications. This has been an interesting exercise. There are certainly people out there who have some innovation and are looking towards ENUM to facilitate that. It was mentioned earlier, that ENUM itself isn't about actually engineering something that's tangible. The benefits come from what it facilitates. The applications that it can run.
So when you come to a trial and it's a noncommercial trial who wants to play?
Well, a lot of people want to play but they want to keep their innovation for when they can move into the commercial environment.
So that was quite a challenge, filling that role in a way that has proved to be a benefit to all. But we have got some people there who are providing some different applications, and I'm quite hopeful that as the trial moves forward, then this area will be the focus of more attention and we'll get more out of this.
Where are we now? Work started in earnest the beginning of January. The infrastructure is now in place, and we've done the test look-ups. So the infrastructure is working and we've proved that.
The current focus is on the authentication issues, getting these processes right, enabling us to put in the numbers that we're using for the trial in an easy way. To facilitate the additional actions from the Tier 2's and the registry/registrar interfaces.
We've got a lot of work to do if we're to meet the timetable. We intend to finish the trial by mid-summer. But the fact that there are other European trials coming along, it slightly – as they're running a slightly slower time frame than us, that the UK trial will endure for a little longer. This is an open issue it's certainly something we're all very aware of and at some time we'll have to take a decision. And to the note at the bottom referred to the remark I made earlier that within ETSI some of the gaps in standards to facilitate interworking capability within the trials has now been closed.
So all this is going on in the UK trial group, but we haven't been able to rest in the main UK ENUM group either. There are some really difficult issues. The Tier 1 issue is the one that comes to the fore. How to choose who will be awarded the Tier 1 role when we get to a commercial phase?
Well, the first thing to say is it isn't limited to just the people who play in the trial. And we've been well aware that we needed to do some work in this area. I'll say a little bit more about that in a moment.
The other issues are the regulatory framework and of course the authentication agencies need to be accredited. How will we do that? What will be required? And I'm not going to dwell on the privacy issues. They're there. They've been spoken about a number of times. Huge issues. But within this group, we will look at them.
So choosing the Tier 1. We set up an ad hoc group to make proposals. The original thought was that we could just give some indication of criteria and say to our government "this is what we propose you evaluate them against. It's your decision to make the choice."
Life wasn't that easy. They decided that they wouldn't make the choice. And now it's back in the ENUM group, not only to set the criteria, not only to look at different ways you can achieve this, but also to make some recommendation, and at some stage, that group will have to make the choice. That group or a similar group. And it raises a number of issues, because you can't have just the players in the trial deciding amongst themselves who is going to get this one key role, not unless you want to start a war between them. So somehow we have to make sure the process is transparent, making sure it's equitable, making sure it stands up somehow. And a number of us have been keenly watching what's been going on with .eu and some of the issues that surround that.
Very related to what we're going to have to do for our choice of tier 1. The regulatory issues are also, I think, quite new. They have shared their initial thoughts and that's what these are currently, they are initial thoughts about the regulatory framework for ENUM.
The first point is that it should be running the commercial domain as much as possible and it's covered by a general set of conditions which have come out of the new eu regulatory framework for electronic communication services.
And they've looked at the tools they have now, they've looked at maybe the tools they would want for the future and concluded that there is no new ENUM-specific regulation being thought about in terms of the UK at this time.
The approach towards the communication bill anyway excludes domain names and Internet addresses. They don't have the control mechanisms to do this and they anticipate it will be a self-regulating environment. So how does the industry self-regulate itself? Well, it could be through a UKEG type body or some similar body, but it needs to be defined in some way that gives it some legal recognition. There has to be a way to make that body accountable for what it does so that it can actually make agreements and settle some of the disputes.
So how do you constitute the group? Well, this slide is the slide, it hasn't kept me awake at night so far but I'm sure it's going to at some stage in the future.
Because if you're involved in this exercise, the issue of providing some form of legal indemnity and meeting all the goals acceptable to a very broad community in terms of openness, transparency, accountability, I think a number of us have been down similar paths to this before. And the aim is to make proposals on the way forward by early summer. Again, it's a challenging thing to do within that time frame.
And out of those proposals, it's quite likely that our government would then go towards a public consultation to actually test what we're putting forward. So there's still a lot of ground to cover. I do think that the work that's been done so far and the spirit of the work has been excellent. It really has been an experience to work and to see so many players who look at this as an exciting thing for the future, working together in a way that's going to enable us to move down a path quickly, assuming that the support is there and the drive for the commercial implementation is there as well.
So that's all I have to say for my presentation. I'm happy to discuss any of this outside, but if you want to pick up on any issues looking at the slides after, please feel free to mail me. Thank you.
Helmut Schink: Okay. Thank you, Tony. Richard, now the floor is yours. We have approximately half an hour left, something like this. So I think that's feasible.
Richard Stastny: There's no (inaudible) in the network.
Helmut Schink: Could we have some support concerning the connectivity here. For the demo. Obviously, it doesn't work here.
Richard Stastny: The network is not....
The network –
So I will try to start, maybe I do the second one – we will see.
Yeah, I want to go from the theoretical side to the practical side and show you about (inaudible) and ENUM trials.
First I will make a short review on the status from IETF (inaudible) activities, say a bit about the ENUM background in Austria and our ENUM trial platform, what the scope of the trial is and the tasks of the trial partners and a bit about application and administrative aspects, the trials (inaudible), how we do application, and then our second trial we are doing with the UPT numbers, which is the global country code 878, and a bit about ENUM scenarios. And as the time is running out here, I will say that the major demonstration will be (inaudible).
So Tony Holmes already said in ETSI, we had first ENUM administration Europe, which is – it's a technical specification, 102051 which was the basic also for the Austria implementation. And, of course, we are also looking what UK is doing, what the ENUM forum is doing.
But then we saw with the trials coming up, of course, the trial within the country is nice, but DNS is a global system. So the prime idea is, you could work together.
And since there were no definitions at this time from the IETF, (inaudible) record should look at detail. We decided to make a basic set in the – in ETSI, which is now approved by the technical body just last week. And it's out now. It's a technical specification.
The plan is that we update this somehow in autumn 2003, depending on IETF changes and, of course, of trial feedback.
And so Tony also mentioned there – this ENUM network routing, which work will be continued in two weeks in Vienna. And just to mention the merger of the groups SPAN and Tiphon, and the first meeting will be in June in Budapest.
What is the status with IETF? In the first presentation, I gave you the major picture of the IETF, IETF with ENUM. But the work group is working in detail. I already said something, RFC 2916bis is almost finished and the technical specification is based on this draft.
As I said, there is no ENUM services defined. I will come later what I mean with ENUM services. In the NAPTR records.
And so we had the draft and now we have – because IETF is not a – to move this over to the IETF. And this – at the moment, there are five drafts out. And these drafts are compatible, all compatible with the ETSI technical specification.
And – with one exception. There's still a discussion going on we see draft using SIP. But there will be several contribution in summer.
Additional, the ETSI – ENUM is using the URI scheme, some additional URI schemes or additions to URI schemes necessary, and this is available in another work, and there will be drafts out. The next IETF, which is also in vienna in July 2003, several additional drafts, remaining drafts of the ETSI technical specifications will be moved to IETF.
Just a short overview, in European activities, from our point of view, as nearly everybody which is dealing with numbering in Europe has – some people say about ENUM. And, of course, there is involvement of RIPE. The views of the different bodies are, of course, different because it's depending on their background.
There's also, of course, a lot of national activities going on. And the procedure normally is, regularly is a consultation, then you have a workshop, then platforms are formed and trials are launched.
At the moment, platforms and trials are, as far as I know, in Austria, UK, Sweden, in Germany and France there's a closed trial, don't hear very much about it, the details. It says consultation workshops going on in the Netherlands, Switzerland, Portugal, Hungary, Romania, Poland.
There's one in RIPE, Germany, and Austria so far.
If anybody knows something additional, it would be interesting to hear about.
Of course, this is a lot of non-European activities. I told you before I was in the workshop in Australia three weeks ago. So in Australia, there is something going on. And as far as I know, there's also activities in Canada, Korea, in China, Taiwan, and I just heard also about Israel. At the moment, delegations, even – you have this list here. This is, as far as I know, the last time I looked was 15th of February, the official delegations which means there aren't activities, because some countries decide to have a delegation only if they have something in place. So, for example, France, request for delegation came in last week, for country code 33. So this is just (inaudible) cycling.
So what was the ENUM background in Austria? We really started our activities quite early. But this was internal work. It was in Telekom Austria and interested parties. The first consultation by the ustrian regulator was in 2001 in Telekom Austria also started an ENUM task force.
There was another workshop in February this year when a group of interested parties formed – the workshop really had the task to make an Austrian ENUM trial forum. But there was not enough interest. But some people were interested, so we had a – started with the regulator a smaller group.
In may, (inaudible) procedures were available. So we requested a delegation was sent by our regulator, RTR, to RIPE, and, of course, ITU.
In June, we had the registering operation, which one for the Austrian country code, (inaudible) which is the Austrian top-level domain. And the other one for (inaudible). We got most delegations, and at this time, also the development and deployment started for, as you will see, on one side the administrative stuff and on the other side the client stuff. We also had a first draft of a policy framework in July and in September, the Austrian ENUM platform was established, and agreed to framework, some of the trial participants have to sign MOU, which means trial could start officially. We see why. So see mission of the Austrian platform is to coordinate the activities between the Austrian ENUM trial – so now I have connectivity, obviously. It's a task force to development approve documents besides the regulatory framework, coordination between the trial partners, monitor the trial activities, of course, monitor the international ENUM standards and trial activities. And, of course, provide feedback, (inaudible) sites, and serve as a basis for the Austrian ENUM forum, which is required if we have a commercial application, because at the moment it's a noncommercial application.
And the members of the platform are at the moment our regulator, nic.at, Telekom Austria, Infonova, which is a provider for most kinds and provisioning systems, AOSA, which is a joint company between Siemens and Arcatel, Kapsch. And OFEG, my company, which is doing consulting. And Telcordia, which is also providing (inaudible).
The scope is, of course, the same, like in the UK. I will skip this.
It's just to provide infrastructure and have a web portal, ENUM (inaudible) software, have Voice Over IP software to be used in the trial, and other applications.
One thing is, our trials at the moment are more visibility (inaudible). It is not intended to go with what we have now to a customer in production. So there's a second step needed, which is not a trial, would be a pilot, to test the real – what you give to a customer. So there will be a step necessary in between.
So our – our purpose at the moment is also to find out first the product and then the markets.
I talked about the MOU. We have two circles, really. One is the inner circle, which has to sign the MOU, it's the Tier 1 registries and the registrar name server provider. And we have also a simplification here at the moment that we have registrar and Tier 2 name server providers one entity. So we wanted to have one interface less. But, of course, in a later stage of the trial, we will have to separate this also.
In the registrar, Tier 2 name server, have to get the MOU to the – which are issued by the rtr, the regulator. We have an outer circle, they just have to join the platform, just quite informally, they can participate in the meetings. Meeting protocols are available on the web site. It's public. And this is what we call the outer circle, kind of providers, provisioning software providers, application providers, and, of course, consultants and standard operations.
Just one – we have already heard of NAPTR records. And I have inserted this slide. What is really going on?
So what's happening in ENUM is you take a e164 number, create an entry in a explain, search for sources on the Internet, for example, with this phone number, which becomes an ENUM lookup to this domain. So what it is, it takes a phone number, turn it around, put dots in between, put e164.arpa, then you look up system name, and this lookup is for naming authority point resource records. And these records are looking like this.
And now I have to do some explanation here.
There's some important (inaudible) for ENUM. One is this field is order priority, preference. So there's a bit of discussion still on how this works. At the moment, we are using only preference. The order is always the same.
To really understand what's going on here in a complicated case, you have to read a DDDS, Dynamic Discovery System suite of RFCs, which is fun in itself, and like some people say, it's like theory of relativity. Only three people in the world who understand it. One is Mike (inaudible). I don't know who the other two are.
Anyway, what's happening here is you have a flag here which is "u." And that means this is the end of it. And it's all flag "u" at the moment. It could be frames and not ended. Nobody is using it at the moment. But should consider this way happen. So there may be a chain of NAPTR records.
In ENUM this is not used at the moment. But some applications will be coming up.
The next thing is, is the easy part. E2u means ENUM. It means e164, number 2, (inaudible) says a plus, and this is also from the RFC 2916, says change to the order, so E2U is the first one. So you have one or more ENUM services, and CCM services – it has e-mail and it has URI mail, too. This is SMS and it is using a Tel URI. This is voice and pointing to a H323 URI. Which is Voice Over URI.
ENUM is discussing at the moment really this part. Which is ENUM services. And the problem with this is, to use it in ENUM, you have to register with IANA, and to register with IANA, you have to have an RFC.
The next funny part is this here. And this is again what I mentioned before, it's a regular expression. You see it's always these four weird characters here, which it's meaning take the URI as it is, and this is again (inaudible) if this is the last one, there could be something more complicated in it. And what it could do really here is it could embed here a regular expression. One example would be to make some digit modifications from that number to this number, which is very interesting, for example, if you use ENUM with an area code split, you could have a pointing to another part of the tree.
And, of course, if there's much more complicated issues with this with real DDS application.
But this is really over my head also.
So what's really happening is, if you make a DNS query, you query for NAPTR, and say you get all of them. And now has to select from all the preference field and the ENUM services field what to do next. And this is described, really, for example, in 2916bis. It is described in the ur- – in the RFC, which is defining the NAPTRs, it's 3403, and it's defined in the (inaudible) specification.
So next is, how does our trial look like? I have seen the picture from the UK trial. It's quite similar. We have three tiers, which is – here is e164 as a delegation to our country and then we have the delegation from the number. So DNS is connected to the Internet. You have an ENUM subscriber, and this is the one – this is the (inaudible) ETSI document now. The ENUM subscriber is the one who is giving the data, and it is the NAPTR records. You have ENUM application, which may be a Voice Over IP application, e-mail service, what are, and you have an ENUM user, which is somebody else who is now querying DNS. And this could be anybody on the Internet, not even a trial participant. It could be anybody.
He's querying. And now establish a communication through the subscriber.
This is the easy part. This is DNS.
What we have now is, we have a hierarchy, we have here the ITU. On the other side, we have, for example, here NIC, and we have an ENUM service provider. And the ENUM service provider now provides a web portal. And it is acting in the role of a registrar.
So a subscriber wants to be a subscriber. First he sends in a registration. And now the ENUM registrar is doing a validation. If the validation is okay, he creates a zone, ENUM Tier 2, and sends a request for ENUM delegation to the Tier 1. And the Tier 1 puts the data in Whois.
(inaudible) we have already automatic this part completely. So tier 1 registry is just doing nothing. E-mail at the moment, structured e-mail going to ENUM Tier 1 registry. It checks for feasibility, if in allowed range, and then is doing the delegation.
So the major validation effort is with the registrar.
There is one point. Of course, now, the subscriber gets an e-mail with a password and user id password and can modify his NAPTR records (inaudible) portal.
This is defined within the policy framework of the regulator.
So how do we do with the validation?
There's three points which is important for validation.
First, ENUM subscriber shall be the assignee of an e164 number valid for the ENUM trial and the number shall be in operation with a TSP, as it is now.
It has to be verified that the ENUM subscriber is the named entity, and the registration shall cease if the first item is no longer valid.
Sounds simple, but it's very, very complicated.
We – of course, because it is so complicated, we choose an interim solution for the trial. We are using at the moment only known subscriber, so we are using subscribers known to us from other trials. Normally, the validation is the billing address. But since it's a trial, it's a hard thing to do. We are using only geographic and mobile numbers. And the numbers shall be listed in the phone directory. So the data need to be the same. If somebody is not in the phone directory which is public on the Internet in Austria, he cannot participate in the trial.
The validation is done by the registrars, and the use of personal numbers for use – for ENUM use only is under discussion at the moment.
The devalidation is done with a periodic check which will be automated.
But we have a validation group now in place which is coming up with new proposal, very interesting proposal, using certificates, using radio service and all this stuff. So there's a lot of things going on, because the major objective is also the validation need to be automatic. There should be no manual, because – just because of cost.
We have still an open issue. It's corporate ENUM subscribers. Because here's – here the validation is a bit more complicated, first to find out who's responsible in a company and things like this, responsible for signing, responsible for operations, things like this. So this will be done later.
Regarding the Whois, we have a Whois. We have all the data in the database. There is still a discussion which data will be stored. For the trial, we have decided to store all data, because it's easier to remove some afterwards and trial participants have no problem with privacy at the moment.
So what we are storing is, it's really – the only question is this data. It would be easy to remove this data, as you can see. I can show you lookup. And we have the – the registrar and so there's a name server provider only in the DNS.
As I said before, we have a second trial in operation which is with the VISIONng Association. That is to provide a framework for the deployment of work wide interdomain multivendor IP telephony services based primarily on ETSI TIPHON specifications. They are doing Voice Over IP work. And VISIONng is a forefront organization, association, implementing the specifications.
ITU has assigned part of the country code for – for deployment of the universal telecommunication service, this is 878-10. So the UPC code is 878, a country code. And we're using the number range 10.
VISIONng, as assignee of this numbering range has requested an ENUM delegation from RIPE. Got the approval from ITU-TSB. This is for trials only. So we are implementing in parallel to the Austrian ENUM trial. And it was also decided by VISIONng to use these numbers also for ENUM only. And this decision caused the joining of free will dialup, which is a – free world dialup. And show some of the scenarios. First we have this – it's very simple. You have two delegations, we have two different tier 1s, but, of course, telekom Austria is one of the registrars. And they use numbers of both registries.
I'm skipping this quite quickly. You will see this on the slides. It's – the only important thing is that we – in February, we have converted our complete trial to be compliant to the ETSI spec already.
So now ENUM scenarios. We have talked so much about administration and things like this. Of course, how does this work?
How does ENUM with national numbers work?
What you have now is you have a phone network, TDM, which is circuit-switching. And if you make a call to a number, it's going like this. You may have users on the Internet, and what you have here, because it's shorter, I put in here gatekeeper, but, of course, this may also be a SIP server. This is major protocol used on IP. So what's interesting here is with this – like an e-mail address.
So what it can do is it can establish a message – a communication using this id.
What – now, ENUM is queried by the user. You put in this number, queries the data for this number. You get this URI. And then, again, establish a communication.
And, of course, you could implement an ENUM gateway or so. And if you dialed by some means, like I did it in brackets, like two-stage dialing, you also can establish a communication like this.
The problem with this is this is a second-line service. So you have one phone here and you have a second pc, laptop, or whatever here.
How does this work with personal numbers?
Personal numbers first is used in VISIONng, you have numbers like this. 87810 and whatever. You have ENUM type capability at the moment. The problem we have here is that we had this in place before ENUM was standardized. So we did something else, which is not working quite in the same way. And we are converting it now to be standard ENUM. It's called Tiphon resolution capability. And you can make a call from one laptop to another on IP. But you can break out to the TDM network. You can register on any phone, because this is a UPT service, you register on any phone, and now the call is forwarded to the TDM. And because it's an even six four number, you can dial it on the – this number if you have a gateway here, and a router on this network, which is a problem.
So how is now personal numbers and ENUM working? It's working in the same way. You have an ENUM query for this number, and now for what it is forwarded to here.
Now, we still have to separate services. How do we combine this VISIONng,