ICANN Public Forum in Bucharest Real-Time Captioning
27 June 2002 - Morning Session
Note: The following is the output of the real-time captioning taken during the ICANN Board Meeting held 27 June 2002 in Bucharest, Romania. Although the captioning output 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
Thursday, 27 June 2002
Vinton Cerf: Ladies and gentlemen, I'd like to call this meeting to order. This is the opening session of the two days of ICANN board meeting. My name is Vint Cerf. I'm Chairman of the Board.
We have today a public and open discussions and reports, which will continue throughout the day and into the early evening. I intend to schedule breaks during the day. There will be three of them scheduled, one at 10:30 in the morning, approximately, a lunch break from approximately 11:30 to 1:00, perhaps a little bit later. And then a 3:00 break. We hope to allow at least an hour of time for open public comment, starting at 5:45 this evening. I'd like to call upon Stuart Lynn, the CEO of ICANN, to begin this morning's session with his report.
Stuart Lynn: Thank you very much. Are these mikes on? Can you hear?
Due to technical difficulty, I'll be talking like this, looking at the slide. I don't have my laptop up here. This is the President's report this morning. I'll try and be brief and to the point.
Just a year in review. I'm trying to figure out the best way to do this. Let's see. maybe if I come over here, that will be better.
We've actually accomplished quite a bit this year, in spite of having shortage of staff, as we'll talk about later. We're down 4 from our authorized complement for budgetary reasons. But we did complete the last of the gTLD agreements that were - I think two that were done the previous year and five this year. All of those are signed. 6 of the new gTLDs are in operation. And the 7th will come up in due course.
We have signed - that says 4. Actually, it's 3. One is subject to Board approval tomorrow. ccTLD agreements, which started down what will undoubtedly be a very long and laborious road. There are several more in the pipeline. But we have done all the work on those 4. And those - that work has been done on others as well.
We have strengthened IANA services with some process streamlining. We're not as far as we'd like to be, but we have made significant progress both in the processes and the information that is communicated to those who need IANA services. We have negotiated an agreement with the address registries that at least at the staff level was signed off on. The Boards have not approved it. And whether it or another agreement or what will be approved will spend on the outcome of reform. But that work was done. Took a couple of years to bring to that point and was done with some very constructive discussions among all of the parties involved.
We organized in Marina del Rey with not as near as much time before the conference as we would have liked a major conference on security. Many of you participated, and we appreciate all the support and help from many, many speakers and contributors from all over the world It led to the formation of a Security and Stability Advisory Committee, which is now an advisory committee of the Board. It is chaired by Steve Crocker. And you will hear from him on the status and progress later on this morning.
Katoh-san of our Board of Directors chaired an excellent committee on international domain names that was launched and staffed and supported. David ThomPSOn and Andrew McLaughlin both provided staff support to that committee. That committee will report later on this morning. I will anticipate their report.
The so-called redemption/grace process, with all of its spiritual overtones, for those of who you come from one set of religions, at any rate, has been developed, has been brought to fruition. You will hear more from that later on.
The dot org bid process, a substantial amount of work was launched. The RFP issued. And you heard from the 11 bidders last night. I'm very pleased with the bid response, and I think we have some excellent choices. And that will move towards completion before the Shanghai meeting to allow the successful bidder time to implement before the end of the year. Of course, a minor thing called the reform process that some guy kicked off has been launched, has occupied a little bit of of our attention and guess what, you're going to hear more about that today. So I will talk more about that.
I'm very, very pleased that the activation of LACNIC, the new address registry in Latin America, has been made significant progress. It's been an exemplary partnership between the ARIN who currently provides services to the Latin American community and LACNIC, which is the emerging registry. I think what they have developed is a model of how such things should be transferred. The final details have been worked out. Over the next several months, there will be a transfer of records that is auditable that all the attorneys have signed off on. All the folks at LACNIC and others have worked together as I said, in exemplary fashion. Every expectation is that that will lead to a final recognition of the transfer by the board at the Shanghai meeting, and at which point the - LACNIC will be totally independent and fourth address registry. So I think that's very significant.
Administratively, on the budget, we have 25 authorized head count. For budget reasons, we were not able to hire up to the complement. 17 are on board. During the year, we Theresa Swinehart joined us, counsel of international legal affairs. Kent Crispin is technical systems manager. Michael Haynes, administrative assistant. They have made an enormous difference to the staff of ICANN. But just not enough. We are still considerably understaffed. And that will increase when Andrew McLaughlin, who's been with ICANN since its - in one form or another since virtually its beginnings, will step down as Vice President, Chief Policy Officer on July 1st, and go half time. I'm hoping it'll be half time of a 200-hour week. Andrew, as you know, has made extraordinary contributions to ICANN, and he - but he wants to devote more of his time to his academic career at Harvard. And this is a transition that we may miss, but we may regret from an ICANN point of view, but I'm sure we all wish Andrew well as he moves on in his career.
We made significant improvements to our computer facilities thanks to the work of John Crain and Kent Crispin and our system over - in our system, overhauling our systems to make them more robust. That work, steady background work, is steadily improving. We haven't gotten as far as we would like on programmatic accounting, which is where instead of accounting for things like personnel and travel, we still do that, but we do categories that relate more to the programs and projects at ICANN.
We expect it and it's been discussed with the Finance Committee. But for sheer reasons of time, there's not been time to do it. We expect to do it July 1. From a financial and budgetary point of view, this is just a synopsis. There's more of this that can be - will be obtainable on the web.
As I indicated, staff was not hired to authorized levels. As far as expenditures are concerned, we're pretty well on budget. We had some surprises this year such as our insurance rates tripling. Unfortunately, our insurance rates came up for renewal right after September 11th. And the - since ICANN is not - is not exactly a known quantity in the insurance world, it is somewhat unique, they decided to raise our rates considerably. That made the difference. But, essentially, we're on target as far as expenditures are concerned.
As far as revenues are concerned, the base revenues, which is revenues from fixed and variable fees from registries and registrars that are under agreement, we came ahead of - significantly ahead of budget. One of the primary reasons for that is the number of new registrar accreditations has gone up significantly over what we predicted in the budget. And I forget the exact number of registrars I think we have now. But it's - I think it's around 180 accredited registrars.
We have our usual situation with respect to voluntary contributions from ccTLDs where we have no agreements, where in the past, you'll see we're going to do this differently in the future, just as last year and the year before, we budgeted a very unrealistic level. It's what it would be if every single ccTLD registrar - registry paid us everything we'd like them to pay us. But since there's no agreement, there's no reason why they should. And we depend on the generosity of their contributions. And as last year, as of this point in time, that well, it will fall considerably short, just as last year, of that target. This is expected. But that number of 565,000 should increase in some of the days and weeks to come. Then the other depends on meeting expenses and relates to sponsorship and stuff like that.
But as a net bottom line, we're in the black, around 300,000, short of the 750,000 we've budgeted, but we always expect that because of the difference between the ccTLD actual revenues and what is budgeted. As I indicated, we're going to change the methodology of that this year so it doesn't create this kind of funny situation that looks as though we're falling short of budget each year when we're really not.
So, let's see, are we doing questions as we go, vint? Is that
Vinton Cerf: I'll find out. Are there any questions from the Board? Evidently not. Thank you very much, Stuart.
Stuart Lynn: What about the audience? You do for the audience?
Vinton Cerf: Well, I hadn't I hadn't planned to. But
Stuart Lynn: That's fine.
Vinton Cerf: I was going to allow that to happen later in the day. Jun Murai, like to call on you to report on the root server system advisory committee.
Jun Murai: Okay. Good morning. Where's the presentation going to be? Okay. I'm going to briefly report about the status of the Root Server System Advisory Committee. I need to see that. Okay. So go ahead.
So the I don't repeat about what root server operator means. But we are taking care of the dot over the entire tree of the domain name server things. And we are doing the distribution, making the root zone file contents available to the community. Okay. And so the committee is on the bottom half of this. So, basically, defining, you know, what kind which TLD should be added and deleted and that kind of decision will be made by ICANN, IANA, and also the US DoC responsibility.
And the bottom blue frame is basically RSSAC role. So and the root server operators' role. So IANA root server operator's role. So RSSAC is basically discussing about the root frame contents which are the contents of the database and distributing it among the various root servers and making it available to everyone. That is the load. And then RSSAC is to advise the ICANN board about that function, as well as the - you see this tiny blue frame in the middle, which is, you know, a lot of question raised about the new locations of the root name server things. And then all the committees also tried to be responsible on finding a way to define the new location and, you know, that kind of information. And the mechanism to do that. Okay. Go ahead.
So this is the distribution of certain root name servers at this point. Go ahead. Sorry about some fonts are okay. Anyway, so 13 of them go ahead. Go ahead. And we had 12 meetings in the past. If you look at carefully, most of the meetings are actually done along with the IETF meetings, not with the ICANN meeting here. Because most of the related people in the committee members are very well participating in IETF rather than this meeting. And the operators are very busy, and they have to work 24 by 7 time frame. So it's really important to have the meetings together with IETF. That's our decision. And we're going to have the next meeting in Yokohama, IETF.
And we had some updates on the - from - since the last meeting to this meeting. But we had a - in the last meeting, about November, we had a security panel in the ICANN meeting in Marina del Rey. So then we have discussed, but we exposed, actually, many of the security aspects of the root server operations in there, which is basically the - you know, the root name servers are, you know, distributed around the globe, and that then - the distribution and the, you know, variance of various technology are the keys of the reliability and the stability of the root name server. Go ahead.
And also the zone file transfer, which was not known to the community. But that was explained at the meeting.
And then, again, the zone file transfer within the root name servers are very - operated in a very secure manner, including the various - including encryption and also the online, offline, and the, you know, various things.
Those are the information disclosed to the community during - using this opportunity.
But I think these kind of activities are really important.
And also, during this meeting in bucharest, we had a meeting, ccTLD people invited us for exchanging information, sharing the information about the root name server things, which was finally happened. But that was a very important meeting. I appreciate the people who arranged the meeting.
And DNSsec is one of the technical activities we are working on. And starting from a root name server and working on the DNS circuits are really important. go ahead.
And IP version 6 readiness is another issue. And some of the root name server operators on the systems are having tested to be available for IP version 6. And then, you know, the we really need to have a consensus with groups like IETF. But we are also doing that and working together with those people for the other readiness of that IP version 6 and the root name server operation as well as the extending to the other part of the DNS system as well. and IDN impact.
We review the IDN impact on the root servers already. And then the proposed then we concluded so far that the proposed technology should not be any impact to the root server operations. So that's fine. But we certainly need the testing period before the real operation. so that's kind of a communication also are important. That's a result of our discussion. Go ahead.
And then the contract. Contract procedures are one of the big issues we have to do. And then this is - (inaudible)
Initial specifications and drafting of the MOU have been done. And then (inaudible) around the operators and the review and modify and depend on that review. And then also, since the nature of the operators, the institutional and the legally responsible person for each of the operators now being on the list. And it's changing. And then they know we really need to coordinate with those people to complete the process.
So that's what we did. And then now we started a discussion including those people who are responsible for legal and the contractual things and are based on the result in the past. and the relocation decision is a hard thing. Not only technical things, but also a lot about politics could be involved. And then and so far, what we are trying to achieve is we have a very accurate information about a statistic status of relating to the DNS and the root name server around the world. So without that, we can easily use only the political discussion to define the future decision on the new location of the root name server. So they are working with other groups. Go ahead.
Those are go ahead. Those are some of the results out from those measurement work. We asked the two actually measurement group to generate information and statistic status relating to the root name server and the DNS in general. Go ahead.
These are these are measuring the (inaudible) from the various points, go ahead, in the world. Go ahead.
And each of the root name server is receiving from which point of the Internet, is another measurement scheme generated.
This is a list of all of the certain root name servers' behavior.
And this is a new one, actually, that we are now using the distributed starting point all over the world, using the dialup assist point and then measuring all the root name server and the (inaudible) of the server from that point. It's paying a lot of long-distance telephone bill, but it's very effectively viewed the kind of status of the entire major root name server thing.
So what those are could generate a very good idea of, you know, this which part in the world is kind of less services from the point of view of root name servers. Go ahead.
Okay. So this is the summary. So we have the root DNS operation, and we this is our concern. And the security and stability have been discussed recently in the panel. And also we are a member of the DNSsec, which Steve Crocker will explain later, and the contractual things. The CRADA report is one of the big tasks. But this is all of the information collected. And this is on editorial action phase. And for the location activities that we do, all the performance and measurement, we I just show you. Okay. Go ahead.
And these are the important URLs updated. Thank you very much, for many people suggest to me they're kind of old URLs and different URLs are there are mistakes on it and typos. So I think I've fixed now this time. So please check the URLs again. Go ahead.
And the schedules. We're going to have the next meeting in next month no, this month, right after this one, in Yokohama.
So email@example.com. Any comments or advice would be appreciated. Thank you very much.
Vinton Cerf: Thank you very much, Jun. If you'll wait, there are some questions. Helmut and then Amadeu.
Helmut Schink: Thank you, Mr. Chairman. I have some questions. The report sounded a little bit like a technical expert's opinion on the stability of the root server system.
As far as I understand, there are some questions concerning the operation of the root servers. One thing is the further internationalization of the location of the root servers. You mentioned that it is globally diverse. But at the moment there are 10 in the US and only 3 in non-US countries. And I think it's a political will to further globalize the situation. And you mentioned that you need some, let's say, political input into the technical debate how this can be done. And I think we need to find a way how to stimulate this and to give the root server system advisory committee the appropriate input.
So my question is, how can we progress this issue?
Next question is, the number of the root servers is currently limited to 13. And I am asking for some guidance whether this number is really technically a technical limit or whether there are some other limits or some other reasons not to enhance the number further.
Next point is that, well, unfortunately, I don't know the name of the operator, but one of the operators seems to run out of budget and run bankrupt in the US, PSINet. And what happens with this? Does this affect the stability? And what happens with this root server?
And the last question is that in the board meeting in 2000, the Root Services Advisory Committee was actioned to prepare a report. And whether there will be a kind of final report or whether this is replaced by this ongoing report. Thank you.
Jun Murai: Okay. You raised many questions. So I almost forgot the first one. first one was okay, internationalization.
Yes, the internationalization, the reason why we have okay. We have a you know, say, 10 other root name servers inside the United States. I think that was reasonable in the past from the point of view of traffic and all of the nodes there distributed. And, yes, that has been changed. And IANA has been under IPG and other groups has been making a lot of efforts for kind of adjusting to the reality. And the result is, you know, three of them are relocated from there. And then two of them still are candidates of relocating. That was the phase when the iacc started, and we continued the work of the former group of, you know, those intelligence. And then, you know, tried to but the important thing is service, quality of services to everywhere. And root zone file should be properly serviced to any part on the Internet. That is a very important fact.
And then according to that line, that purpose, we really need to know the engineering background.
You know, it was so simple in the past. But it's not that simple now.
So the reason why I showed a lot of you know, we are spending and with a lot So we really need to find out the engineering and traffic-wise status of the DNS operations. And then based on that, then we can add or define the schemes or mechanism to define that. and probably that part we need to deal with, you know, some of the politics or something. But that's a part you know, the initial thing is this here is what we have as a kind of engineering result, traffic-wise result. And then that is what we can do to the ICANN board at the first phase.
And then we can discuss about the further mechanism to do defining the location. That's our plan so far.
And then the the what was the second?
Helmut Schink: 13.
Jun Murai: Okay, the intention of 13 comes from the protocol period, technical things.
And then, okay, then there is a proposed way for increasing the number of the root name server. And then you know, so either, you know, taking that things into the entire Internet operation, that kind of a decision should be well discussed in the IETF DNS Ops working group and other operational entities. And then so there could be, you know then we can discuss about, say, many root name server location program; right?
Okay. So either way, we're going to need the measurement thing. We need to understand the situation.
So the you can consider that the okay, phase one, as for the relocation things, phase one is how we can manage 13 root name server in terms of the location. That is a phase one task. And phase two task is what if we have, you know, many root name servers with introducing the new technology, and then, you know, how to progress location, locating those many root name server. That's a phase two. Okay. That is the situation.
Then the last question about the what if, you know, one of the root server is unable to continue their operation. Then we really need to find out the way to replace that, yes. but for this particular occasion, then we discussed with the operator and then we checked with the machine and the condition. And so far, we have concluded that, you know, the continuation of the operation on that particular operator is stable and they're continueable.
So if when the condition has been changed, then we're going to discuss about that, and also reporting to the board.
Vinton Cerf: Okay. Amadeu, you had a question.
Amadeu Abril i Abril: Okay. Thanks. First, I will refrain from my usual question about, you know, the plans of the US government for the transition of the policy control over the root, because facts speak much more than words. And so we all know where we are.
Regarding my other my question for Jun, in fact is, so how real operation, some of those that have really been made, there are, you know, the technical aspects of the operation, aspects that you are working at in the RSSAC. My question is, is now anything that should be brought really to the general ICANN policy-making process, the decision-making process that you need from the RSSAC, or there is still nothing that the committee needs from the general framework of ICANN in terms of policy (inaudible), recommendation of work, whatever?
Jun Murai: Okay. Probably one of the, you know, long-discussed issues relating to the non-technical issue was probably the understanding of how the root name server works, and the question like, you know, those are limitation coming from the technical aspects rather than the politics and, you know, location of the root name server is one of the good examples.
So probably then also we have a kind of security and stability problem. And this is one of the very strong missions of the root server operators for the stable you know, doing the operation as a stable manner.
And then in order to achieve that, probably their mutual understanding with all of those, you know, open communities is a really important issue.
So then, you know so one of the things that we have achieved was creating the web service for representing the status of the root name server. That's progress. And then that's on the list of the URL newly added.
And then so that way, we can share the status of the operation of the root name server with the community.
So that you know, sharing the understanding of how it works. And then another point is which is a really important point, is, okay, root name server is not the only set of name servers operating on the Internet, you know. The ccTLD name servers, gTLD name servers, and other name servers, all the name servers are kind of constructing this single distributed system for the operation of the name server things. And then so probably the root name server is just one of the one of the, you know, set one set of the root name server name server thing.
So all of the discussion, like IP version 6, DNS sec, and stability and how to exchange the zone file things and, you know, the root name server is basically the secondary set of secondary servers for the root zone file.
So of those things, those experiences could be shared with the major name server operator, so that that is the only way to create the stability of the whole system; okay?
That kind of a mechanism, for example, were kind of missing in the past. And then probably I repeat the appreciation of the ccTLD committee that now we know that the ccTLD name server, some of them have the kind of issues we already encountered in the past, and then those expenses could be shared with them so that we can create a more stable name server in general as a whole Internet system.
Vinton Cerf: Thank you very much, Jun. I'm going to take this opportunity to make some suggestions concerning the root name servers. one of them is to look more closely at the problem of the number of name servers. We know that the number is limited by the technical implementation of the system. The flexibility that we have is, therefore, quite limited in terms of how many root servers we can place. There is a design that allows a larger number of root servers, but the architecture has some limitations. We can increase the total number of servers, but they have to be clustered and grouped in a certain way. The order in which we approach this problem depends a good deal on how much more flexibility we can design into this system.
So I think that we would be well-advised to schedule a special not a special meeting, but to use root server as a special topic just as we have, for example, security in the past. And to focus on the several aspects that need to be dealt with; the flexibility and expansion of the root name server system, the location root name server system, and setting politics aside for the moment, the most important thing is that the root servers be located in places in the net where they can be reached with the least delay and with the most bandwidth, so that the system will work efficiently.
And finally, the statistics that show the ages of the various DNS software is very distressing to me. We need to do something to upgrade all of the DNS servers, root and otherwise, to the highest quality and most recent versions. That includes the ability to handle ipv6 because we should be looking forward to that capability as well. So my recommendation is we deliberately plan a time when we can have a discussion on the technical and political side of the root name servers and I will commit to finding a time to schedule that.
Are there any questions from the folks here on the floor regarding root name servers?
Vinton Cerf: Thank you, I'd like to call now upon Stephen Crocker who is the chairman of the Security and Stability Advisory Committee.
Stephen Crocker: I've just been advised I should make a quick, small change here which I will do, and then we will get going. I will note that there is quite a lot of overlap between what we are doing and what jun has just reported, and that's a good thing, basically, because quite a lot of the strength of our committee comes from the many hooks we have into all the different committees. stephen crocker I'm ready to go here and all I have to do is - good. I'm Stephen Crocker. I'm the chair of the Security and Stability Advisory Committee. Is that the right name? The name has moved around slightly over time. I'm going to talk about the brief history and what we're doing and who we speak to, and then where we are. stephen crocker We're not nearly as far along as the root server committee, for example, since we're much newer. But we're off to a good start. There was the events of 9/11, of course, and then a quite excellent meeting that I unfortunately was not at in Marina del Rey with great participation and excellent presentations from a number of experts on security, and the board directed the creation of this committee. stephen crocker It started as president's committee, got converted into a standing board committee. In some sense, that's of keen interest, I suppose, in the legal standing but has not greatly affected us. The committee consists of a really excellent set of people who are plugged in across the entire operational and intellectual structure of the of security and networking. I have to confess that I had essentially nothing to do with forming this committee. It was handed to me and I was astonished at how good it is. It's just amazingly excellent. And the committee is distinguished by, as I said, having its hooks in every part of the operation. We have root server operators represented, gTLD operators, ccTLD operators, name space registries, the registrar community of course and experts in Internet protocols. Every member of the community is a full-time technical or operational person with another life. There is no political or policy orientation to the membership except as required by their experience. But it's sort of deeply focused on the set of issues that we have here. And for example, Jun is a member of the committee, and so many of the things that he talked about, as I listened to his report, I was thinking I could just say any questions, he's given a good portion, not everything but a good portion of what we're talking about and that's a good thing because there's very close coordination, easy communication.
Our charter covers developing a framework for DNS and address allocation security, reviewing the requirements for protocols and technical changes and speaking to the groups, particularly the IETF, who might have an interest in improvements or changes in the protocols where necessary, engaging in risk analysis and tracking the progress and reporting on it. We are not an operational committee; don't call us if things go down to fix it right now. Somebody is responsible for each and every one of the parts. But we definitely want to understand how the parts fit together and what the technical issues are and the long-term issues.
We are, as an ICANN committee, obviously responsible to ICANN and to the board in particular, but we also view ourselves as speaking to and reporting to the community at large, particularly the IETF and the security community, the operators of the various moving parts to the governments and last, but obviously not least, is the general user community and the public. Our approach is to look at and to make progress along three broad dimensions, which I'm calling here strength, measurement and communication.
With respect to strength, the theme is figure out what the system should look like and try to plot a course for getting there. That means considering the protocols, the system design and the operation of the systems; to some extent the registration procedures, although not wanting to get into the non-technical areas of misrepresentation of names and the interactions between a registrar and a registrant with respect to identity issues but to the extent there's technical support there, we can touch on that. And most particularly, trying to understand what the threats are and to make sure that they're countered in both the design and the operation of the system.
One of the things that I think will make a very important difference in the whole process is to be very crisp about understanding how well things work and how well things do not work and to plot ourselves a course for improvement, and then having a way of measuring that. measurement is a complicated subject.
I don't mean to make light of it, but I think it will help us tremendously in bringing precision and making sure that we're all talking about the same things. There are two basic parts to the process one is laying out what it is you're going to measure and the other is actually carrying out those measurements. laying out what the measure is where things are start out being tricky. Not everything is easily quantifiable. In some cases, we will be measuring in the sense of laying out milestones that are more discrete rather than numeric and plotting a course there. The other thing, the other part of our trio here, is communication.
I don't have a separate slide on it, but we will be publishing, on the ICANN web site and in other forums, the progress that we're making and the results that we're achieving and trying to have quite open statements about all that.
We're a standing committee, but my view is that we have sort of two broad phases. One is improve things up to a level that we set out to achieve, and then once having achieved that, which I hope we do, reevaluate, shift into more of a maintenance mode.
I don't have a precise schedule of criteria yet for you, we will, but I'm guessing that we're talking about a couple of years. That's much longer than anybody would like; it always is. But it's not a couple of decades, which is the way these things often go. More to the point, in the near term, we will have pretty good description of how the parts fit together.
Oh, I'm not loud enough. That's unusual. (laughter).
Stephen Crocker: We'll have a good description of how the parts fit together. You saw from Jun's slides that even if you just look at the root servers, there's some interesting topology. You have, just for an example, 13 root servers, but what's constitutes a root server is sometimes a collection of machines so there's two layers of description there. And as jun said, that's just the root servers. You throw in the top-level domain servers and the names the address allocation servers and various other parts, and the parts get pretty interesting.
There's multiple protocols in play, evolution of those protocols. Then with that as a base, an identification of what the vulnerabilities are I think is an important thing. This is a potentially controversial area. It's not uncommon in security discussions to try to keep an open discussion of vulnerability not open; that is, to keep it all under wraps. I think that it's very important in this situation to have a pretty crisp discussion of where the vulnerabilities are. The bad guys have a much easier time of sharing all that information, and will just go a long way toward reducing confusion and imprecision if we're laid out on the table. And then from that, a clear understanding of the security architecture, what is and what should be. And then the beginnings of a measurement framework.
I don't know how far we're going to get within the next three months but I hope we'll get reasonably far. That's the near-term schedule. All the interest things happen between the near term and long term and I'll be happy to report on that next time. I think we'll be much further along.
Interacting with other groups is absolutely essential. I did not start out this slide with the most obvious, which is the other groups within ICANN, the root servers group being perhaps top of the list. So all of that goes without saying. There is an initiative on the part of a handful of large companies it started actually at the CEO level, Andy Grove at Intel and his counterparts at HP, Oracle and so forth put together a cybersecurity working group. They spun off a related group trying to use IPv6 test beds to conduct some experiments under the rubric of accelerating trustworthy Internetworking and then there are measurement groups in various places and we will coordinate with them. I've listed a couple here, but there's plenty more, of course.
That's the basics of what we're up to at the moment. I'm quite excited about the group itself, and the work that we're taking on. I think we have a chance to make a real difference here.
Vinton Cerf: Thank you very much, Steve. Questions, from Stuart Lynn.
Stuart Lynn: Not a question but a statement. I'm not sure everybody is aware, but Steve has a distinguished Internet career, and that was recognized last week when he received the 2002 IEEE Internet award. And I think we should congratulate him for that great award. (applause).
Stephen Crocker: Thank you. That is Stuart trying to distract you from asking any interesting questions, I think. (laughter).
Vinton Cerf: Well, it hasn't succeeded.
Stephen Crocker: It hasn't succeeded.
Vinton Cerf: I believe there's one from Amadeu.
Amadeu Abril i Abril: Thank you, Steve. One question, is your group also dealing with not hard core technical security like, for instance, data escrow from registries and registrars and things like that; just, you know, techniques for recovery in case of disaster or just with direct technical issues?
Stephen Crocker: That's a very good question, how broad the scope is. We have not considered details of recovery procedures of escrowing and duplication, but we do know that the operators of each of the systems worry about those sorts of things. And I'm speculating slightly, but I think it is within the scope of what we will be considering is to ask how strong those recovery procedures are, both on an individual basis and on the ability to switch over rapidly for redundancy and that sort of thing. Have I addressed your question?
Amadeu Abril i Abril: (nods head up and down.).
Stephen Crocker: Yeah, Thank you.
Vinton Cerf: Andy.
Andy Mueller-Maguhn: I guess you are aware that in the it security world, some security measures are being taken more and more surveillance measures instead of security measures. So in what kind of terms are you assuring that in your committee privacy issues are watches when, for example, registry data is being escrowed to other places?
Stephen Crocker: That's one of the nasty questions. So we have it's a fair question, but I have to say we have not actually looked at any of the privacy-related aspects. Our focus is driven first and foremost by what does it take to keep the core system operational; that is, the primary threat that we're concerned about is that somebody takes down the Internet or major pieces of it, or in a closely related thing, poisons the information so it's effectively either misdirected or unavailable.
There is, of course, a very large and important area of protecting the privacy of the information. speaking personally, and I don't want to speak on behalf of the committee, my view is that although there's often a relationship, that it's not an either/or situation, and that it's fundamentally orthogonal.
I don't immediately see a need for intruding on the privacy of people in order to improve the security in the senses that we're dealing with or the integrity of the system. And from the perspective of trying to keep our committee focused, effective and bounded, I feel obliged to not take on not get drawn into a separate and broader topic, which admittedly deserves a lot of concern but it's not the concern of this committee; at least at this time.
Andy Mueller-Maguhn: I mean, let's then I might say it another way. I'd be happy if the transparency of your work and if it comes to a point where privacy issues are touched, you're also free to cooperate and okay to cooperate with privacy-related people and that field of groups.
Stephen Crocker: I think one of the key things is that by being open and explicit about the measures that are being taken and the concerns that are being addressed, I think it leaves plenty of room for other people to assess whether or not there are privacy issues, to lay to rest concerns that turn out not to be relevant, and to let others participate in the process of seeing what those interactions are. And I think that's an important aspect to what we're doing.
Vinton Cerf: Thank you very much, Steve. A couple of final remarks. I don't see any other questions coming from the board. Are there questions coming from the floor? There is one two, actually. We have one in the back here.
Harold Feld: Yes, at the 2001 Marina del Rey meeting, director Karl Auerbach had a number of security recommendations that he published, including one which I thought was particularly useful, particularly for those of us who are moderately sophisticated end users, which was usually the home DNS kit, so that if something catastrophic happened, we would be able to resurrect the reconstruct these things at the end points rather than centrally. I'm just curious if there's been any if Karl is working with the committee or if there's been any follow up on the recommendations that he made at the 2001 meeting.
Stephen Crocker: In truth, I need to go back. He sent those in, and I read them, and I need to go back and review them in the light of sort of where we have focused our attention.
An interesting question, just with respect to the users reconstructing things at the end points, is assume something really catastrophic happens. Would a sophisticated set of users who will represent, as we agree, a very, very small percentage of the total users be able to do enough that would effect that would be relevant for the system as a whole? And even if you can reconstruct things inside your house, the thing you want to talk to will be down or the thing it needs to talk to will be down, and so forth. But I don't want to prejudice the discussion. I mean there could well be I like the idea of a very distributed and sort of self-reconstructable systeMs. that would be very nice. There is quite a lot of overlap, as I recall from my last reading of Karl's note, with things that we are doing, and of course as is characteristic of karl he opened up some new areas, and I agree it would be worth going back and looking at that.
Nigel Roberts: Good morning, Nigel Roberts from .gg. I don't want to anticipate something too much that will be covered in the ccTLD communique, but I'd like to ask Steve if the committee would consider examining the system processes used internally in ICANN for weaknesses and vulnerabilities; specifically, the IANA function.
Stephen Crocker: We've been I'm not sure I know all of the aspects that you might be referring to, I suspect there's some context I've been blissfully unaware of. We've first and foremost been concerned about aspects at the architectural and operation level. And the process issues surely can be important but they operate at kind of a different speed from the things that take systems down abruptly and create massive havoc. So we have not focused very much attention on that. I think a useful thing to do, and I guess you're suggesting that we will hear some of this in the communique, is to elaborate on that a bit more, and give us some fodder to chew on, and we'll be happy to do so.
Nigel Roberts: In fact what was referring to was the process for making changes which was identified at the special meeting at Marina del Rey, being able to make an urgent change in, for example there is an urgent need to make a technical change. So it's an operational matter, such as for example, a major telecommunications carrier goes bankrupt, like happened in Europe recently.
Stephen Crocker: I see. What was the comment I heard recently? Maybe it was last night about not making any changes to oh, this was during some of the .org presentations, I remember. Yeah, we have not yet come to the point where we are grappling with sort of detailed operational issues that an operator is engaged in. And I think under the heading of first do no harm, for the procedures that are in place, they'll be in place for a while and we'll get around to considering how the pieces all fit together. We're in a more strategic mode at the moment.
Vinton Cerf: I'll make one other comment. It's clear from the line of questions that there's a desire to expand the scope of the work that your committee is charged with. A suggestion I would make is that we not necessarily assume that the only way in which to address the matters that have just been mentioned should lodge in your committee. But I am deeply interested in the list of issues that are of concern to people and that we don't want to lose those. So even if you are not likely to cover all of these questions that come up in the committee, should they come to your attention, maintaining a list of those and drawing them to the attention of the board would be much appreciated because some of them do require action.
Stephen Crocker: Thank you. I think that's quite good advice. O can tell you that expanding our scope is something I'd like to resist, and I can further tell you that my wife has been after me not to expand my scope. (laughter).
Vinton Cerf: This has nothing to do with weighty matters. We'll leave that alone. All right. Thank you very much. I note that I've not managed our time very well, and that we are running somewhat behind.
Vinton Cerf: But I'd like to call on Denise Michel for a report on the At-Large Organizing Committee now.
Denise Michel: While they are hooking up the slides, thank you for giving us the opportunity to give a status report on at-large organizing and while they're hooking up the slide show I'd like to introduce some of the At-Large Organizing Committee members who I believe are here today, and I'd like to have them stand up so you can see them. Esther Dyson I believe is here Izumi and Vittorio is around. I'm sure he's working.
You'll recall in at the board meeting in Accra, the board decided that ICANN should have a robust at-large mechanism for meaningful involvement of individual Internet users and called upon the community to devote sustained energy to the creation of at-large mechanisMs. So the community's response to that was to, last month, launch a grass-roots self-supporting effort to establish at-large structures worldwide.
Initial fund-raising efforts were launched by Esther Dyson, and I am temporarily coordinating the efforts both for organizing and coordinating fund-raising. So far we've raised 17,000 from both individuals and companies. We're definitely seeking additional support. An ICANN at-large project account has been established at ICANN, we're taking checks, cash, wire transfers, and here's where you can send them. You get a nifty at-large t-shirt if you send in a thousand dollars. So the results in less than two months, we have been quite pleased with the results so far. We have 16 at-large structures that have been either created or designated so far. They represent over half a million individual Internet users in over 70 countries throughout the world. and their intent is to provide the meaningful informed participation by individual Internet users that ICANN has called for.
Here's a list of those structures.
As you'll note, 14 of the 16 structures are established professional recognized organizations. So these at-large structures can be either new or existing groups that commit to involve individual users in ICANN's mission. The structures have been asked to commit to five criteria: openness, participation, and self-sustainability. They commit to engage in outreach and education of individual Internet users about ICANN and the issues that fall within ICANN. They also commit to involve individual Internet users, aggregate their views and identify the relevant user priorities.
They are soliciting opinions of their members on these issues, and they've committed to working with all of the ICANN stakeholders to address issues, develop positions on ICANN policy.
To help coordinate these efforts, we've created a temporary informal group that we call the At-Large Organizing Committee. It comprises representatives of each of these at-large structures. as new structures are created, new members will be added to the committee. We also included to help launch the effort a former member of the at-large study committee, Esther Dyson, and former members of the NAIS group, Christian Ahlert and Izumi Our web site where all this information is contained is at-large.org. Here are the current members of the organizing committee. Quite a breadth of geographic and professional diversity.
The focus of the committee is to conduct outreach, identify individuals and groups throughout the world that are interested in the relevant Internet user issues. We'll be managing surveys and we are discussing relevant issues of interest to the groups. Primary focus right now is to identify both the common and the conflicting objectives that are of interest to the Internet users and fall within ICANN's mission. We are working on establishing mechanisms for coordination and cooperation and policy development among the at-large structures that have been created and also with the other ICANN stakeholders.
And I think it's very important to mention that the basic premise for this at-large organizing effort and the new structure has been to focus on the substantive contributions that these organizations can make to the business of ICANN. The groups feel they can enhance the user perspective and focus of ICANN's work.
So, currently, the at-large structures are examining several issues to determine which issues we're looking to identify one, two, or three at the most, priority issues that we can provide substantive contributions on. And I'll run through this list very quickly. These are the ones so far that we've been examining and discussing and they're talking to their membership about. Internationalized domain names, practices and policies for registering and transferring gTLDs, requirements regarding the provision, access to, and use of WHOIS data. Domain name intellectual property issues, introduction of new TLDs, implementation of IPv6, fair allocation of address space, and finally, the participation and representation of at-large in ICANN. Several of the At-Large Organizing Committee members submitted input to ICANN's Evolution and Reform Committee. The gist of that input was that since the board has agreed to support self-organized at-large and since the organizing efforts have we feel been successful thus far, the board should plan to institutionalize new at-large structure to ensure the individual user perspective is represented and brought to bear on ICANN's policy and decision-making. They recommended that at-large be given a seat on the board as well as the Nominating Committee. And also that the Accra resolution be followed through on and that a structured role for at-large be developed in ICANN's policy-making process, involving both the current at-large structures that have already formed, as well as the future at-large structures.
They also were very supportive of the proposals to improve the policy process within ICANN, and recommended that the policies and issues should be referred to an at-large entity for review and input. That an at-large entity should designate liaisons to other ICANN policy-making bodies and that staff should be designated to support at-large policy work. To help ensure greater transparency and participation, accountability, we support the establishment of specific time periods, mechanisms, and processes for public involvement in policy development.
Going forward, the At-Large Organizing Committee will focus on supporting the formation of additional at-large structures worldwide, providing input on ICANN reform, and also and I think most importantly identifying and providing input on key ICANN issues.
Please take some time to check out our web site. We welcome any suggestions or comments or support that you would like to provide. And I and the other At-Large Organizing Committee members would be happy to answer any questions. Thank you.
Vinton Cerf: Thank you very much, Denise. Are there any questions from the board? I have one.
One of the things that I've noticed is very difficult to do when working with a large and distributed group of people is to ascertain what their interests actually are and to find a way to accurately express that. When you have a hierarchical structure, which is what I imagine this to be, it's not always clear what method various parts of this hierarchy use in order to capture user interests. And so one of the questions I have is whether the at-large committee is looking at each of these various at-large structures and either asking or suggesting ways to capture user information and user input in a way which is at least accurate. Here's what I'm worried about. The classic situation is you have a hierarchical structure, and an individual represents some at-large group and asserts what the views of that population are. But the process by which those views were captured might be quite invisible and perhaps nonexistent.
Denise Michel: Yes. I understand that.
Vinton Cerf: So you see what I'm getting at.
Denise Michel: That's an inherent problem in this process. Well, just real quickly, I think Esther has something to add. Another objective of at-large organizing efforts to to develop sort of a tool kit that these at-large structures can use both in outreach and aggregating views, recording them, and providing input. So some of the things that you discuss, I think, were intending on incorporating in those tool kits, that we will be encouraging each at-large structure to use to help us build in that accountability and transparency. And esther, I think, has something to add.
Esther Dyson: The first, this is not a wild-eyed idea of something that is going to happen next month. But I do hope at some point, rather than a hierarchical, geographical structure, in fact, there will be something closer to parties, to groups with common interest that extend across geographies that will be somewhat more self-organizing than this is right now. The second is, we are a technology organization. And there's lots of interesting software you can use to bypass these hierarchies. And in particular, one product/service Denise and I have looked at is a service used by a large company contemplating a merger with another company that the outside service used to survey the employees post questions and get feedback. The large company didn't like the results, so you haven't heard much about this, but it does exist, and we would like to use it.
Denise Michel: That's an interesting tool, but your point has been taken.
Vinton Cerf: Thank you very much. I actually hope, Esther, that we don't end up with parties in the sense of the highly factionalized environment.
Esther Dyson: We are attempting to make different voices coherent and produce better arguments that will lead to consensus because the compromise issues are clear.
Vinton Cerf: Andy?
Andy Mueller-Maguhn: I have the question if you could be a little more specific, even if this is still on your list of tasks to be worked out. Watching the amount of questions already answered by the blueprint, but also watching the amount of questions still being opened even if the blueprint like this gets implemented. And if or in what kind you could think the your organization you're forming could be part of one or the other committee, also watching the amount of board members coming out of the structure being proposed there.
Denise Michel: We've had some very constructive discussions over the course of this week with members of the evolutionary Evolution and Reform Committee. And there's a couple of different ways, I think, that actually, I'm sure there's many different ways. We've discussed two specific ways that at-large could be plugged into the blueprint. And we're still discussing sort of specifics and getting feedback. But we are very heartened by the acknowledgment of members of the committee that there is common ground here and the blueprint does provide real opportunities to structure and formalize at-large participation and representation.
I wouldn't presume to really speak any more for the committee. But, you know, we've posted specific recommendations, and it's something we're definitely going to pursue. I would take this opportunity, just as a personal note, I don't think that this nascent organizing effort will continue and survive unless there's a recognition on the part of ICANN and an incorporation in a more formal way of this type of structure. Really, the threshold is too high, the challenge is too great to simply have no formal mechanism for groups like this to plug in and to be a part of the process. Just telling them to go organize outside the organization, come up with some good ideas, and, you know, trust us, we'll listen to you, doesn't resonate with a lot of the organizations. And in order to build trust and to establish a much more professional organization and mechanisms that can contribute to ICANN, we need some more formal commitment on ICANN's end to
Vinton Cerf: Just before you start, Esther, just kind of a suggestion. We are going to have time to have more detailed discussion about the Evolution and Reform Committee's report and recommendations and time for some comment from everyone. So I'm going to try to suppress that part of the discussion until we get to it this afternoon. very short.
Esther Dyson: Very briefly, a lot of people have a lot of different opinions about the blueprint. But I'd note that the blueprint allows for the board to do something such as pass a resolution specifying criteria that it would designate an ALAC to meet. And we think we meet those criteria.
Vinton Cerf: Jamie, if this is not about Evolution and Reform, okay. Otherwise, I would but it off until later.
Jamie Love: I'd like to respond to the report. I'd just like to respond to the comments that denise made and esther made about the at-large proposal they just described, if that's appropriate now.
Vinton Cerf: Only if we don't get deep into the middle of the Evolution and Reform blueprint.
Jamie Love: Correct. I think the value in terms of you having a relationship with the general public is that this organization's asking for the confidence of the world community, governments, private businesses, consumers, people like that, in order to have an important resource, to tax that resource, to decide who can basically run different parts of it. And the relationship of, you know, their trust, the at-large thing is an issue about how you verify whether or not you're abusing that trust or doing it in a way that people like or don't like. I think the fact we're in romania today should remind us all that there's been periods in history where people have not respected freedom, and they've tried to manage public opinion and public dissent in a way which is not which has allowed people in power not to be accountable, and to do a lot of bad things.
So the problem we have with the structure is it's managed top-down. It separates the individuals from any kind of direct voice. It doesn't provide democratic institutions for polling instruments, not just polling instruments, but opportunities for people to do things like elect from the individuals. It creates a layer of selection as to who can do what. And if the point is to find out how the general public feels about things, you don't have to impose Denise and Esther on top of everything as some kind of management as to what people do. You have to give an opportunity within the structure, ordinary people to elect people that speak for them, and to express their views within the rest of the ICANN structure, without getting into the details of the specific proposals, most constituencies that don't involve just ordinary people have that. A handful of businesses can get together and declare that they represent the interest of all of the business users on earth. A handful of IP owners can do the same thing. ISPs, et cetera. So in areas where there's commercial interest, there's a perfect willingness within this group to accept the views of proxies or self-selected groups even those statistically, they're minuscule. But when it comes to individuals, there's panic when people who step forward as individuals to have a direct role, even if it doesn't involve controlling the board of directors or anything like that. So I'm opposed to this whole approach of
Vinton Cerf: And I I think, Jamie, we'll have to stop there, if we could. I'm concerned about time. There will be an opportunity to comment on this later on today during the public open microphone. Is that okay?
Jamie Love: Yes. The only thing I would add is that there is a group of 65 consumer groups that are trying to organize a meeting in September, 9th and 10th, in Geneva to talk about some of these ICANN-related policy issues. And we've invited I think maybe yourself and the staff of ICANN to attend and participate and engage in some of the discussion about this. This is a case where we kind of came up with this on our own and approached it. And if you really want to have outreach, people should participate in those kind of events.
Vinton Cerf: Thank you very much. I hope this is very brief, please.
Harold Feld: I just want to echo Denise's point that the trust-building is something that needs to happen. And media access project, which is my organization, advises non-profits in the United States on telecommunications policy issues. And I have to confess that at this point, if I got a call from some of our standard clients like consumers union or consumer federation of America, and they asked me, "So do you think we should participate in this?" I would really have to tell them, "Wait and see and see if this is going to be a genuine effort or if this is something that is going to be managed and a, you know, just a show."
So I would, on the one hand, say, number one, that Denise's comments are very important; but also, number two, that I would not rush to declare these efforts a success or failure based on the number of people who participate until there's some opportunity to see whether trust can be established.
Vinton Cerf: Thank you very much. And thank you, Denise.
Denise Michel: Thank you.
Vinton Cerf: We have three more reports. And what I would like to suggest before we bring those up is that to the extent that these reports touch on the Evolution and Reform Committee blueprint, that we withhold discussion and comment on that topic until we get to that topic this afternoon.
All right. So we now have Barbara Roseman speaking for the address supporting organization, assuming we can work out the technical side of getting things plugged together. Barbara.
Barbara Roseman: Okay. I'm Barbara Roseman, chair of the Address Council. this is actually a very brief presentation.
This is the current members of the Address Council, voted from the various regions. The ones with the star next to them were elected for the 2002 to 2005 period. Everyone else is on a staggered term, will be ending either this year or the following year. address council This year, we've observed progress in the establishment of LACNIC and AfriNIC as new RIRs. There's been regular participation by the representatives in all of the ASO activities. LACNIC is expected to become an operational RIR in November of this year. And they are making preparations to elect the ASOAC members at their first meeting following the ICANN approval of operational status. And, of course, they're doing this following the process outlined in the ASO MOU.
Discussion has been started to review RFC 2050, which for those of who you don't know, is sort of the overall policy on IP address allocation. And its current relation to active policy. So that there have been some divergences over the years between what we practically do and what 2050 outlines. The global mailing list for discussion has been established as RFC2050firstname.lastname@example.org. Anyone is welcome to join. Committees have been established to draft the initial versions of the documents and new drafts should be available for public comment by fall of this year.
For IPv6, the RIRs have established a common IPv6 policy. After considerable coordination of the various RIR working groups, an IPv6 policy was adopted by all of the RIRs to replace the interim policy. Policies under ongoing review as operational experience grows include criteria for initial allocations, and standard assignments for end user sites.
And I'm just going to put this up here. This is the brief statement that the ac made regarding ICANN Evolution and Reform. And our statement should be posted to the regular comments page later today. So that's all I have. Any questions?
Vinton Cerf: Yes, one. Helmut.
Helmut Schink: You mentioned that the ASO has developed an IPv6 policy. Do we have a chance to get a report on this to the ICANN board?
Barbara Roseman: We can send to the board the statement of what the policy is and what the process was used to arrive at it.
Vinton Cerf: Thank you. Are there any questions from the floor? I think there will be some considerable interest in the IPv6 policies as we go forward.
Barbara Roseman: Certainly.
Vinton Cerf: Thank you very much, Barbara.
Barbara Roseman: Thank you.
Vinton Cerf: The next report is from the protocol supporting organization. Azucena Hernandez will make that report.
Azucena Hernandez: That's it. Okay. My name is Azucena Hernandez. I work for telephonic (inaudible). I'm a member of the AC board. And I represented in the protocol supporting organization. I am going to give you the report of the activities of the supporting organization in the period from November 2001, because this is the last time reported to you in Los Angeles. Nobody from the PSO was I believe to attend the Accra meeting. So I'm going to first of all just for the sake of those who maybe come here for the first time, and merely the Romanian that is never have come to ICANN before, to talk just very generally on the mission and structure. Then the activities during these 10 months. Then what is the role that we consider the PSO have in ICANN and therefore the reform.
The PSO consensus is based in ICANN. It has a Protocol Council, and we were made members of the PSO in July '99. You have on the right the members of the Protocol Council. We have had a lot of changes during these 10 months. So myself, I am there since the beginning, but Mr. Kaijanen replaced by Mr. Jerry Lawrence. From the IETF, Geoff Huston and Mike Saint Johns. (inaudible) is there since the beginning as well, and Richard Hill replaced (inaudible). Finally, Martin Durst replaced and Daniel is there since the beginning. We have had a lot of changes since that time and a lot of new discussions with the new members in order to make them updated into the activities of the Protocol Council.
The duties of the Protocol Council are shown in this slide. And I must tell that they have been different there have been different interpretations from the different members of the PSO on what were their real duties of this body. And this different interpretation has led to show how some possibility from the outside that we were useless or doing something wrong. And I think it's because the MOU at the time it was drafted didn't show clearly what the community was expecting from us. I think we consider ourselves qualified to give advice, technical advice on many issues, because the standards-making activity is very wide in the organization that formed part of the PSO. But the way the MOU was drafted gave room for different interpretations. And that has led to some internal discussions that have gone to anywhere. But I think that we are now, you know, moving a little bit better into the future in order to be able to be more useful for the community. So we are elected, also, three of the members of the ICANN board. And the elections have gone well up to now. We hold our general assembly where all the community is invited to join us to know what we do.
So what have we been doing during these 10 months? We normally work by teleconference because we are all over the world in all four continents. And so we meet by teleconference eight times during these 10 months. We have come up with positions during this period, one regarding the alternative roots, in other words about the at-large. Both are available in the PSO web site. We have nominated one person for the ICANN international domain name committee, Mr. Laorden. We have received an application from the international standards organization to be a member of the PSO. This application is still under debate PSO Protocol Council. But we have already communicated to give a response in our next meeting, end of July. So from now on and also looking at the reform discussions, we will have to take the decision on whether to enlarge the PSO with another member or whether to remain more or less the same until the reform takes place.
We have our general assembly last week in Geneva on the 19th of June, kindly hosted by the ITU-T. We make it each one is one of the signatures. And the secretariat has been provided by the ITU-T. So how is the PSO viewing the ICANN reform?
We are highly interested. And our main interest came when we saw the first paper from Stuart Lynn. First point, the PSO must be killed. And we felt somehow shocked by that statement. And we started thinking why the perception from the community was that we were useless and killing us was a target.
But then, you know, reading carefully the details, we just understood the reasons behind that proposal. We have been followed very closely on the different papers that have been produced by the Evolution and Reform Committee. We have been talking with some of the members of that committee. And I think that now, despite the views of the four organizations were absolutely different from the beginning, we are now going to more common grounds of understanding. And I think that the future looks much better than it looked at the beginning. So each organization decided to post their different positions in their own web sites rather than trying to find a common ground. Because it looked quite impossible from the beginning. So if you are interested, you can see each of them. W3C for the time being is not available. So we will continue reacting.
We didn't have time, in fact, to react to the blueprint, because it came just two days after our general assembly, and therefore we have our own views, personal views, or different views on the different signatures. But we will react in paper, as we have done up to now, to that particular view. But let's see that the blueprint from the PSO point of view looks quite promising. In the part which refers to our area of expertise, let's say.
One of the three members of the board that we have the pleasure to have retired, Mr. Phil Davidson, a couple of months ago. So we have started a process for the election of a new board member, because for the time being, the PSO exists and therefore we have to fulfill our duties. So the call for nomination is already open. And I invite the community to look at the details. And if they feel qualified to represent the PSO in the board, please go and put your name on and the PSO Protocol Council will be pleased to look at your expertise and to select who we consider the best member of the committee.
We are very proud to have been electing Vint Cerf and Helmut Schink for occupying seats on the board and Vint being the chairman, not only the chairman, I guess it's as more remarked, being served together with two other pioneers of the Internet have been awarded with a very important prize, maybe not very important if it is in the world contest, but very important in the Spanish community. It is a prize which is somehow like the nobel award for the Spanish community, Spanish-speaking community. And we are 400 million in the world. So I really feel very proud of having Vint Cerf chairing the ICANN board, and Tim Berners-Lee on the PSO. So I feel like a little contribution to the PSO to world peace and communication which has been recognized by this prize.
So congratulations. Please pass these congratulations to the other three people, because I think you deserve them. (applause.)
Vinton Cerf: I'm sorry. Could I just say one thing. For those of you who are unfamiliar with this prize, it is a very, very distinguished award. And what is stunning many of my colleagues is that two other people are receiving this award at the same time as Bob Kahn, Mary Roberts, Tim Berners-Lee, and I. Woody Allen is one, and another is a playwright. We will be meeting in Spain in October. And all of us are looking forward to meeting those two world-famous characters.
Azucena Hernandez: It's going to be fun, I'm sure.
I'm going to mention very briefly a description of the four organizations that are members of the PSO in alphabetical order not to create any tension of who is better who is not better.
So the European telecommunications standards institute, the Internet Engineering Task Force. I assume that this one is quite well-known among the people here. The ITU-T, the International Telecommunications Union Standardization, and the Worldwide Consortium.
So just very briefly, ETSI has around 1,000 members from 54 countries, so truly international. Nearly 35 from the European countries and 19 from other countries all over the world. And I must give some example like US government is a member of ETSI even though we hold European as the first letter of our name.
We have 18 countries who are observers and we work in partnership with most of them. Our main amount of members, 53 percent, are manufacturers followed by service providers, administration, and very important users. We have 3% of user association of members in the same level as administration and so on. And the policy making from all different players is absolutely good.
Our engagement on IP, a list there of all the activities that we are doing on IP, next generation IP. Our IP multimedia system which is our concept for 3g capability, IP over cable and satellite, electronic signatures, different radio accesses to IP networks, meta protocols, and then the future IP core public safety network.
So we build our strategy on four blocks, more IP communication. We consider ourselves as leaders on that particular technology. And we see it, as you know the future of Internet with communication. We want to remain a driver in fixed networks. We want to target Internet involvement and bridge the fixed mobile Internet and broadcasting.
Our two major projects right now at the NGN, Next Generation Networks, and the 3G, Third Generation Mobile.
We look at the process absolutely from the beginning, the collection of requirements from users and from network operators are normally the ones who provide the final, the requirements. and then the architecture, then the protocols, and then we finalize with the (inaudible) profiles. With our complete marketing view end-to-end and then to go from end to end applications. We focus on some specific areas that are listed there, architecture, end-to-end quality of service, service platforms, network management, lawful interception, security, and naming and addressing so we try to cover the full part of it.
On third generation mobile, this is more or less the history since we started with GSM, up to the moment now.
We have just agreed on release 5 of the Third Generation Mobile which is the first one that includes what we calm the IMS, the IP-based multimedia services, a full mobile network with IP, IP architecture in it.
And we don't expect implementation yet, there may be still a couple of years to come but at least all the standardization is done and APB 6 is the protocol that has been chosen to offer better profiles for the mobility services.
ETSI, in our opinion, can offer many things to ICANN. It offers leadership in mobile aspects, which is essential in the short-term evolution of the Internet. We offer policy making expertise in making interoperability between existing telecom networks and IP networks. We offer competence on ENUM and security and so on. We offer capability to cooperate with different players. We are absolutely, we have identified 40 different players for our project, and we work with all of them. It takes time but at the end the process is much better. And we feel ourselves capable to really contribute positively in the understanding of different kind of communities like the administrations and the manufacturers, network operators industry in general. So we see ourselves, we see ETSI in ICANN, we see us in TAC if TAC is the final mobile that is going to be followed, and we also consider we can make a good contribution to the NomCom when it is finally set up.
ITU-T, all the governments in the world will have their member states and we have neither 700 sector members from the industry. They work with most of the SDO's including IETF and W3C. They are members of the worldwide standards corporation group that includes the ISO and IEC, they are an observer in the GSC, and they have now a new approval process, much faster than the previous one, and therefore they have overcome the criticism about how slow the ITU-T is.
ITU-T is a leader in most of the IRI can't say that are listed here, ENUM, multiprotocol and IP-based networks, e-commerce and e-business, and ITU-T supports whatever comes with the PSO. And they support policy making by governments.
W3C have 500 members, have centers in the USA, France and Japan and small offices in other countries all over the world. Tim is the director, well-known by the way, in Europe, talking about the region I was born. And this were the five domains, architecture, document forms, interaction, technology society and accessibility. There are main areas of expertise right now are those that are listed there, being the (inaudible) and web services are major projects they're accomplishing now to make the web more intelligent.
The major concerns regarding ICANN are listed there. The DNS have root of URI's to ensure that the decentralized evolution of technical protocols for the web, the use of URI for protocol identifiers and the integration of international domain names and URI's and IRI's. So this is how the standards board is seeing the IP world. It's not a matter of one, two or three bodies. It's a matter of a lot of players in the standards-making process.
I have put that in red, the four that ICANN identified from the beginning as being qualified to give technical advice on IP matters. But there are many more. I have put here those that were able to fit on the slide but I think there are about 40 more. I have no room to put them. So it's not a small world, it's not one body, it's not even two or three or four. It's nearly 40, and I think it's good that ICANN is aware that all these bodies can make a good contribution, technically speaking, to the work of ICANN.
Thank you very much. I invite you to visit PSO web site, it's very interesting, and if you have any questions I will be pleased to answer. (applause).
Vinton Cerf: I think one could not ask for a more charming and energetic presentation. Thank you very much. Are there any questions? One from Amadeu.
Amadeu Abril i Abril: Three very short things. First, you will be glad to know that according to the notes you are working not for telephonic but for California. Second, thanks for the advertising banner for ETSI. I was missing that since (inaudible) left this process. That was one of the traditions of the ICANN meetings. And third thing, well, nobody wants to (inaudible) the PSO. In your efforts of market the PSO organizations that provide the protocols, some of them are a part of that, some of them less, but for the process, for the things we take care about. So the transition between PSO and TAC, if that's the solution, will not undermine at anyway the regard we have for all these organizations. But just as a personal question, perhaps, seeing that perhaps this PSO disappears, I would like to see before it disappearing a recommendation to the board from the protocols council. Just one.
Azucena Hernandez: You are right. The standards board is going to keep working with or without ICANN. That's clear. This is business as usual for us. But what we consider is a pity is that we feel capable of being of help, and we consider that this offer should be accepted and welcome rather than the opposite. But I agree with you, I think it was a little bit of misunderstanding from the beginning and now we understand it was the meaning of the original sentence and I think it's quite clear in the new versions of the blueprint, for example.
Vinton Cerf: Thank you very much. Are there any questions from the floor? Apparently not. Thank you very much again.
Vinton Cerf: We now can hear from Philip Sheppard reporting the status of the domain name supporting organization.
Philip Sheppard: Chairman, thank you very much.
I shall endeavor to be as concise and brief as possible as I see we are running a little behind time. I want to report on some substantial progress on four key issues. This is the transfers, deletes, wait listing issue, on WHOIS and on reform.
On deletes and wait listing, you will have seen a status report has been posted to the board. This fit in with an external deadline there, with a comment period happening now on that. Final recommendations will be made by the task force, having listened to the comments, and we are hopeful of a rapid adoption by the Names Council over the summer of that and a final report will then be submitted with our recommendations on that.
Work on transfers was delayed a little because of the time line on the wait list and transfers will continue over time and we hope to have some results for Shanghai.
On WHOIS, there has been, I think, some highly commendable effort on behalf of the individuals involved on the WHOIS task force. They have done a substantial analysis of the WHOIS survey that was set up by this task force. The preliminary results of that are also posted. Comments are open, and the time line for final adoption is the same as the deletes and wait listing service. On dot org, two questions came out of the Names Council meeting yesterday, and I'll raise those now.
Firstly, we understand there was a possibility that the definitive board meeting to decide on the proposals for dot org may well be a telephone conference. If that is the case, we would request exceptionally that that telephone conference have available other lines for observers. And before that happens, we would also like to make the offer to remind the board and those involved in this evaluation process that the constituencies, all the constituencies, and particularly the user constituencies of the DNSO are highly engaged and highly interested in this topic. If there are questions about the evaluations that you wish to ask of those constituencies, we are very open and willing to respond to those.
And on reform, I know we're going to go into detail this afternoon. I'll reserve detailed comment for then. But perhaps I just wanted to share with you a little of the essence of some of the thinking that has evolved over a number of frequent meetings we've had on this issue, on the Names Council.
Number one, though, I think ICANN is simply not fundamentally flawed. The principles on today it rests are the right ones. Two weeks ago it was said bottom up, transparencies and I consensus building should continue to be the guiding principles 6 ICANN. We agree. We see gradual change. What has come out of our thinking is all change will be useless unless two conditions are first met. Unless ICANN is allowed the budget it needs, it will perform poorly. Unless that funding allows for staff support for policy development, policy development will be poor. Other changes, all the other changes we've all been discussing, will be insufficient to make a difference without action on these two enabling conditions of success. ICANN's only real failure was perhaps the quaint hope of its founders that it be somehow okay to set up a board with administrative support, but to leave the heart of its mission, the all-important policy questions, to someone else and then to offer them no help at all. Go off, self-organize and tell us when you've found the answer to simple questions such as ending (inaudible) in the world or introducing competition on a global scale in domain names. Funding is the key. The ICANN budget approval process should be independent of those who administer ICANN funding. We believe that core funding should ultimately derive from the revenues of gTLD registrants' fees and we support some of the conclusions that come out in the blueprint. That funding should provide full-time staff to support all aspects of policy making including a coordinating secretariat and staff support to policy making task forces that will make the new DNSO GNSO whatever, an instrument to external interested parties.
Policy development staff is the enabler of bottom-up consensus policy making. We believe there should continue to be four policy development bodies, gTLD, ccTLDs, addressing protocols and those bodies need self-determination. They should select their own steering councils and chairs. There needs to be better stakeholder interaction within the new gTLD policy development body and we believe the general assembly body should embrace though stakeholders uniquely and thus be the forum for broad consensus building, policy development staff will enable this. And what of those who are not stakeholders of the new gTLD policy body? They should be given new means of participation and development for e-mail based mechanism for the interested public. Policy development staff will enable this.
What is more, we believe that the policy development bodies should elect around half the board, and as for the rest of the board, around the same number or less could well be chosen by a selection committee comprising of providers users and the public interests. Add on your ICANN CEO, and we believe the board is complete and may number perhaps around 17. There should be no further role for a selection committee other than getting that very challenging job right.
As far as the Advisory Board is concerned, our top line conclusions there are the technical advisory committees are fine and should be organized according to need. These committees should liaise with the board to provide good communication, but should not provide board membership. To do so would limit the creation of future technical advisory committees. We believe governments should not, and we understand do not seek a voting board representation, and should be a better liaison between the GAC and liaison policies. And the policy staff shall develop that. advisory board How do these compare with the blueprint from the board's committee? We think pretty well and we hope given those refinements we're recommending to that blueprint we may well find we have all the fix that we need. Thank you very much for your attention.
Vinton Cerf: Thank you very much, Philip. (applause).
Vinton Cerf: I don't think we could ask for a more terse and lucid presentation. Are there any questions from the board? Are there any questions from the floor? Reminding everyone that we will discuss the reform matter later in the afternoon. Thank you very much, Philip.
Stuart Lynn: Mr. Chairman, the hotel has asked us to keep to the coffee breaks on time. It's now 10:00. I wonder whether we might defer both the next presentation and the budget presentation until after the break.
Vinton Cerf: Well, we might do so. I would remind you that the break was scheduled for I was asked to schedule it not at 10:00 but at 10:30. I understand that the schedule says 10:00 there; however, I was advised by Diane Schroeder that 10:30 was the preferred time. So I see Louis is nodding, so I think you should stand corrected, Mr. President. So there.
Vinton Cerf: I'd like to I'd like to call Marianne Wolfsgruber to give the report. Sorry, I ever the wrong name.
Nigel Roberts: Not at all, it's Nigel Roberts. Marianne was a little shy this morning. We were going to do it together, however I'm going to do it on my own. This is the communique of the meeting of the ccTLD managers which was issued late yesterday. Representatives of 57 ccTLDs managers met on the 24th and the 25th of June. Useful and constructive discussions were held on various subjects of interest to the managers, notably on the topic of ICANN reform and various concerns relating to the IANA function. The ccTLD managers recognize the hard work carried out by the committee on Evolution and Reform within the very short time scale allowed. We are please today see that a number of the concerns of the ccTLD community are being taken into account in the report of the committee, although they do appear to be a number of points on which the ccTLD managers do not agree with the conclusions of the committee.
However, bearing in mind the discussion earlier, that will be a topic for questions this afternoon. A response to the committee's blueprint which was published at the end of the next week was prepared during the two days of the ccTLD manager's meeting and this represents the initial views of those ccTLD managers present here in Bucharest. We do recommend that ICANN make sufficient time available so that all ccTLD managers worldwide are able to consider the details contained in this important proposal.
The managers also considered in detail the functions and the level of service that the ccTLD managers require from the IANA function, and have prepared a requirement specification which will be transmitted to the ICANN board as ICANN is the organization currently charged with operation of the IANA function. Four major bullet points in that requirement; that the IANA establish and follow differentiated processes for the different types of database update that can be made by ccTLD managers.
The point of this is to simplify and expedite the submission and processing of simple and routine requests. And all those who were present were in favor.
That the IANA should automatically process all requests to change the IANA database which have been properly requested by the ccTLD manager and which are not related to changing the ccTLD manager. All present were in favor of this point.
That the IANA and each ccTLD should agree an authentication method for changes to the IANA database. This means that it doesn't have to be the same authentication mechanism but one which is agreed between each ccTLD manager and IANA, and all present were in favor of this recommendation.
And finally, which touches also on stability and security, that the IANA institute and maintain a formal change control system so that all changes to the IANA database can be tracked, maintaining a comprehensive and accurate audit trail which is also available to the ccTLD managers. All present were in favor of this recommendation. So back to the text of the communique.
The ccTLD managers reiterate the urgent need, which was identified already at the special ICANN meeting on security and stability of the Internet naming system, in Marina del Rey back in November last year, for a procedure for making urgent or emergency technical changes. one of the problems that exists is that Marina del Rey is on Pacific time, and the rest of the world isn't. (laughter).
Nigel Roberts: The recent business failure of a major European telecommunications carrier which is used by a large number of ccTLD managers has underlined and reinforced this need, and it's highlighted the global stability risks which are inherent in the absence of such a procedure.
A number of the ccTLD managers have reported that ICANN had refused or delayed urgent technical changes for what was seen as procedural reasons, including a requirement for delivery to ICANN of the ccTLDs' technical databases. We regret the fact that the technical stability of the Internet was impacted as a result, and alternative methods of ameliorating the situation were found. The ccTLD managers present here in Bucharest unanimously reaffirmed their commitment to RFC 1591 as the sole guidance for the interaction between the ccTLDs and the IANA.
The ccTLD managers reconfirmed their commitment to funding the necessary IANA services, and in addition, committed to making a contribution for more general community services. this means we like coming to ICANN meetings.
A joint workshop was held with the Government Advisory Committee at which a number of matters of common interest to ccTLD managers and GAC members were discussed. It was agreed with the GAC that joint working groups would be created to deal with specific topics, including the principles on which the GAC and the ccTLD organization operate. The ccTLD managers especially wish to thank the chairman and the members of the Governmental Advisory Committee for the opportunity for these useful and very constructive discussions, and we look forward to increased cooperation in the future. government advisory committee A number of presentations on internationalized domain names were given to the ccTLD managers which were received with very great interest by all of those who were present there. issued in Bucharest yesterday evening. Any questions from the board?
Vinton Cerf: Andy?
Andy Mueller-Maguhn: I recall from the Marina del Rey meeting that the issue of IANA making that immediate emergent or however we call them automatic exchanges not touching change of the ccTLD manager was just technical changes, that we have a single point of failure here called the approval of the Department of Commerce of that changes. What about that issue? Because I'm very much in favor with your communique, but I don't see that problem solved.
Nigel Roberts: Well, thank you for the point. It's difficult to determine, shall we say, how to divide up between the IANA internal processes and the Department of Commerce in this. We are simply highlighting the systemic problem. We're looking at it as a black box, saying the security and stability of the Internet depends on an ability or not having such a single point of failure, if you like. And we are reiterating the fact that no progress has been made on this very important simple point.
Andy Mueller-Maguhn: So as a matter of fact, that is an issue to be resolved by this board.
Nigel Roberts: Well, as the ICANN board is currently responsible for the IANA function, I think it's something the board should consider and address.
Vinton Cerf: Whether it's completely resolveable by the board might be open to debate, but in any case, it's an issue that has to be addressed. So I'm not disagreeing with you.
Andy Mueller-Maguhn: It's a problem to be solved.
Vinton Cerf: Amadeu.
Amadeu Abril i Abril: Yes, thanks. Nigel, on the same line, this problem about technical changes and redelegations and the things like that are the most common thing that the ccTLD managers express to me from time to time. The problem is the lack of authorization of the different types of problems because there are different types of problems and probably different types of procedures we could adopt for solving that regarding name servers, technical context, different types of TLDs regarding the, perhaps, the relation they have contractually with ICANN at this moment or the relation they have being managed from the country, not being under a dispute of the administrative contract or not, et cetera. And perhaps I would like from the ccTLD community, if you are working on that, having somehow a table of the different situations with possible ways of improving, you know, the decision on these changes or these updates, if you understand what I mean.
Nigel Roberts: I do, indeed, Amadeu. Thank you very much for the point. This is, in fact, directly related to I think it was the first or second point in the full bullet points where we recommend that the IANA adopt differentiated processes for different parts of database changes. I can only speak now for .gg, but we have had some problems in simply changing our address several months after we move because the IANA wanted to know why we moved. the answer was, we had outgrown our previous offices.
In terms of the other ones you describe, I know the European ccTLDs, (inaudible) working group which has published some recommendations, and I was also part of that working group, which I think could be also useful. And I don't know if the IANA has a copy, but if it doesn't, we will make sure it does. So it's a good point. And we have been thinking on exactly the same lines.
Vinton Cerf: Thank you very much, Nigel. Are there any other questions from the floor? From the board? In that case, thank you again.
Nigel Roberts: Thank you very much.
Vinton Cerf: Particularly for those concrete suggestions. I'd like to call on Stuart Lynn now for the budget report. And, Stuart, if your concern is for coffee, you could do us all a favor by compressing this to a 15-minute report.
Stuart Lynn: You can be sure on my own behalf that you will have coffee at 10:30. Yes. (no audio.) The Microsoft Powerpoint has unexpectedly quit, not that Microsoft has unexpected quit. Good. Thank you.
This discussion is about the budget, the proposed for the year 2002-2003. Just to run over briefly what the budget development process is in ICANN, the proposed budget is proposed by me. It's developed with the advice of the Finance Committee and the budget advisory group. I'll mention who they are in a moment. Either separately or together, either by telephone or in person, those groups had several meetings. We also went through a process last December where, as usual, we ask for community input on the budget.
You know, we're always disappointed. We ask for it, but we receive precious little. And that's always a concern to us. But we always try and do the budget group and others try and determine what the wishes of the community are.
The preliminary budget was posted last March, March 30th. There were comments received. I'll talk about that later on. The proposed budget was posted may 15th. Comments were received there. I hope many of you have had time to look at it. And, again, it's the year 2002-2003.
Very briefly, these are the members of the two groups that advise us, the Finance Committee, chaired by Linda Wilson, and the budget advisory group that contains delegates from the four principal funding groups of ICANN, the ccTLDs, the name registries, the name registrars, gTLD registrars, and the address registers. And I'd like to thank all the individuals who devoted considerable time and thought during the process in providing some very valuable advice.
Some key points about the 2002-2003 budget it is a pre-reform budget. It doesn't incorporate any of the items that might come out of the reform process. It deals with the ongoing workload, with the mission of ICANN as it is perceived through the paper of what ICANN does, which seems to fit very well with the recommendations of the reform and evolution committee, but is work that we're doing today or are committed to do.
It is, however, intended to achieve some level of normalcy in the budget, namely some expansion so we can do the things that are expected of us in a reasonable and timely manner. It's intended, in fact, to bring funding in line with our current responsibilities. And that includes funding for newly authorized activities, including the security committee, as you just heard from Steve Crocker earlier.
It also recognizes inflation, a known cost increase, I mentioned earlier the increase in our insurance cost, for example, and continued attempt to build our reserves in a responsible fashion. So those are the drivers of the budget.
Some of the highlight priorities, one is to improve operations, IANA operations, technical services. You heard some of that from the ccTLDs just now. I want to, for no one, however, to be under any illusions about what's going on here. IANA works with a set of instructions from a set of policy documents. And those policy documents, it was mentioned by the ccTLDs, is RFC 1591, but also ICP 1, as has been approved by the board of directors of ICANN very early on. ICANN is not at liberty to change those instructions unilaterally. If changes are to occur, they need to follow the policy development process that ICANN has in place or has made change through the reform process.
Secondly, many of the things that go on in these services are out of ICANN's control. Not only the Department of Commerce, as was indicated in the last presentation, but also in the ccTLD community itself, where requests for information sometimes go unheeded for a long period of time as well.
So I think Nigel Roberts is absolutely correct, not only do we have a systemic problem that extends generally, but my personal view, as I've said to some of you on many several occasions, is that the policies that drive IANA, it's probably a good time to look at them again either to reaffirm them or to see whether they should be changed or to think of ways in which they can be updated to meet the changing world that we're in today.
So it isn't just a question of do what we say when we say it. It's a question of defining policies that can guide the work that IANA does. So we talk about services. We should really also be talking about policies.
Nevertheless, even within that framework, it's very important to us that we continue to improve whatever we can to make things better or more effective, such as, for example, in the failure that Nigel referred to of the that occurred in Europe, IANA was able to respond in dealing with the particular KPM Quest situation within two days and have things, name servers suitably located with the great cooperation of the ccTLD involved ccTLDs involved.
We also have to improve services to gTLD registries and registrars. We've expanded services, the number of gTLD registries. We haven't really effectively expanded staff to fit at the same pace. We need to provide support to the various committees that are being appointed by the board, the ICANN security committee for sure, the IDN committee will depend on what action the board takes tomorrow with respect to that.
We have certainly been requested that we improve the monitoring of agreements of all kinds. If you sign agreements, you should monitor them. And if you don't monitor them, why sign the agreements?
So to the extent that we have agreements which have provisions in them, we need to do a better job and be staffed sufficiently to monitor them than we can today.
We need to continue we've made big steps, but we need to continue to improve the security and robustness of ICANN's operations itself. Within the evaluation of the new gTLDs, we'll talk about that later. But out of the funding that came with the new gTLDs, there's about 300-plus thousand dollars left that we've earmarked to go as far as it can with the evaluation, although, as we'll indicate later on today, that may not be enough.
Provide temporary support to jump-start nascent self-forming at-large activities. You heard from Denise before. The budget itself doesn't actually do that. It says we'll spend 200,000 if the at-large community raises 200,000 itself. Personally, I find that a little unsatisfactory. That was in the preliminary budget. I feel that if we believe this activity is important to support in some way, that we ought to help it get started and continue the work that denise has been doing up-to-date. We're acting under the guidance of the board that it should be entirely self-funding and I want to acknowledge the work of Esther Dyson and others in helping to raise funding to date to help keep things going as far as possible. But one suggestion has come through this week which is not in the budget, is this board might want to consider earmarking some extra funds on a matching basis to help both stimulate the community and provide some support to the community.
And it's not in the budget, but you may want to think about that. We finance to negotiate ccTLD agreements in a very steady, slow but advancing pace. And we this will continue on in the future. And we need to strengthen internal operations, particularly, our financial systems need to be updated and strengthened. Also to include the opportunity for programmatic budget. Not included in the budget, one-time costs for reform and restructuring, continuing costs associated with reform, such as the in the blueprint, the ombudsman, the manager of what the working title of participation, and the other costs that may be associated with it. Other self-funding activities, for example, if the evaluation of new gTLDs is more than we have left, and it could easily be that, then that's not included.
The dot org bid process is self-funding. Any newer gTLD activity that may or may not be approved by the board would presumably be self-funding. So it doesn't have a budgetary impact.
If the security committee comes up with any recommendations that require work by ICANN, we're not funded to do that right now.
The funding for the DNSO secretariat, Phil Sheppard, gave a very strong statement in support of the need for funding for the various secretariats. The PSO funds its own secretariat. The ASO funds its own secretariat. The DNSO requested funding to support its secretariat. That is not included in the budget. There was very strong opposition by the people to provide the funding. And that includes three of the seven constituencies of the DNSO itself. Whether that's right or wrong, the decision of the that was made with the advice of the Finance Committee and others is that is a feature in the reform blueprint for reform. I personally happen to agree that there is a need for all our supporting organizations to be staffed appropriately, but the decision was to made to deal with that in the context of reform.
And if there's any increased levels of litigation, if people decide they want to bring lawsuits against us above and beyond what is recommended, that's not included in the budget. Let me move very fast now.
These are the positions that in the document online I won't go through it, of the what's currently the four positions that are budgeted but unfilled and the new staff additions. The budget itself is as follows. The first two columns you effectively saw in summary this morning. the budget and projection. What's proposed is in the third column. It's been posted online for several weeks. And I hope you've all had a chance to look at it. And I won't go through the details here. One thing that I would go through, however, is the funding model. That includes four components as far as the funding sources are concerned funding coming from those TLD registrars, registries, that are under agreements, that's allocated according to quarterly name counts. There's an amount that's budgeted that's distributed among all the various participants according to name counts. The address registries is according to a formula that we've grade. Fixed TLD registry fees are according to agreements that sign contracts.
Other registrar revenues come from accreditation fees, which I mentioned earlier this morning have grown quite substantially this year and is included on the budget based on trends and other factors. One change to the budget process I mentioned earlier today is that the way of approaching voluntary contributions from ccTLDs has changed. Instead of our going through every year and putting a big sum in there we know we're not going to get and then making it look as though either we or the ccTLDs have not stepped up to the mark, these are voluntary contributions. No one has to contribute it. They contribute exactly how much they want. And so what we've decided to do this year, with the advice of the both the budget group and the Finance Committee, is to put in a more realistic amount based on historical trends. And to take the uncertainty out of the budget process.
What's happened in the past as we go into the budget year, we don't know whether we're going to get it or not. We can't hire the staff up to the authorized levels. And we get ourselves caught in a Catch-22 of not being able to deliver the goods we'd like to.
With the advice of the groups I mentioned, the gTLD registries and registrars advised us to create a budget that basically they would provide the core funding, and that any extra funding would deal with things that are more discretionary, funding that's not unknown.
So now we base it on historical performance, not on arbitrary formulas that we know aren't going to be filled.
The budget to require to be approved requires approval by two-thirds of all gTLD registrars for that portion of the budget dealing with the variable gTLD portion. Normally we do this after this particular meeting. We've been trying to do it in advance. So far, 36 have approved. VeriSign registrar, that's NSI is not yet approved. If they do approve, it'll be a set figure of 78%, which will be more than enough.
I might mention that the agreements with VeriSign require them to approve this budget, provided it's within certain limits, and this budget is. And their approving this budget is a condition of their renewal of their accreditation.
Comments received on the web. We always receive posted comments. 73 comments received. 72 of them were spam. Which is either an advance or decline from being off topic, depending on how you want to look at it. One was on target, recommending subsidized and UDRP filings for low-income people and senior citizens. We've not included that, because we don't have a policy under which we can do that. But, nevertheless, I did want to bring it to your attention. so thank you very much. You've got a choice now of coffee or questions. And I'll leave that choice to you.
Vinton Cerf: Thank you very much, Mr. President. Are there any questions from the board? Jamie.
Jamie Love: I have a question about the transparency issues about the budget. ICANN is being sued right now by one of its directors because he can't examine the books of the company. And we'd like to know how much money is it costing ICANN for the litigation to prevent your own board member from looking at your books. And can you actually explain to the public why it is that you are not allowing your board members to see whatever they want in your books. Thank you.
Stuart Lynn: I'm so glad you asked that question, Jamie. Because it helps to clear up the common misconception that this lawsuit has provoked.
Any director of ICANN can look at the books of ICANN. And, in fact, the directors of ICANN or ex-director of ICANN looked at exactly the information that the particular director in mind has has in mind. This is not about access to ICANN's books by a director; this lawsuit is about whether a given director can set policy over and above the portal as a whole.
Jamie Love: The other part of my question is how much
Stuart Lynn: I can't give you a figure because it's an ongoing situation and we're not in a position to disclose that.
Jamie Love: When you say you're not in a position to disclose. You can't tell us how much you're spending on the litigation at any point? Is that like a state secret or something like that? Is there some member of the board that can find that out and tell us? That's a legitimate question for someone to ask, because this group is proposing a 25-cent per domain tax. And as a taxpayer
Stuart Lynn: It is not proposing a 25-cent per domain name tax. That's rhetoric.
Vinton Cerf: Could I make a suggestion. I see we have a long queue of people. We've been asked specifically by the hotel to have breaks at the times that were scheduled. What I'd like to suggest is that we continue this open discussion either after the break or during the public part of our open activity. But I would like to actually call for the coffee break now, not to stop this discussion, absolutely, but only to stay in schedule with the hotel's ability to support us. So when we return after the break in half an hour, we'll continue this part of our questions. Okay? Half an hour.
Vinton Cerf: Hello? I'd like to reconvene this meeting. I'm missing some directors. And we're missing a considerable number of people from the floor. I think what I if you go out there and tell people we're restarting, that would be helpful.
Ladies and gentlemen, I'd like to call this meeting back to order, please. So if you'd kindly take your seats.
We left off at the point where there were some questions for Stuart Lynn. In view of the delay, my inability to keep us on schedule, I'm going to suggest the following we will spend no more than 10 minutes on questions for Stuart at this time. And so whenever we get to 10 minutes, we will stop. And any additional questions we will put into the public comment open microphone period. I apologize for that, but it seems the only way we can try to get everything done. I'll try to stay on schedule thereafter. So, Stuart, we now have some open questions. And we'll invite the first one. Could we please close the doors so that we can have quiet. It's going to be difficult. Just speak up and we'll do the best we can.
Steven Metalitz: Thank you, I'm Steven Metalitz with the intellectual property constituency. I just wanted to note, there's been a lot of discussion at this meeting, and will be more, about how ICANN can best represent the interests of domain name registrants at large and Internet users at large. And I would suggest that the most immediate concrete step that the board can take to do that is to allocate resources to the monitoring and enforcement of the agreements that ICANN has entered into with registrars and registries. Those agreements have some very important provisions that are really for the benefit of domain name registrants at large and Internet users at large. And the best way to advance the at-large interests would be to enforce those agreements, which is not happening now. I would encourage the board as they review this budget to stress the importance of this monitoring and enforcement capability. Thank you.
Vinton Cerf: Thank you, Steve. Phil.
Philip Sheppard: First, as Names Council chairman representing the DNSO, I would like to formally express our disappointment at the fact that our request for modest funding for the secretariat did not go ahead. We understand there was greater hope for the future.
Speaking also now in my capacity as a representative of the business constituency commercial users, I'd like to express perhaps also a hope for reform in the future in the nature of the Budgetary Advisory Group. We have said many times at this microphone before that we believe funding for ICANN ultimately comes from registrants, users, it is administered by suppliers. If there is to be a budget advisory group in the future, we believe that should also have user representation. And this may help a situation in terms of certainly the independence of ICANN, certainly also help in things like perhaps contract enforcement that does not force ICANN into the role of a Dickensian petitioner, seeking funds from someone. Thank you.
Stuart Lynn: I can make one comment on that. I think it's an excellent suggestion. I think like a lot of things we're looking at anew, that's a thing that needs to be looked at anew as well. I mentioned that during the budget process, we did ask for advice from the various constituencies, and the Names Council was good enough to forward that request that was unfortunately not forthcoming. But it would also be helpful, whether constituencies are involved or not on the budget process, on the budget group, advisory group, to take advantage of the postings of the preliminary budget, of the budget that came in may 15th. It's a source of some concern to me that we don't get the comments on the budget except until people come to these meetings. It would be really very useful if it happened from the posted documents, too.
Philip Sheppard: And it's not too late to do so?
Stuart Lynn: It probably will be too late to do so now. And I know
Philip Sheppard: For the future.
Stuart Lynn: the Names Council was preoccupied with a lot of work on reform, which we appreciate. I'm not saying it's not the Names Council, but all constituencies. We really do value that feedback and the comments. And you don't have to be on the budget group to give those comments.
Vinton Cerf: If I could delay just one moment. Jonathan.
Jonathan Cohen: Yeah, sorry. I just wanted to actually support Phil Sheppard and the DNSO, GNSO. I must say Stuart's point is well taken. We have to be able to find the money. And without the money, you can't do it. But I must say, I really strongly think that if we're going to have a policy development arm, that we have to find a way to get them the kind of support that's necessary to get the job done. And until we've tried that, I don't think it's reasonable to discard the process.
Vinton Cerf: Thank you very much.
Sabine Dolderer: My name is Sabine Dolderer. I'm the ccTLD manager of .de. Actually, it has a little bit to do with the budget, because when you're talking about the budget, you're talking about the (inaudible) problem and that it will be solved in two days. But that's only one side of the matter. And, actually, it was solved one it will solve one problem of numerous problems. And this was not solved by ICANN, but it was actually solved by the RIPE NCC and a lot of technical people in Europe. But the underlying problem that we need, first change the root server on a technical level was actually not solved and is still not solved as we have the KPM Quest name server dot de. And it isn't actually, we don't request a change yet. But at the moment, we have problems with the process. And the ENIC has contributed the last three years to the ICANN budget quite a lot. And we don't we have no strings attached, actually, to our donations. And I want to ask you, do you want to make technical investment changes with strings attached to the future or do you actually do it in the same good faith we are doing it, with no strings attached. That's one.
And secondly is, I want to urge, actually, to allocate more money in the budget to the IANA function and to go ahead with defining processes which fits our technical needs.
Stuart Lynn: Thank you, Sabine. And let me say at the beginning that we very much appreciate the generous contributions this year and last year. We continue to want to work with you to improve all processes that come through. I'm a little puzzled, because I heard you say there was an urgent change that hasn't yet been submitted.
Sabine Dolderer: Actually, our problem is still we have to find a server, locate it somewhere in the network, because we can't rely upon voluntary servers somewhere popping up. Because we really need to settle down the infrastructure. But our infrastructure at the moment is strong enough to actually live with actually, if it would be possible, I would send in a request, please delete the KPM Quest server. Then I will arrange technical settlements for a new request saying I have settled up with a new name server. This works perfectly as long as I have a turnaround time for say at least one day of the changes. But at the moment, every change takes me up to three weeks. And therefore I just wait to make these two changes together in one. But the technical best solution I agree should be to delete the name server first, next, we set up a new environment. That is the new one.
Stuart Lynn: Well, look, you're covering a lot of ground there, a lot of which I don't have the information on the details. Let's get together, see what needs to be done. What I do know is on the KPM Quest situation, we did those name server changes very, very rapidly. If there are some things left over that still need to be done, let's get together and talk about them.
Sabine Dolderer: There are still some pending, as far as I know.
Stuart Lynn: Let's talk about them, if there are.
Vinton Cerf: Okay. It's now 13 minutes after the hour. I think that I need to end this part of the open discussion. I apologize
Stuart Lynn: Maybe let one more speaker.
Vinton Cerf: One more? All right. All of you who have lined up, we will make sure you get to speak during the public open microphone time, but I need to get this schedule
Michael Palage: Michael Palage I'm the chair of the registrar constituency. the registrar constituency has been supportive of the ICANN institution since its inception and we supported it financially.
Most recently, we are on the verge of approving a 30% increase in the context of the registrars. Right now there is about an eight cents per domain name licensing fee which is going to be increased to approximately 12%. Again, this is a 30% increase, and the registrars as a whole have been supportive of this. One of the things that we'd like to do is clear up the conception that we are some fee taker. We have a contractual relationship with ICANN, and it's important to understand this contract. If you take a mid-size registrar with 100,000 domain names under management, we provide domain name services not on a yearly basis, but for an extended period of time. Using a mid-size registrar with 100,000 domain names under management for three years, this 3 cent increase represents a $51,000 increase. This is a cost that registrars are unable to recollect, or recoup, because we've already taken the money from registrants. Not only that, but under the current process where a registrant chooses to take his name and transfer it to another registrar because they do not like the service they are getting, that registrar does not recognize any revenue. If a person has five years left on a domain name and they go from registrar a to registrar b, registrar a collected all the money but registrar b, under the current contract, is required to pay the financial contribution. So again, registrars are supportive, we've been supportive, we've paid our DNSO fees from '99. We've not missed a payment. We've approved the budget time and time again. We've met our financial contributions. Please do not view us as fee takers. We are a partner with ICANN. Thank you.
Vinton Cerf: Thank you. May I suggest that the three people who we didn't have time for right now put your names on this list. We will put you first in the open microphone session.
Vinton Cerf: Okay. I'd like to call on Dan Halloran now to tell us about the grace and redemption proposal, which sounds vaguely religious.
Dan Halloran: Sorry about that, but my dad is a Catholic priest, so there must be...
Vinton Cerf: So there will be a litany, and should we have the scensors come?
Dan Halloran: I'll try to catch up on some time here and go through my slides as quickly as possible.
We're coming back to this topic we talked about in Accra. ICANN receives a large number of complaints about inadvertently deleted domain names. In February of 2002 we posted a proposal for a redemption grace period for deleted names and at the meeting in Accra the board requested authorized Stuart to have a technical steering group for an implementation plan. The technical steering group had six very well qualified technical personnel from registries and registrars. We had Register.com, Neulevel, Verisign, Afilias, Melbourne. It represented the group proposed to implement the grace period process in a two stage process, first to implement right away a safety net to catch these deleted names before they get snapped up by a third party.
The first stage will create the safety net, the second stage is to implement the registrar transfer of deleted names so they can pick which registrar will redeem the name. The safety net will extend the delete pending period which is a 30-day registry hold period. After every name is deleted by the registrar, instead of dumping it right back in at the registry level, it will be kept on hold 30 days, still in the registry database but the name won't resolve so e-mail won't work and they should give registrants notice there is a problem and the name has been deleted. Registries will implement a new restore capability, depending on the registry it will up to them to chews the implementation. They can ask for the names to be restored or undeleted. This is kind of technical, the effects of a restore operation. A lot of these details are in the concrete proposal, so I'll just skip some of this stuff. The proposals are on the web site. The interaction with other grace periods. The main change will be in many cases now, domains that are deleted immediately go back and become available for re-registration. This will change those grace period provisions and make these names subject to the delete pending period. The one exception will be domains deleted within the first five days after initial registration will be exempted, the redemption grace period won't apply to those names and that's mainly to prevent opportunities for gaming or abuse where a registrar could register a million names, delete them a next day and have a free 30-day option on those names, effectively. There will be both registry and registrar transparency requirements in implementing this proposal.
Registries will provide information about deleted names through their WHOIS service. And this is an example of the sort of information they'd have, if you did a WHOIS lookup on a deleted name you would see when it was deleted, the fact it's in a delete pending period and also registries will provide lists to registrars of names that have been deleted and have gone through the 30 day period and will be available for re-registration and this will give all registrars an equal chance to and all registrants an equal chance to go after those names. Registrars also have transparency requirements. The idea is that registrars will only be able to redeem names for the original registrant, not to take it back for themselves or sell it to some third party. So every time they do a redemption, they're going to have to submit a previous report explaining the circumstances just to create a paper trail so it can be audited later to make sure they it was done properly.
The proposal any new these will be new registry services, this restore capability, and any time a registry under ICANN contract wants to charge for its services it needs ICANN's consent. Any fee would be based on their costs including for implementation and monitoring. we put up the proposal has been up on the web site for about three or four weeks, the technical steering group's proposal.
Dan Halloran: There were several substantive comments, a request for diagrams or transition matrices which we didn't have time to implement unfortunately, a request for accounting, how this would impact staff resources, which again we didn't have the time to handle in detail. There was also another question. It's not spelled out in detail, what registry hold means exactly in the technical steering group's proposal but it does, in fact, mean these names won't be in the zone file, they won't resolve, no web site web site won't work, no e-mail. And we had one suggestion and there have been other talks on other lists that even 30 days isn't long enough, should be three months or six months. I heard recently there should be a cooling off period for a year, maybe, or something. I think Stuart has ideas about that, too. there's widespread community support for this idea. It's kind of rare at ICANN meetings, but it seems like almost everybody agrees this is a good idea, including lots of the DNSO constituencies discussed it and had support for it, and if there's they might want to come up and say that's true or submit statements on it, in fact.
I want to thank again the members of the technical steering group who did excellent work. It was really a pleasure to work with them all. A couple of them are here, Bruce T. And Ram Mohan and Jordyn Buchanan are here, and thank you very much. And I know it's hard to ask them to take time out of their busy schedules but they participated in calls, read drafts and they were great to work with. Thank you. And that's the conclusion. Bruce and Ram and Jordyn are here if there are any questions from the board about the proposal.
Vinton Cerf: Okay. Are there any questions coming from the board? Amadeu?
Amadeu Abril i Abril: Well, thanks, Dan. I also really think this is a very good idea and was much needed indeed. But just one question. Could you explain how can you hear me? Could you explain the whole picture of what happens between renewal and deletion right now? So how this relates with the 45 days we already had for, you know, deletion and now this 30 days for redemption period, how the whole picture works?
Dan Halloran: The way it works right now, say a person registers a name for two years, and the first day after the second year that name technically is expired. The registry auto-renews the name and the registrar has 45 days after expiration within which to delete the name. If they do it within 45 days they get a refund of their registration, of the $6 registry fee or whatever it is, and right now the name goes right back into the pool to be re-registered. Under this proposal, the same thing would happen but it wouldn't go become available right away. there would be another 30 days plus actually another five day notice period at the end of that. Does that answer?
Amadeu Abril i Abril: Yes. And the 30 days, would always be the name on hold that is not resolving?
Dan Halloran: Correct.
Vinton Cerf: I see we have one question from the floor.
Harold Feld: Yes. My name is Harold Feld. First I do want to echo tremendous support for redemption grace period. This is an issue which profoundly affects a number of noncommercial users from very large users to the smaller users. My one concern is just to make sure that the scheme be properly understood which he it is implemented. One of the problems for all of us, and this may be more of a registrar problem, but registrars are very good at making it easy to register domain names. It is more difficult to, sometimes, get up front the information on what it is that you're getting, what's available to you. There's CR service agreement, click here, and there's this really long thing. On issues like redemption grace, which people are going to be in a panic when they are going to want to implement this, and most of them are not going to be sophisticated users who are going to be frantically calling and saying "What do you mean my domain name isn't working? What's going on?" It has to be a simple explanation, it has to be user-friendly, and it really has to be communicated directly to the registrants And again, this may be more of a registrar issue. But it's really important that how this program is going to work be understood and that people be told multiple times with the understanding that a bunch of people who are going to need this are going to ignore the notices until they're in a panic and desperately need the services.
Vinton Cerf: Thank you very much.
Dan Halloran: Harold as a priority we'll try to get up an FAQ for registrants about this. We have FAQ that we try to put on InterNIC.net.
Vinton Cerf: Just a reminder to stay brief.
J. Scott Evans: My name is J. Scott Evans and I want to step forward and express to the board our endorsement of this point of impact. We think it's an excellent idea both for noncommercial and commercial users. With regard to Harold's point about information circulation, that is something we all in ICANN, I think, face every day is getting the message to our constituents and to stakeholders. And I would suggest if you could turnkey this and just provide registrars with a package that they can then upload onto their system that would be simple and get the message across would perhaps be effective. And we also would like to say that we think the redemption grace period should be a priority before we consider the next topic, which is on your agenda which is the WLS. We think that you need to get this in place before the WLS is implemented, whatever decision you choose to make on that particular issue. Thank you.
Vinton Cerf: Thank you very much. Marilyn.
Marilyn Cade: My name is Marilyn Cade. We are addressing transfers, deletions. A member of our task force has prepared a short briefing which he will e-mail to the board. We call it a day in the life of the dot, and it has a powerpoint presentation which will take you through the various stages. I think it would be helpful to you and we'll make it available to Dan as well. Let me just say that on behalf of the task force, the redemption grace period has very strong support.
Vinton Cerf: Thank you very much, Marilyn.
Robert Hall: My name is Robert Hall, I'm a registrar. I want to make sure we carve out one exception, it's been discussed our constituency meeting. The initial five-day registrars have an initial five day period after a domain is registered to delete it. I would hate to see this great period apply to that five-day period. What happens someone can come, register a domain, we see an increase in fraud with credit cards. The registrar deletes the domain after a day or two and it's held up for 35 days. This would allow people to take domains out of circulation for long periods of time just by re-registering them every 35 days. So I think the five day initial grace period this should not apply to. It's meant for consumer mistakes. So I would hate to see this tie domain names tied up and take it out of circulation. So I would ask there be an exemption for the five day period after their initial registration.
Vinton Cerf: We'll have to sort through whether that proposal leads to any gaming of the system. I understand your point about gaming in one direction. I hope it doesn't get gamed in the other. I think we need to think through that.
Robert Hall: It already has.
Vinton Cerf: Okay. Are there any other comments? No? Thank you very much, Dan.
Dan Halloran: Thank you.
Vinton Cerf: I sense there's considerable support for this proposal. Let's see, I call upon Stuart Lynn now to bring us up-to-date on the unpronounceable acronym of the new TLD Evaluation Process Planning Task Force report.
Audience member: I have a short announcement, someone, Mr. Michael Hiller, lost a card. If he's in the room, please does anyone know Mr. Michael Hiller? He lost a credit card. I think could be
Vinton Cerf: Is that a....
Audience member: Okay.
Vinton Cerf: If it was a credit card that could deal with $30 billion, I'd be very interested in it. (laughter).
Stuart Lynn: Thank you. I promise this is the last time you're going to hear from me today.
Audience member: No.
Stuart Lynn: Did I hear someone say thank God? This is the report of the New TLD Evaluation Process Planning Task Force, which you will recall from previous meetings is known as NTEPPTF.
The draft final report of the committee was posted a week or two ago, and is here for discussion at the public forum, but no action by the board today to allow for 30-day comment period. I won't go through the details but the board appointed this task force last year, and asked the task force to come up with a plan for monitoring the new introduction of new TLDs and for evaluating their performance, focusing on technical business and legal perspectives, and has been mentioned in previous interim reports, we have added to that, those three process perspectives as well.
I want to acknowledge the committee and thank the committee, or task force as it's called. It's been an excellent task force with great contributions and participation from everyone involved, and it's been a lot of fun. And at least it has for me. I hope it has for members of the task force, too.
The interim report was posted in December. I made a presentation in Accra about where we were, we were a little behind schedule, and this indicated a draft final report. So let me emphasize, it's not the final report. We welcome comments until July 15th when the comment period will close. Then the task force will meet, consider the comments that have come in, and submit its final report in late July to the board. And with that, the work of this task force will be complete. As I just mentioned, there's no board action at this meeting, but this is the last opportunity until Shanghai that we would have the opportunity to present it in a public forum. It's a long report with a lot of conclusions and a lot of meat in it. It's not exactly intended to stimulate the imagination, something that you enjoy reading as your bedtime reading, but nevertheless, I would urge you to read it because we do value the feedback that you get because it's a complex question.
We have posed a number of questions. In our draft report we'd indicated what they might be based on feedback and input from the new gTLD staff. We refined those questions. We talked about early in the interim report coming up with a criteria for how to address those questions. We found that was much more difficult and not practical, because most of them were dealing with questions where it's not easy to establish criteria because there was no history on how to establish those criteria. This was the first time. So what we chose instead in a very lengthy appendix to the report was to provide commentary on each question, give guidance to to an evaluation team on what they might consider and how they might approach answering the questions.
And again, we'd appreciate your comments on those comments, not just on the body of the report itself.
What is clear, became clearer and clearer from our work, is that a complete evaluation, even within the constraints that the task force put on itself and put on by the board only to focus on the most important material, a complete evaluation is going to be a formidable undertaking. formidable in terms of the resources it's going to consume. I mentioned during the budget process that the resources that we have available left about $350,000. That's assuming that's all that it needs to be used for. And there's going to be some serious limitations on how far that funding is going to go in an evaluation. And also, formidable in terms of the time it's going to take, people time and so forth.
So as a result, even within the questions that it posed, the task force tried to establish what it thought were the critical priorities that have to be dealt with rather than in case there's not funding or time to deal with all the questions that may still be important but not vital. It will also take time, perhaps as much as a year, before an evaluation would be complete, even focusing on the critical priorities.
And so the report has a lengthy discussion of the extent to which the board may want to consider parallel processing; that is, to proceed forward in certain ways even before the evaluation is complete, maybe when it's partially complete. And the report sort of tries to weigh what the opportunities are for doing that versus the risks of doing it. That is a subject for the board and the community to consider. It lays out priorities, as I mentioned. It suggests evaluation methodologies, suggests a proposes a schedule and various alternatives and a final set of recommendations. Those recommendations, in summary, are to recommend to the board should initiate an evaluation to address what the report considers the most critical questions. And also to implement a monitoring program as is defined and outlined in the report. It also recommends to the board that it adopt a certain methodology for continuing the evaluation, including the appointment of a TLD, new TLD evaluation advisory committee to provide oversight to the evaluation process.
The NTEPPTF wants to say that the members either individually or as a group stand willing to help in any way that the board and the community wishes it to do so. It recommends that the evaluation proceed according to recommended schedule to be completed no later than June 2003. I want to make it clear that that schedule is very tenuous. If it requires a lot of interaction and approval, going back and forth with the community at every step, then it's going to take a whole lot longer than that. This evaluation schedule says that largely it is staff driven but with the oversight provided by an evaluation committee. But if we get into a lot of process, then you can stretch out even further. The task force recommends that the remaining $350,000 or so in the new gTLD funds be budgeted for this purpose. There will still be questions. We have not done an assessment of how far those funds will go. We're assuming that between if the board wishes, that one of the first things to be done is to approve a budget and to look at the tradeoff between priorities, what needs to be done and what can be done with the funds available. but we don't give any opinion on just how far that will go. And the task force recommends that the board consider to what degree it wishes to engage or not engage in in some degree of parallel processing, trading off some of the risks and opportunities that are mentioned in the report.
So I've given you a summary of the report. There's much more detail in the report itself, of course. But I welcome any questions or comments that you might have.
Vinton Cerf: Okay. Let me first start by asking if there are questions coming from the board. Are there any questions oh, Amadeu. I should remember, always a question from Amadeu.
Amadeu Abril i Abril: This is the first time I have a question today. Stuart, one thing, is the main goal of the evaluation task force to see to evaluate how it work or to see, first of all, the main problems that could we'll learn for future introductions or types of introductions of TLDs? That is, is there somehow a positive evaluation or negative would work, how is it working, or what has not worked and should be taken into account?
Stuart Lynn: I don't think it's what has worked or not worked, but what questions we need to ask, what do we learn from the process to guide us in future decisions about new TLDs in the future. So it's more the positive of what you have in mind rather than the negative.
Vinton Cerf: Thank you. Are there any other questions? Jamie. Brief and to the point.
Jamie Love: Yes, Thank you. I was recommended by my own constituency to be part of this task force but I was not included in it. One idea that we wanted I would have thrown out on the new TLD task force, among other things, is that a special thing for the ccTLDs, the ccTLDs are confronted with these problems of governments coming in who want to basically nationalize or take over their basic two-digit country level thing and they're upset about the sort of sovereignty issue. And on the other hand you have businesses who have technical expertise and they know how to do things. We find it to be quite helpful if you allocate all the existing ccTLDs strengths, maybe three or four apiece so they can begin to develop other businesses which would not be faced with the same kind of political pressure that the two-digit country does because there are already people in the root, they already know they're not destabilized in the Internet, they have all these reasons to expect that they are competent and know how to do things and are already basically in the business already. It would serve the idea of expanding and creating more competition and it would be regionally good because you'd get operators all over the world essentially being able to compete with the American gTLD operators, if you let them start with nine dictionary names and did a first come first served thing, you could expand the name space and help them resolve some of their political fears that they'll be overrun by the .za kind of problem and stuff.
Vinton Cerf: That's an interesting idea. Next question.
Vinton Cerf: The next question?
Patrick Murphy: Good morning. Patrick Murphy. I represent IATA, which is one of the sponsors of dot travel in November 2000 and has been waiting for this evaluation process to move as rapidly as possible so that we can get to some conclusions on the next round. Chairman and board, the report itself has two particular aspects that I want to bring to your attention. Within the report, it talks about what Stuart has talked about, consideration be given to initiating another round in parallel with the evaluation process. But the recommendation is a bit more "fudgey", because it only talks about a process of initiating activity to start the process. Chairman, since the last meeting since the turndown of the appointment of 7 TLDs, we did a lot of work, and I know other bodies did the same. We now have a travel partnership. We now have an organization representing 2.1 million organizations involved in travel and tourism who are looking forward to find space within the Internet.
I'm going to have to report that this evaluation process is going a long, long way. So I'm putting an appeal out to the board to take that point in the report about consideration of going back to where we were with the original applicants and maybe moving it a bit faster. Thank you.
Vinton Cerf: Thank you.
Ken Fockler: Thank you. My name is Ken Fockler. I'm actually probably giving the same message that the previous speaker did. I thank the committee for its work. I note the paragraph on a possible parallel process and the recommendation that the community and the board consider it, which I think is appropriate.
However, I'd like you to find some ways to communicate the results of the consideration so that various people such as the previous speaker and others have a way of trying to plan their futures and how much they should get involved, and just clarify possible time lines. Thank you.
Vinton Cerf: Just an administrative note. If my clock is correct, we are now into a period where we had promised the hotel we would break for lunch. So I will take the next two questions and after that there will be no more. We will reconvene at ten minutes after 1:00. So, please.
Harold Feld: I will make this quick. I just wish to echo that we, as the constituency, were disappointed that Jamie was not permitted to take Y.J.'s place when she stepped down in Accra. And I understand that Stuart regarded this as a well, he had his reasons. But I would hope that in the future when the constituencies expressed a preference to replace one representative with another on an ICANN task force, particularly one of this importance, that that decision of the constituency is respected.
Stuart Lynn: I just want to comment briefly on that. This is not a task force of representatives. It was a task force where the Names Council was asked, not the constituencies, the Names Council, was asked to give suggestions on who should be members of the task force. They did. They did a wonderful job. In fact, did such a wonderful job, although we were looking for sort of smaller task force, we accepted I accepted every one of their suggestions. But these, once they were appointed, were members of the task force. They were not representatives of any constituency. And Y.J. in fact did not resign.
Jason Hendeles: Hi. I wanted to express my concerns about the delays in the new TLD evaluation and implementation process and also wanted to suggest that it's possible that there are ways that the new TLD groups, the different the different people that are involved in this process would be more than willing to participate in both funding and the evaluation process. And if that's something that the board could start to explore, I'm sure that the new TLD applicants could assist in that aspect and possibly push the process a lot faster.
Stuart Lynn: Well, that's a very welcome comment, because certainly the report indicates in many places that the number of questions cannot be answered without the collaboration and cooperation of the new gTLD registries. So we'd certainly take up any suggestion.
But let me just, if I might, focus on one word, "delay." Delay from what? There was no established real time schedule. And, in fact, it's not possible to evaluate something that hasn't really started. So it may have taken longer than a lot of us would have wished, but we're still on track. We offer to help move it the offer to help move it forward is greatly appreciated.
Jason Hendeles: I agree there wasn't a set path, but to some degree there was a pattern set in place by the whole registration process. And when the registrars became alive, there was a group of five registrars that are given registrar status. And then almost immediately, within a you know, several months, there was a large group of other registrars that followed into the fold. The expectation or pattern that was set in motion was that the TLD applications would follow a similar stream and that there would be a small group of TLDs that would be activated, and that at some point in the near future after, there would be an additional block. And it doesn't seem like that pattern stayed consistent.
Stuart Lynn: As I'm saying, I'm sort of at the evaluation task force report, which is a little late. But not not that late. And particularly the new TLDs haven't one of them isn't even in operation yet. So ... thank you for your offer. I really do appreciate it.
Vinton Cerf: Marilyn, I'm sorry, but I actually
Marilyn Cade: Sorry.
Vinton Cerf: said that we were going to stop questions, because we need to break for lunch. And we can bring any additional comments and questions at the public forum. I'm sorry that you must not have heard that. We are the reason I'm being so strict about this is that the hotel is asking us because they're handling so many people, they're trying to get us to be there when we said we were going to be there. So I have a list, however, of people who wanted to speak early on in the public forum open microphone. Those people who were waiting to raise questions on this report should come here right now and put their names on this list. I'll make sure you're first. So we will now break for lunch. And we will reconvene at ten minutes after 1:00.