ICANN|ARCHIVES
Internet Corporation for Assigned Names and Numbers
Please note:
You are viewing archival ICANN material. Links and information may be outdated or incorrect. Visit ICANN's main website for current information.
ICANN Public Forum in Rio de Janeiro 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, and you will see it's quite easy, if you put in a gatekeeper or gateway in here, what you get is this operator is providing SIP addresses, for example, looking like this. And if you make an ENUM query now, you get this mapping to this, and it can establish a core from any terminal to this terminal.
Of course, that means UPT is the primary line service. You have this, end up to here.
So if you put all this together, you can now make call in all directions, and we are trying to show this in the demo. And you could also now disconnect this language with a dedicated line and use the Internet to go over here.
So this was very short now because my time is already running out. What we have here on the table.
Just one – web sites, I have corrected for different trials. There may be, of course, some additional ones.
I have, in my other presentation, just to mention this. We first wanted to show you a bit about the administration. Just to show you one starting point of it. This is our web site, which is ENUM NIC at.
The first thing you can do on the web site is find the presentations I just gave here, and you can see them on the ICANN web site, and you can do an ENUM lookup. The ENUM lookup is courtesy of (inaudible) research in the UK, and what it can do is you can enter, for example, the number I just showed you, 878, and is my UPT number, and you get some response.
So what you get – of course you don't get a NAPTR because it's not very user friendly, so you get the essential information. And what you see here is you can even use the e-mail is also recognized by the system as a URI. There's others which is not but this is just a work that we have to do. So you could even click immediately on the link and get to my web page. So this is my kids and my dogs and my wife.
Anyway. You could launch outlook here, and the idea is that you also, if you have a SIP address, I have no SIP guide stored – I have them stored but I'm not linking them to be displayed as a URI. We have another ENUM, I query now another number. I hope this is one working. Now it's coming. So you see here and also because you could click on links to start, for example, the web page. And of course e-mail addresses and so on.
So I want to show you another kind. How it makes the kinds. The user interface is not our problem. We have four companies doing clients at the moment. This one is from Siemens. This is from Info Nova. How the links can look different. I have another one from Accordia which doesn't display the URIs. It just displays make a voice calls and things like this.
If you want to play around with this, you can download all these kinds. The question is which numbers to query. So what we have – just I have to go back. You have here – no, no.
You have here all 12 participants listed. And you could also launch a Whois query and you can see now the data we have in Whois. It is standard Whois, and it's really this data which is the descriptor data which may be deleted if there's a privacy issue. The other data here is just pointing to the handles of the registrars and so on.
So this is private data which is under discussion.
Just the last table is – I hope it works. I use this messenger. I'm locked into a Voice Over IP provider. The handling is not very nice at the moment, but I will try to make a call. And I hope it works. Oh, I made a type of....
So we enter phone number. Hope it works now. The phone number is coming to (inaudible) to Telekom Austria. And opening a gateway and calling my mobile phone.
You hear? It's really a connection.
(tapping phone).
Richard Stastny: It's the echo. So there's of course a delay. But this is the idea how we think that it would work.
I also show you the outside – this is a packet Microsoft message. It doesn't recognize the connection is over.
What I will also show you outside is, of course I could also make it just a mobile connection to this one. Rudy has it now on his laptop. And you see we are just using normal. There are other different kinds.
This should be with the head set normally because the quality of my speakers is not quite okay.
And what I really do here, just stop this, I wanted to describe in more detail – okay. Maybe this slide.
Helmut Schink: Richard, we are unfortunately running out of time.
Richard Stastny: Just a second. Just to show you the scenario, what we set up is we have here SIP phones connected together with different numbers. One is the dialup from pulver which is the left side, and we make now just normal SIP calls. We have now put ENUM into it, and with ENUM, you can query ENUM from the laptop with the kinds I showed you. But, of course, and this is the important thing, also sip servers are capable of making ENUM. And SIP server is really running Iptel org server which can capable of making calls and can make calls in this direction. And the last part, what I showed you with the mobile phone, it was just going this way.
So it's coming from NIC, going to Telekom, and running this way.
Helmut Schink: Okay. Thank you, Richard, for the brevity and also the technical experience to work in this environment and make the trial really running.
We are, unfortunately, out of time, so if there are any urgent questions, I think we have a few minutes left.
Is this okay?
Vinton Cerf: Well, I'm very concerned. The coffee has been out there for a half an hour getting cold. At least I hope it's not getting cold.
A suggestion. Rather than having public open questions right now, why don't we call this session to a close, let people have coffee for 20 minutes, reconvening at about 11:15, and then – is that correct? Yeah, 11:15. And then during this period when we're having coffee, we can do informal questions for any of the people.
Yes?
Richard Stastny: (inaudible) the whole day except of course we have to have coffee or what. But we will be outside on the tables with the Internet connection the whole day for answering questions. So please get your numbers and queue up.
Vinton Cerf: Even better. All right.
Helmut Schink: I would also like to announce that the wrap-up session will be in the Lagoa Room on the "e" level. Time at 5:30.
Vinton Cerf: Thank you very much, Helmut, for organizing this and the presenters. Thank you very much for your presentation. This is exactly what we were hoping for.
So we take a break now till 11:15 and we reconvene for other reports.
(break)
Vinton Cerf: This is a two-minute warning. Two-minute warning. We'll be starting in two minutes.
Vinton Cerf: Well, despite my best efforts, hardly anyone seems to be interested in these reports. So I have a recommendation for the next time we schedule this. We will announce that they will be secret and private reports (laughter).
Vinton Cerf: – and that no one else is invited, and this will indoubtedly fill the room.
Let me officially restart the session. We're permuting the order of the reports a little bit to accommodate schedules, so I would like to call on Helmut Schink to make a report of the Audit Committee, and I would appreciate if we would try to keep those doors closed back there.
Okay, Helmut, it's all yours.
Helmut Schink: Okay, I will do this. I'm afraid people are still digesting the rooting tables for the UPT numbers via ENUM.
So the Audit Committee had a meeting yesterday at 3:00. Just to remind you the members are Mouhamet Diop, and Jun Murai and I have the honor to chair this committee. The meeting was accompanied by Stuart Lynn, Paul Twomey, Diane Schroeder. We essentially went through the four main items where the Audit Committee is responsible for.
The first thing is to recommend to the Board of Directors the selection of the ICANN external auditors. In the past three years, that was done by KPMG, and the Audit Committee felt quite comfortable with the service of this company.
And therefore, we ask the CFO to contact KPMG and ask them for an offer to do the auditing for the current fiscal year.
This will be done in – until April.
The next item, next action we decided is the completion of the audit of the last fiscal year. There is a conference call missing, and that is also done in April this year.
For the current fiscal year, we need to review the corporate – Corporation's annual financial statements, the unaudited financial statements of the first two quarters of the fiscal year, and that will be done by the Audit Committee in April as well.
The review and forwarding to the Board of the annual financial management letter, that is already done, so on this point there is no action needed.
The fourth element of the charter of the Audit Committee is to periodically review the Corporation's system of internal controls, including risk management and accompanying insurance coverage.
The Audit Committee felt, especially on the insurance coverage, improvements need to be made, but those improvements are not really urgent. So we agreed, also in agreement with the CEO and president and also with the new one, that that will be done until the end of this calendar year.
And that's everything I have to report from the Audit Committee.
Vinton Cerf: Thank you very much, Helmut. I have two questions for you. First of all, on the presumption that KPMG will perform the audit for fiscal year 2003, has the committee made any plans to interview other auditors for the following fiscal year?
Helmut Schink: For the following fiscal year we have to plan to ask other auditing companies to provide us with an offer. The acceptance of the KPMG offer for this fiscal year of course depends on the conditions of the offer. If these are acceptable, we will go with this company. We developed a policy to change the auditing company every three or four months, something like this, because that seems to be common sense in the noncommercial area. Three or four years.
Vinton Cerf: That's right. Stuart.
Stuart Lynn: Let me just comment on the selection of auditors. This would be a recommendation of the auditor to the Board as a whole and the Board will engage in the selection.
Vinton Cerf: Thank you for that clarification.
The second question I have for you, Helmut, has to do with insurance coverage. You mentioned improvement, and I wasn't sure whether that meant to reduce our cost or to increase the amount of insurance coverage or perhaps something else.
Could you elaborate?
Helmut Schink: The topic is that the rates have significantly increased; that the number of insurance companies who are covering this kind of company is obviously reduced due to the recent problems associated with terrorism and stuff like this.
So we will find a new company to cover the issues of property.
Vinton Cerf: One might speculate the less controversial we become the easier it would be to obtain coverage.
Thank you very much, Helmut. Any other questions? Questions from the floor on the audit?
Address Supporting Organization Report
Okay. We're going to go on, then, to the ASO report, which will be given by Mr. McFadden.
Mark McFadden: Thanks, Vint. Just a short update on the Address Council. This is only a little larger than an Address Council meeting.
The Address Council, just for review for people who are not used to – not used to the numbers part of ICANN, one of the things that is a structural part of the Internet, our Regional Internet Registries that do the allocations of IP addresses and other integers that are actually used to make the Internet work. The Internet, believe it or not, worked before the introduction of the domain name system.
The organizations that actually do those allocations are called Regional Internet Registries. The Address Council doesn't represent the RIRs. The RIRs are independent, freestanding organizations on their own. They're membership organizations. And for each one of the RIRs, there are three representatives. I'm one of the representatives from North America. There are three representatives here from Latin America. There's a couple representatives from other places.
The Address Council members do not have to be members of the RIR itself. It just turns out that right now all of them are.
And one of the things about the Address Council and the Address Supporting Organization is that anyone can participate in it. You don't have to do that through the RIR. There are other ways to do that.
The Address Council may change. This last bullet here is – sort of hides a dramatic change for the Address Council, and I'll talk about it in a moment. But the role of the Address Council may be changing dramatically as a part of the implementation of ICANN's reform.
And it's a bad thing, I think, to divide the world into old and new. I think that's a very bad thing. But here's the old Address Council. It was made up of representatives from three regions. The APNIC region which serves Asia-Pacific, what used to be the North America region, North American, Latin America and then the European region.
The representatives are there. I won't read them to you.
The Address Council also takes advantage of a secretariat, has a functioning secretariat. Those services are provided by one of the regional registries in rotation. In 2002, and we thank them for this, it was ARIN and right now in 2003 it's APNIC.
Very pleased to say that at your last meeting, you recognized LACNIC as an RIR, and immediately upon recognizing them in November they began participating in the Address Council. So the Address Council has grown from 12 official members to – I'm sorry, from 9 official members to 12 members.
The three new members you can see here. There are 12 total members. We still have observers as well on the address – non-voting observers on the Address Council. But Hartmut is on the organizing committee here and we give him a special note of thanks.
The Address Council has also been continuing to observe the process on establishing a fifth regional registry, one for the African region. The African region are observers on the AC calls, the Address Council calls, and they're routine participants in that work.
Let me tell you a little bit about of the substantive work that we do. Since you see so much activity go on with names and so little with numbers, you might be led to believe that things are just perking along perfectly in the addressing world. And in general, that's the good news.
One of the things that your Address Council has done recently is actually develop a standard Board of Directors selection process. One of the things the Address Council has done is actually work on an annual basis to actually go through that process. Now we've actually documented a standard way of doing that, along with notifications, the whole – the usual ICANN approach to providing public notice and getting public comment and having a feedback process.
We've also started working on establishing a similar standard process for nominating our representative to the Nominating Committee
Another important piece of work we continue to work on, seems like it's been going on far too long, is to redo the RFC which is for readdressing in the global Internet which describes the way addressing works and roles and relationships between the organizations involved in addressing. That goes on. There's a public mailing list for participation. There are participants all over the world actually working, doing the writing of those documents.
Another thing we're working on, this is a new initiative in January, is actually promoting better participation from a wider community. One of the things that we're doing internally as a group is working on electronic voting for the Address Council. That's a mechanism, because we have people from all over the world on the Address Council, not that this would ever happen to the Board but we have conference calls which by definition for someone would be in the middle of the night and for other people in the middle of the morning. That's an awful situation to have someone snoring on your conference calls. And so what we've done is we've actually arranged a mechanism by which we can start to work electronic voting into our bylaws.
We're also building a new track of workshops and information gathering sessions. We'll really start working on that in Montreal.
The Chair of the Address Council has actually drafted and is distributing a roadmap document for the Address Council. This is sort of a strategic plan for the year. That roadmap document is the subject of a conference call in the coming week, but that's something that the Address Council has not had in the future.
Also the Address Council held a workshop in Amsterdam in January where about, oh, three-fifths of the Address Council participated in a face-to-face meeting to try to deal with some of the key issues that were facing global addressing policy.
The Address Council is actually sort of in a funny place. It's actually in the middle in between the RIRs and the ICANN reform process. And one of the things you should know is that the RIRs and the ERC are working very hard at renegotiating a new MOU. Was that enough acronyms in one sentence there?
They're working on building a new MOU that reflects the new nature of the relationship between the RIRs and ICANN. That work is going on. I know that the RIRs and the ERC met yesterday.
In that meeting, the Address Council was not a part of that meeting. The Address Council stands ready to be a part of that work if it's called on by either of the parties. I'll let that be just like that.
And finally, one invitation. The Address Supporting Organization meets annually, but meets where the addressing community meets, and that's at the RIR meetings. And so our general assembly is right around the corner both geographically and on the calendar. The annual ASO meeting is on Thursday, April 24th, and it's going to be held at the same place as the LACNIC meeting in Santiago de Chile, and the agenda is currently out for public comment, but the agenda distributed as the draft is here. We're accepting additional proposals for agenda items and we have some in hand.
So the good news here to the Board is the Address Council continues to do its work. It's formalizing its own internal processes and trying to do a better job of reaching out to its community.
Vinton Cerf: Thank you very much, Mark.
Let's see. Let me find out if there are questions. Alex has one.
Alejandro Pisanty: Mark, has the Address Council discussed the role it should have in the discussions about how to structure the new ASO?
Sorry. I sense some unrest with your --
Mark McFadden: There is some. So that's absolutely accurate.
At the Amsterdam meeting – Amsterdam workshop, one of the items on our agenda was the – the future role of the Address Council in a – vis-a-vis a new MOU between the RIRs and ICANN. Inside the Address Council there is not consensus about what that role should be.
Also, there are strong pressures from the RIRs, who actually, from their members, elect the members of the Address Council, there's very strong feelings from the RIRs themselves. I would say that the Address Council has a variety of – a continuum of views, if you will allow me to say that.
There are some people on the Address Council who believe there should be a very activist role for the Address Council where it facilitates the development of global addressing policy, where it actually helps the RIRs build – helps the RIRs develop global policy and actually facilitates discussions of common issues across the RIRs. One of the things that we see when we work with the RIRs is that a discussion will happen in one region, and on the very same topic, a very different discussion will happen in another region.
That's partly cultural. But it's also partly different technical people, different engineering issues coming to play in different regions around the world.
On the other end of the continuum, to be honest, there are people who – in the Address Council who would be very comfortable if the Address Council's role was a fairly lightweight one in that it was there to support ICANN in the election of Board members and the election of Nominating Committee folks and performed whatever supporting roles, but to allow the RIRs to independently manage the development of both regional and global addressing policy.
The fair answer to your question is that there is, on the Address Council, this sort of range of views. There is no consensus.
Alejandro Pisanty: Thank you.
Vinton Cerf: Are there any other questions either from the Board or the floor for the ASO?
Mark McFadden: Thanks.
Vinton Cerf: Okay. Thank you very much, Mark.
At-Large Advisory Committee Report
Next up is Vittorio Bertola on the At-Large report, if he's here. There he is.
Vittorio Bertola: So thank you for the opportunity to report about the activities of the At-Large Advisory Committee.
My name is Vittorio Bertola, and I am the Chairman of the At-Large Advisory Committee. And we only exist since two months ago, so we are a very young committee. So we already have some things to report, but not too much. So I will mostly introduce how the committee is done and what it is expected to do in the next months.
First of all, currently the committee is at an interim state. So we presently have 10 members, two for each of the ICANN regions. Some of them are in the room. So I would invite them to stand up so that you can know the faces.
Because, actually, we want to work on a very regional basis. So I think people in each country should go to the person of their region and the committee members from their regions.
So can you just please stand up and maybe say your name.
Okay.
(inaudible)
Vittorio Bertola: Erick Iriarte from Peru and Wendy Seltzer from the US. Thomas Roessler, who is not here, but his face is quite well known.
We are waiting for members to be appointed, five more, so I think in a few months, we will be 15 members.
This is the fundamental design of the committee.
The mission that was given to us by the new bylaws was to give individual users a voice and a place in the policy-making process. So a way for them to be at the policy-making tables and to actually influence also from the early stages the policy-making process.
And so the whole point about this is quite different from the – the last attempt to build a sort of user representation, which was the global at-large thing of three years ago.
The point is not about representation, so it's not about involving millions of people who elect people, other people, representatives to the Board in other places. But the point is more like having a more limited number but active people that can actually do advocacy. So participate at all levels of the policy-making and make sure that they are heard there and they can provide new ideas, new opinions, and different points of view which, I think, are needed to make good policy.
So to do this, we are trying to rely on what's already there. So there are a number of organizations and active users who already want to participate.
And so our first step is to go and reach them and have them participate in the mechanism that I will describe.
And then, of course, we will try to bring more people in. I think that one of the targets of the committees there is also the possibility to bring new faces inside ICANN. And that's something we want to do.
But just to start, we want to allow the people who already are here and want to participate to actually participate.
So this is how we are involved in the policy-making process.
We have already appointed the five delegates to the Nominating Committee. And you can see their names on the slides. Some of them are also well-known in the ICANN community.
And we really thought of them as delegates, not representatives, because, as you can see, we have one person from – And then we will have a nonvoting liaison once the new Board is established. We have already sent non-voting liaisons to other parties. So we have Thomas as our liaison to the GNSO Council and we have liaisons to some of the task forces on the policy issues we are mostly interested in.
And this is the final structure of the At-Large Advisory Committee.
So there will still be five members appointed by the Nominating Committee. But the other 10 members will be chosen by what we call the Regional At-Large Organizations.
So these are meant to be sort of coordinating points in each region to allow for participation. I will come to them in the next slide.
Of course we also expect to have liaisons from the GAC or from any other bodies that could be of use. We think that our role is really to talk with all the constituencies and interact. So we would welcome liaisons from all the constituencies.
So the Regional At-Large Organizations – these are new. These are still to be formed. And these are one – I mean, on our agenda. And they are going to be the sort of – I mean, coordinating point between the At-Large Advisory Committee and the active users and organizations in each of the ICANN regions. So they will act as sort of coordinating point and instrument to reach people at the local level in local languages, possibly, and through the local cultures. These organizations will be formed in the next months and they will have to enter into an MOU with ICANN, which is one of the things we have to prepare and to recommend to the Board.
So at the bottom level of this structure, there are what we call the at-large structures, which, in fact, are existing Internet user organizations of any kind. So as long as they are predominantly focused on individuals, they're okay. They could be issue-based organize, they could be national organizations, they could be, for example, computer users or chapters of the Internet society or civil rights organizations, privacy organizations, whatever. As long as they represent individual Internet users and they want to participate actively in the process, they're welcome. Because we think that the more diverse we can be and the better ideas and suggestions we will produce.
But of course we will have to prepare some sort of accreditation process to be sure they are organizations of interest.
This is what we are trying to do as immediate steps. The first things are related to the structure that still has to be built. So we are working on proposing criteria for accreditation of the at-large structures and guidelines for the regional organizations to be formed and how they could self-sustain themselves and be financially independent.
And also we are trying to do some outreach to bring some organizations into the mechanism, of course, compatible with those that we have.
We are doing outreach, of course, with our at-large constituency, but we also want to get involved in the beginning in the policy-making process, because that's the final point of the whole thing. So we already, as I told, sending people to the task forces and trying to participate and to bring ideas in. So these are the issues. We have already started to discuss Whois and gTLD issues.
I have just started ENUM because from what I saw this morning, there's going to be lots of interesting problems for the final users about privacy and security. So for what – at least for what ICANN is concerned in ENUM, I think we should be there.
So I just close with the contacts, that we are having the web site which has just been created. And we will have a public comment forum I think in a few days.
And, of course, we have a contact e-mail. So feel free to get – go and pick us up in the – during the meetings and talk to us.
Thank you.
Vinton Cerf: Thank you very much, Vittorio.
Are there any questions? Yes, Ivan.
Ivan Moura Campos: I see that the constituencies you are announcing as supporting the activities of ALAC have an intersection with the noncommercial constituency. Do you consider this a synergy situation or do you foresee any kind of friction? Because on the issues like, for example, funding for activities and also on the agenda, I see an overlap – maybe I'm wrong, I just want a clarification if you see also this overlap in the agenda, and that may have consequences in the structuring of the at-large constituency.
Vittorio Bertola: Of course, I mean, we are – we have just been created, so we have – still have to understand which is our precise role, I think, and how to relate with these other constituencies and organizations. But, for example, I think these two entities are positioned quite differently on the ICANN map, because we are supposed to be an advisory committee to the Board and go across all the supporting organizations and the issues that are in ICANN, while the noncommercial constituencies, GNSO constituency, is just focused on names. Of course there will be overlap, because we will be participating in the GNSO policy making process. And, naturally, it's through that I'd say most of the issues that pertain to the users are in the GNSO.
And, of course, I mean, I think that resources have always been the biggest problem for the noncommercial participation in ICANN. So that might be a point.
But I think that – I mean, we may just simply find a way to live together. So I don't think that necessarily there will be an opposition between us and them.
Vinton Cerf: Thank you, Vittorio. Are there any questions from the floor?
There's one.
Would you kindly use the microphone at the front of the room. And please say who you are.
Vladimir Convalcante: (inaudible).
Good morning. My name is Vladimir Convalcante from Brazil.
And I'd like to understand a bit better the position of ALAC in terms of the number of people that can take part as members. Because as we (inaudible) produce discussion, five members is not a good number if we consider, for example, companies like Microsoft that use similar models of developers, like alpha and beta testers, people with specific competence to define and to appoint and to contribute to developing commercial products; right?
And I am seeing ALAC as a very similar place where people with this kind of merit can produce ideas to be included in the ICANN structure.
So I would insist in a point that is user Internet is not represented by ALAC right now. And I would also suggest that if ALAC doesn't have any power in terms of deliberation, we could consider the possibilities to have at least more members in ALAC just to start. For example, with countries that are – have a significant presence in Internet world. Okay?
Vittorio Bertola: Okay. And I see a number of issues here. So – well, let's start from the issue about the number of members in the committee. Of course, you have to have something which is a sort of final coordination – coordinating point at the ICANN level. And, of course, to have any working committee that can actually produce any output, you cannot have more than, say, 10, 15, 20 people. Twenty people are already a big number for a committee, I think.
So, inevitably, there's going to be a few people and so a few countries, a few cultures.
But the important point is not who gets into the committee. The important point is the network that you can build below the committee.
I see this as a very informal network of networks. So it's not going to be a strictly hierarchical structure where the top decides. It's just going to be a method to allow everyone who has an idea and something to say to actually come and bring it from the bottom to the top through the regional organizations and the committee.
So it's not really important about – I mean, having a representative of each single country, each single issue in the committee. It's important that the mechanism works. And, by the way, this also allows you to go to local communities, local Internet communities with local ways suiting the local culture, local language. Because you're going to have local groups who can organize activities and discuss. And then they can bring the issue up. Of course, for example, language is an issue. So, of course, I think that it will be very difficult to be able not to discuss, for example, in English at the very top level. But at least you can have discussion in local languages at the regional level and at the national or at-large structure level.
And about – well, about how much the – decisional power you have in ICANN. This has been a long discussion for years. So I'm not going to open it again. I just think that you will have to judge the results and you will have to judge ICANN by the – by the results themselves. So not by the method. But I think the only thing you can do is to see, for example, the new Board, how it behaves, and the new policy that gets created by ICANN. And I think that that will may be tell all of us if this mechanism works or not.
So, of course, having decisional power is important. But, more important is to be able to bring good ideas. And as long as they are actually listened to. So this is the important point.
Vinton Cerf: Thank you very much, Vittorio.
Are there any other questions?
In that case, let me encourage you again, thank you and your colleagues for your hard work. This is a huge undertaking. There are a potential 600 million users out there, and more, with some interest in the Internet, trying to provide a channel for their concerns to reach the Board is a serious undertaking. And your work is very much appreciated.
Vittorio Bertola: Thank you.
Root-Server System Advisory Committee Report
Vinton Cerf: Okay. So we now go on to the next report.
This is the Root Server Advisory Committee.
And Mr. Liman is going to give that report.
Lars-Johan Liman: There we go. My name is Lars-Johan Liman. I am – closer? Okay.
My name is Lars-Johan Liman. I am responsible for the operations of the I dot root server in stockholm. Since Jun Murai was unable to come here, he asked me to give the report.
So some issues that have been on our table since the last update by Jun Murai.
You have all probably heard the word anycast in the corridors and regarding root server. What is that? It's a way to put more root servers on the Internet without having to have more names and more data in the DNS zone files.
So – and anycast is something we want to put out there because we want to be able to better serve users in more places. As it used to be, there were only 13 copies, 13 instances of the root servers. Now we can do more.
And we – this will also mitigate the impact of denial of service attacks where we are bombarded by large number of packets and queries. This is also a local decision. A root server operator can decide on his own whether he wants to make more copies. Or her server on the network where this doesn't have to go through the large political slow, decision-making process, so we can actually quickly put this into place.
I'm going to do a 30-second demonstration how it works.
The Internet as a whole consists of a number of connected Internet service providers that talk to each other. And they form a kind of a network.
This is the old way, where the autonomous system, the source of the root name server was in one place. And it would send out information to the Internet that this is where the root server sits. It's reachable here. And all the traffic going to that server would listen – would – rather, the ISPs would listen to the information and transport the traffic towards that server.
What you can do with anycast is that you can have several, not only two, you can have tens of these identical copies, and they will each send out information that "I am reachable here." And that will make the traffic on the Internet try to reach the nearest server.
And by having many servers out there, we can give better service to – in more regions. And we also have an automatic backup system, because if one of these servers falls down or crashes, it will stop transmitting the information that is reachable, and we are back to the previous picture where you reach another server.
There are two types of anycast, what we saw on the previous picture was global anycast. This is local anycast, which is actually something that you might call load-balancing. And this has been in use for a long time. When the traffic hits one of those copies, you can attribute the queries among several actual computers that are located in the same facility.
The current anycast situation is that 7 of the 12 root server operators – remember, two servers are operated by the same administrators. 7 out of 12 are doing anycast in some form. Most of these are local anycasts, load-balancing. A few do global anycast. It's not particularly dangerous. And there is actually lots of experience about this. It's been done with web servers and other kinds of servers for a long time.
Here's a list of plan of what the root server operators that do plan for anycast are doing. Some are doing it within their data centers only, within their networks. Some are doing it in several different places all over the globe. Some do it to provide it only to their own customers in a better way.
And some are focused on special regions. It varies from organization to organization what the plans are.
Another thing on the table has been IP version 6 and how to make the DNS root available over IP version 6 transport. That's trickier than it might sound because it's useless unless we can also tell in the root zone with data, DNS data, that the data is available at certain addresses.
And we need to put in new records in the root zone that deal with the IP version 6.
Unfortunately, there is a special query that is very important in root service. And that is the so-called priming inquiry, which needs to be fit in one single packet. And the packet can, due to an old limitation in the specification, only be 512 bytes large.
With that limitation in place, we can only fit two of these IP version 6 addresses in a package.
So the first plan is to use the anycast model for these two addresses so we can have many copies, identical copies, of these two servers all over the IP version 6 part of the network.
Eventually, the goal is to add IP version 6 records for all the 13 root name server instances, or, rather, administrative servers. And if we do that, we will have to require the use of something that will extend the DNS, which is a recent extension to the protocol that can handle bigger packets than 512 bytes.
Delegation response size.
When someone queries a root name server for something, it's – it's always handed off to a top-level domain server of some kind, with information in a DNS packet.
That delegation information takes up room. And if you're not very careful, you might hit the 512-byte limit. This is something that the ccTLD has to think about when they send information to ICANN.
If we – actually, responses include a copy of the query. So the longer the query, the less room there is left in the packet for this delegation information.
There are ways around this. For instance, you can use the same trick that we've used with the root name servers to name all the name servers for certain top-level domain or other domain using the same domain name. All the root servers are called a, b, c, but they're all called rootservers.net. That will actually make data fit better into the packets.
If you add IP version 6 records to your delegations, this will also take up room. Remember that. And you also have to think about what should happen if data does not fit in the 512-byte packet.
What type of data should we cut out? The IP version 4 data or the IP version 6 data? Or should we let that be determined on – by how the query came to us? If it came as a version 6 transported query, then we should probably put version 6 data into the packet, and vice versa.
Internationalized domain names is also an issue, because this will also open up packet size limitation problems.
IDN names are longer than traditional domain names. So they take up more space. And remember that both the query and the response fill out this packet.
There have also been – there will be some interoperability testing. In May, there is going to be one set of tests in the US in the beginning of May, which I was informed of only this morning, and later in May in Europe. Maybe it was the other way around.
There is a potential problem with the notion of the dot as the domain name label separator. You're all used to www.icann.org as a separator between labels. If we're not careful with idn, we might end up with situations where it's not obvious that a dot should be a separator between the labels. So we probably need to look into the specification there and make sure that that's the case, that the dot is always seen as a separator.
And we are already – we are already seeing more traffic due to queries with IDN that have longer and bigger packets and thereby generate more traffic.
This concludes the report from RSSAC. And this presentation will be available at that URL.
Any questions?
We are, I think, four root server operators here. If you have any questions during the week, thank you. I will leave right now for the airport, but I will be back later this afternoon. Questions from the floor are welcome.
Vinton Cerf: I do have a question. And, of course, I'll call for questions from the floor and from the Board.
This is out of ignorance and I'm embarrassed to ask this.
Do – do the root servers maintain statistical information about the performance of the roots that can be seen by the public?
Lars-Johan Liman: That's an issue that we have discussed also. Some of the roots have public data. Other roots are working on providing public data, and some have data that is not public at all.
It varies from site to site.
We are working on a way towards a common front page, so to speak, where you can reach the information for each and every server that they want to make available. And we generally don't want to make statistical data available in real time, because that's something that people that try to attack the root servers are looking for. They will see – they issue an attack and then they want to see in the statistics immediately that, oops, yeah, I hit them.
So usually it's with some delay. But we're working on it.
Vinton Cerf: That's sometimes called the CNN problem.
So, yes, I agree with that. I'm only looking for something that's of historical use, not too out of date, but just some sense for trending of performance.
Are there any other questions from the Board or from the floor?
Everyone is hungry.
Thank you very much – oh, is there a question there? It's Amadeu. You need to wave your hand bigger.
I'm trying not to see you. Yes, that's right. Thank you.
Amadeu Abril i Abril: Thanks.
Hi, Liman. A couple questions. The first is, regarding anycast, the misperformance of any of the servers that are added by this anycast experience can affect the overall queries, I mean, the quality of the queries that are sent to the root, that is, is there an automatic way to redirect that because they are not performing? Or the behavior – they have a real impact in case that they are but for any reason not working in the appropriate way.
The second question is, – well, no. Let's – let's do only that question so we keep it short.
Lars-Johan Liman: Okay. Is there any way to avoid hitting a copy that's not working properly? Okay. No, there isn't, but you still have – you have that problem today already. If my server stops working properly, there's no way for you to avoid reaching that server if you're sending the packet to my IP address.
But remember my server is not the only one. So what we will have is not one set of anycast server, but, in the long run, maybe 13 sets of anycast servers. It's 13 times the number of anycast servers that are out there, on average. Which means that if you cannot reach my server because my copy of that is closest to you is broken, you will go to "b" or "f" or "g" instead and reach that server. And the probability that they will all be broken near you is probably fairly small. At least we see it as an improvement to the situation today where we have only 13 sites, going towards more sites. And it will also, if there's a problem with my server copy in Madrid, it will not affect all the users on the Internet. It will be localized to the Madrid area.
So it's, in general, it's better. And for you, it's not any worse.
Vinton Cerf: Thank you. Good point. That seems to be the last question, so I'm going to close this session.
We will reconvene the public forum again tomorrow morning at 8:30 in this room. And I wish you all a pleasant and productive afternoon.