ICANN|ARCHIVES
Internet Corporation for Assigned Names and Numbers
Please note:
You are viewing archival ICANN material. Links and information may be outdated or incorrect. Visit ICANN's main website for current information.
ICANN Public Forum in Shanghai Real-Time Captioning - Morning Session
30 October 2002
Note: The following is the output of the real-time captioning taken during the ICANN Public Forum held 30 October 2002 in Shanghai, China. 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
Shanghai, China
Wednesday , 30 October 2002
Public Forum – Morning Session
Reports
Governmental Advisory Committee Report
Root-Server System Advisory Committee Report
Security and Stability Advisory Committee Report
(Proceedings begin 08:30.)
Vinton Cerf: Good morning. My name is Vint Cerf. I'm the Chairman of the Board of ICANN. And it's my pleasure to open up this meeting of ICANN at Shanghai.
Today we're going to spend on the Public Forum literally all day until approximately 6:00 tonight. We will try to take a couple of breaks in between. But we have a very ambitious agenda for today.
Before we begin the session, I have a couple of announcements I'd like to make.
First of all, Mr. Bicalho reports that his laptop has been lost. It's a Toshiba Tecra 9000 and it was in one of the ICANN blue bags with some GAC documents. And it was up in the 7th floor reception area last night. He left it on the floor and has not been able to find it. So if someone has encountered a Toshiba Tecra 9000, would you please bring it to the ICANN staff office in room 3a on this floor.
Second, although I'm not sure that I see them in the audience right now, I'd like to remind everyone that we will have two new Board members to be seated later this year, Mouhamet Diop from Senegal, and Francisco da Silva from Portugal.
I'm sure we will see them here. Is Francisco here? There he is. Wave to everybody. There he is. Thank you, Francisco.
Mouhamet you will recognize instantly if you haven't seen him by his magnificent flowing robes from Senegal.
So let me begin by asking the President, Stuart Lynn, to make his report to the public forum.
Stuart.
Reports
Stuart Lynn: Thank you very much, Mr. Chairman. I hope you and the Board, the audience, will forgive me if I sit down and make my report. With my now famous back, it's a little easier to do it that way.
Sometimes I feel that since the President always presents his report first in these sessions, I play the role of the overture to fill in while everyone finishes their breakfast and comes to the room.
So you're now going to have the overture.
These are the topics that I thought I would touch on quite briefly.
First of all, on the Shanghai meeting, I would just like to take this personal opportunity – and the Board will do it formally tomorrow – but on behalf of the staff, to thank our host, the host committee, all the people who worked very, very hard to make this meeting such a great success in such a beautiful city. But on behalf of the staff, it's been a cooperative and collaborative relationship and we thank you for your help in making the meeting so successful.
I am going to talk about staffing and budget, the audit report, the memorandum of understanding with the U.S. Department of Commerce, some comments on ccTLDs, and a few other topics as we go through.
Just to bring everyone up to date on the year ended 2002, these numbers will be posted shortly. I won't go through them in detail. But, basically, on the expense side of the agenda, we came in almost exactly on budget. We were $49,000 ahead. It's always difficult to say why in any of these things, because any single expense can be the reason why. But one of the reasons why was certainly two extra Board retreats during the year that were not originally anticipated.
In terms of revenues, the anticipated contracted revenues with gTLDs and registrar accreditation and so forth, we actually did better than budget by US$215,000. As always with the past method of budgeting, ccTLD voluntary contributions were considerably short of the unrealistic number that had been budgeted. Namely, we budgeted US$1.3 million. And by the end of June 30th, we had received US$626,000. Actually, we have received more than that, but the additional amounts will fall into this financial year, not the last financial year.
You may recall from previous presentations that we have adopted a new mode of budgeting now where we state a more realistic figure rather than the fictitious figure that we always knew we would not achieve.
Other items depend on sponsorship and things like that I won't go into. But, basically, overall on contributions to the reserves, instead largely because of the shortfall in the budgeted ccTLD contributions – of a contribution of US$750,000, we've ended the year with a positive contribution of US$114,000.
I still remain concerned and disturbed that ICANN's reserves are nowhere near the level that they should be.
There are a couple of other funds that we carry. One is the fund that was established, what now seems long ago but was really about two years ago, for the funding of the new gTLD project. Of that, there is US$385,000 left over to be used for purposes that I will talk about in this afternoon's presentation.
And during the last financial year, we received US$319,000 to apply for the evaluation of dot org. But the expenditures against that don't occur until this financial year.
So by and large, we ended up where we were supposed to. The contributions to reserves not being what we might hope in an ideal circumstance, but that's because of the strange way of budgeting for ccTLD contributions.
If I jump ahead to the year that we're in right now, we're not in a position to provide any solid figures year to date. I put the budget on the right hand side. I will just note that the budget contained a number of assumptions. And there are items that will work against those assumptions. One is the Board tomorrow is going to consider a special appropriation for the cost of recruiting a replacement for me. As you know, I am retiring March or earlier should that work out. There's a cost of recruiting a new CEO that needs to be dealt with. The Board will deal with that tomorrow.
There are also costs that have not yet been ascertained associated with transition costs for reform should the Board approve changes at its meeting tomorrow. And the transition planning will occur in the next few weeks. And we'll be nailing down the financial implications of that.
So it would be premature to raise that now. But by the time we get to the special meeting in December, we will be in a better position to address that.
From the point of view of staffing, we now have 20 staff on Board.
We ended last year with a budget approval at 21. And we have budget approval of 27 this year. I will get back to that in a moment. Just some personnel announcements. As we announced in Bucharest, Andrew McLaughlin is now half time, having given up his Vice Presidential post, and is acting in a more half time consulting role and supporting various activities. It's with regret but great understanding that I must announce that Herb Vitzthum, who has been our ccTLD Liaison for the last year or so and has done a magnificent job, has decided to leave ICANN for personal reasons, not the least of which are the travel conditions imposed by an ICANN job that interfere seriously with his being able to spend the time he wants with his family. That's something I can certainly relate to. He will be leaving ICANN at the end of this year and moving on to other things.
We're very grateful to Herbert for all of the tremendous contributions he has made, the hard work he has done and will wish him the very best probably at the annual meeting in December.
I am also pleased to announce, that Anne Rachel Inne from Africa will join ICANN full time in December. She will be moving to Marina del Rey and joining the staff, playing a role in some ccTLD liaison work, but also in policy analysis and other support roles.
Anne Rachel is familiar to many of you, because she has worked in the ICANN framework for quite some time now and has played a significant role for ICANN in helping to address some of the outreach issues that we need to consider in Africa. She will be joining us in Marina del Rey.
Steve Conte who is here this week, Steve is over there. Raise your hand, Steve. Has just joined the ICANN technical staff. We're delighted to have Steve with us.
Denise Michel, who is most famous for her at large activities, is now playing a broader role on the consulting staff involved with other key support activities, one of which you saw yesterday in helping to organize the transfers workshop that took place yesterday. But she will be playing many varied roles, while not in any way relinquishing, should the Board approve the bylaw changes, her role in support of the emerging at large advisory committee, should that be approved tomorrow.
We have also had some administrative staff turnover. A couple of staff have left and their replacements have been recruited. We have several other positions coming on line. Two have been posted: the registry liaison position and the webmaster that we're in the process of recruiting. If anyone knows any good candidates, please do let us know.
We have a limited recruiting bandwidth. We can't recruit a lot of positions at once. But as soon as these two positions are further along, we'll be recruiting other positions as well.
The audit report, which is due October 31, will be a few days late and should be posted next week. One of the primary reasons for being late is that one of our auditors, in doing her field work, fell off a horse and, unfortunately, injured herself, that caused some delay. We're pleased that she's recovered. But it did result in a few days' delay to our final audit. I just want to mention that the figures that I just gave you are unaudited. You will find , however, that as best we know it now, we have no reason to anticipate any change. They will track precisely the audited figures. The only thing is the great difference in how material is presented between the way we do things for management reporting purposes and the way the auditors report them. All of those differences are reconcilable. They include differences like –the fact that we don't include the DNSO Names Council income and expenditures, because that's not part of the way the ICANN budget is considered. They are separate. But, obviously, they get consolidated into the final audit report. As another example, the new gTLD expenditures that we carry forward separately as against a kind of informal reserve, are included directly by the auditors in the income and expenditure column. So the difference is in presentation. But the reconciliation has been gone through with the Finance Committee and we'll be presenting that, too.
There are no surprises, no comments in the audit report. It's a clean report.
As I'm sure most, but perhaps not all, of you know by now, we're very pleased that a one-year extension of the Memorandum of Understanding with the United States Department of Commerce was signed on September 12th. In my view, there are significant improvements compared with previous years. Previous years tended to talk about the broad areas that we need to accomplish, without any real sense of the time that it takes to accomplish those broad areas. And so every year, it looked as though there was not progress. One of the big improvements this year is that the MoU has much greater focus on specific tasks to be accomplished in the shorter term while still putting them in a broader context and places greater emphasis on the role of the DOC in collaborating to achieve some of those tasks.
I want to say that accomplishing those tasks is, yes, a challenge for ICANN, and to the extent that they collaborate with us, the Department of Commerce. But they really present a challenge for the community in terms of what the community wants to see happen and what it doesn't. These are not things that ICANN has any arbitrary, unilateral powers to accomplish or impose on its own. It's what we want to do together.
I'm sure there will be more discussion of that.
I do want to make some comments on relationships with ccTLDs.
In the first place, there will be several agreements being signed in the next few weeks. We expect to get some completed by this meeting, but there is a little more work to be done. We expect them to be consolidated over the next few weeks.
There's obviously been a great number of difficulties in relationships between the IANA function and ICANN staff and some of the ccTLDs, particularly some serious differences of view over interpretation of policy. And these are legitimate differences of view. These are differences of view on which I don't want to take sides all of us have views with respect to documents that stretch back historically and where interpretation represents challenges for all of us. And this certainly came to a head on the so called famous AXFR issueI in connection with name server changes.
I think where that's headed now is – a much more reasonable way to think about it – is to channel those differences into a much more constructive framework where, with the advice of the Names Council, the Security and Stability Committee has undertaken the task to think about how to improve DNS stability.
Candidly, I think we on the staff side probably tied some things together in terms of DNS stability and name server changes that should probably be thought about separately. And I think that we're on a much more constructive direction now.
It brings home to me, as it has several times, that I remain concerned that although we have a very fine policy context handed down from the past, if we have so many differences of view over interpretation it raises the question that the policy context probably needs some serious rethinking. And that's something that is probably timely to do.
You know, it often gets focused on how quickly we do name server changes. Name server changes come in very different flavors and it's very hard to find one policy that fits them all. And I hope this is an opportunity and even in the context, perhaps, as it develops of the ccNSO, for all of us to work together to do hard thinking on what is the right policy framework for some of these kinds of things that we can all deal with.
The IANA function is a function that is not a policy part of ICANN. It's an operational part. But it can only respond to what it believes is the correct policy framework. And if we have differences of view in that across the community, it's up to all of us to work together and straighten that out and arrive at a common view of what that policy framework should be.
So I hope we can work together on that as we move forward.
Dot org: as I'm sure most of you know, the selection process is complete. The Board made a decision last month to award the reassignment of dot org from VeriSign to a proposal from ISOC and a new organization which has now been formed and is in place: the Public Interest Registry.
Eleven very serious and very thoughtful proposals were submitted. I want to extend my personal appreciation to all the bidders who put in so much time and effort and worked very hard on all the various proposals. I know there are 10 who are disappointed. I know there are always differences of views in these very complex procurements. And many o differences of view that can get very strongly expressed at times. That's part of the bidding process. We accept that. We have a very robust environment, and it should be that way. But in the end, only one decision can be made.
But I have had talks with many, if not most, of the other bidders, and I appreciate very much the gracious way in which they want to move on and move forward and look to future opportunities.
The proposed agreement with PIR, has been posted. It follows the seven day rule that expires, I think, on Friday, before which any Board member who wishes can raise policy questions or objections. If they do not, then I am given the authority to enter into an agreement and sign it, which I would do next week. If they do, then we will need to have a special Board meeting to discuss it. But we are on a very short time fuse that we are on for transition – I'm going to say midnight December 31, but that's a meaningless number across a global community. What I will say from my own discussions with the folks involved, from both Afilias, who are doing the back end work for PIR, and VeriSign, is that there is very serious and constructive collaboration taking place to ensure a smooth transition. And that would occur depending on where you live in the world, on or about the transition from 2002 into 2003.
New TLDs is a subject I often get asked about. The Board at a meeting in August when I presented the NTEPPTF Report solicited my recommendation on how to move forward. I proposed a three part action plan that I will present to the forum later today. It has not yet been posted because there will be no action at this meeting. It will be posted early next week with a view to receiving community comment, and possibly a Board decision at the Annual Meeting. But we will be talking about that later today.
Just want to remind everybody of the meeting schedule coming up. We have the special Annual Meeting in Amsterdam. We have scheduled December 14th 15th. The afternoon of the 14th will be a Public Forum. The morning of the 15th will be a Board meeting. There might be some extensions of those times, depending on the agenda.
Those of you who have constituencies that may be interested in holding meetings, we'd be happy to advise you on space availability. As has been posted, the hotel is the Sheraton hotel at the airport in Amsterdam, so you can literally walk from the the airport into the hotel and back again without having to step out into the beautiful sunshine of the Netherlands in the middle of December.
And if any constituencies or organizations want meetings, you need to schedule those yourselves, although Diane Schroeder would be happy to advise you on logistics. There are other hotels besides the Sheraton also.
We announced with great pleasure that the 2003 spring meeting will be held in Rio de Janeiro, sandwiched between carnival and the grand prix. The formal meeting is the 24th through the 27th of March with a preday on the 23rd. We are very pleased that the first meeting in North America outside of Marina del Rey will be held in Montreal, Canada, June 23rd through 26th. The Meetings Committee is in the process of evaluating recommendations that have been received for the 2003 fall meeting that will be in Africa, presumably in November, but the exact date and location are yet to be decided.
Just some closing comments, if I might.
Obviously, I have not talked about reform in my presentation because that will be the main topic du jour.
I just want to say, from a personal point of view, that I put forward a document last February that received universal acclaim and agreement.
(laughter.)
As I can tell.
And the community and the Board and the staffs have worked extraordinarily hard over the last eight months in putting forward reform proposals, entering dialogues, participating in substantial discussions, substantive dialogues.
I am personally greatly appreciative that the community has stepped forward and tackled this very, very difficult and thorny but critically important problem.
I mentioned in my document that I saw three primary problems, which I'll just summarize as funding, process, and stakeholder relationships.
I believe that to date, we have addressed, and not everybody will agree with everything there, but the ERC has done yeoman work with the community in addressing the first two of those.
As for the third one, we clearly have a lot of work left to do in terms of relationships with important communities.
I'm pleased that I see some of that progress has already started, but there's a lot of work to be done in how ICANN and its stakeholders we use the word stakeholders often not knowing exactly exactly what that means – can establish the right form of relationship.
It's a very, very difficult problem, particularly in an Internet world where we think of working in partnership, collaboratively, and anything that smacks of coordination raises very difficult questions.
I think everybody who is thinking about those problems is thinking about them very constructively and I'm looking forward to some of the dialogues that are taking place, resulting in very fruitful progress in examining that third area which clearly needs to be done.
And that may take time.
Not all things happen in short time frames.
I think it's been amazing how much has been accomplished on reform in the last eight months, whether or not you and the Board decide to go forward on Thursday and what emanates out of that and how that leads to transition planning, which will be the subject of the December meeting, or the main subject, all remains to be seen.
But I think it's been I thank you all for the role that you have played in thinking so hard and working so hard on these problems and helping point ICANN in some right directions.
So thank you very much.
(applause).
Vinton Cerf: Thank you very much, Stuart.
Since your tenure with the organization continues, I won't respond with the usual encomiums until after it's necessary
I'd like to invite Paul Twomey, the chairman of the GAC, to give its report now.
Paul.
Governmental Advisory Committee Report
Paul Twomey: Thank you, Vint, members of the Board.
The meetings are getting smaller and smaller, aren't they?
I'd like to present the communique of the Governmental Advisory Committee meeting held here in Shanghai in China.
They're transferring technology, apparently, to project the communique, but I might continue, I think, for time purposes.
Should I?
Vinton Cerf: Yes, please continue.
Paul Twomey: Everybody knows this first paragraph by heart.
The Governmental Advisory Committee of the Internet corporation for assigned names and numbers met on the 27th, 28th and 29th of October 2002 in Shanghai, China.
The
Vinton Cerf: Paul, I'm sorry.
Just bear in mind you have people who are transcribing as you speak, and although
Paul Twomey: Sure.
Vinton Cerf: they may not know this paragraph by heart, so if you would take this into account.
Thank you.
Paul Twomey: I can say this paragraph in my sleep.
That's the trouble.
The attending GAC members, which included representatives from 32 national governments, distinct economies recognized and international fora, and governmental and treaty organizations had useful discussions concerning ICANN related DNS issues.
Reform:
The GAC continues to focus on ICANN reform and reports of the Evolution and Reform Committee, including the suggested amendments to the ICANN bylaws.
Members addressed issues of relevance to implementation of IPv6, recent deliberations of WIPO in the IETF, ccTLD management issues, GAC reform, and forward going work program, and resolved to hold elections for GAC office holders.
On ICANN reform, noting its statement of concern in Bucharest around the timeliness of the ERC consultation process, the GAC welcomed the commitment of the chair of the ERC to continue dialogue on implementation of ICANN reform and encourages the ERC to adopt –language that puts forward adequate opportunities in the future for the GAC to comment.
Affirming the decisions of the Bucharest meeting, the GAC continues to maintain a strong interest in the deliberations of the ERC.
The GAC discussed the ERC's proposed new bylaws and agreed on certain recommendations for further amendment.
These recommended amendments are attached and the GAC requests that the ERC and the Board to duly take these recommendations into account.
And I have been asked by the GAC at the end of this communique if I would take you through these proposed bylaw changes.
The GAC will consider any further bylaw text to be supplied by the ERC, for Article 9 on the ccNSO, and to comment if necessary.
As the GAC has previously noted, the Internet is a global resource which supports worldwide economic and social interaction.
The GAC notes that the issues arising from the coordination, at the overall level, of the technical aspects of the global Internet's systems of unique identifiers are entrusted to one entity whose activities should appropriately reflect the global interdependency of the resource.
Consistent with this approach, the GAC calls on all parties concerned, including in particular ICANN, but also the RIRs and the ccTLD constituency, to cooperate in good faith in order to ensure a relationship conducive to efficiency and mutual confidence.
Moving on to a dialogue with the ccTLD constituency, the GAC and the ccTLD constituency continued dialogue on ICANN reform.
The GAC noted comments that the simplification of contractual positions and processes might facilitate improvement in interactions between ICANN and the ccTLD constituency.
Recognizing that Internet stability depends on accuracy of the IANA database, the GAC urges ICANN to ensure that the IANA function performs updates in a more timely and efficient manner to ensure accuracy.
While the GAC members maintain their positions as expressed during the Bucharest meeting, the GAC prefers that its representative on the Nominating Committee be a nonvoting liaison.
IPv6:
The GAC welcomes ICANN providing the workshop on IPv6 for the first time, particularly in view of strong interest in this topic.
The GAC strongly supports the efforts of ICANN and related groups in the smooth and safe deployment of IPv6.
The GAC further encourages ICANN to continue to update information on the operational stages of IPv6 with the community.
WIPO:
A presentation was made of the decision taken by the WIPO members at their meeting from 23rd September to October, 2002 on the issues addressed in the second WIPO Internet domain names process.
The GAC agreed that this issue would be put on the GAC work program for consideration at its upcoming meetings.
IETF:
The GAC received a presentation from Harald Alvestrand, the chair of the IETF on ICANN and the IETF.
The GAC members expressed their appreciation for this presentation and encouraged further dialogue with the IETF in the future as appropriate.
GAC Organization
Moving to GAC internal organization and its work plan, the GAC discussed priority areas for future work for the 2002 2003 period.
Members agreed to hold elections for office bearers beginning the first of November, 2002.
The GAC expects to have a new team of chair and vice chairs in place by mid January, 2003.
The GAC agreed to accept the offer from the European commission to provide the interim secretariat that will be supported by other members.
The transition between Australia and the European commission should be essentially completed by the 30th of November, 2002.
The GAC expresses its appreciation and thanks for Australia's support since 1999 for the GAC chair and secretariat.
Considering the diversity of the GAC, in the sense that it represents a collection of different countries, distinct economies, and international organizations that respond to varying domestic and international issues, and also taking into account that GAC members hail from countries or distinct economies with very different levels of Internet penetration and DNS awareness, members agreed to continue with outreach strategies and encourage issues that would be considered as educational and information sharing.
This will ensure that the GAC's work reflects the interests of all members and will introduce mechanisms through which the various local Internet communities benefit from having their governmental or public administration representatives at the GAC.
IDN:
The GAC moving to IDN, the GAC welcomes the update provided by Katoh san, the chair of the ICANN IDN committee, and James Seng, co-chair of the IETF working group, on matters relating to international domain names.
The GAC also notes that the IETF IDN committee had made various recommendations as to the standards for use of IDNs.
The GAC would like to recall its advice to ICANN in its previous communiques to exercise great care in the introduction of IDNs and to consult all parties affected by the introduction of IDNs.
Dot info and country names.
The GAC continues to monitor and facilitate the registration of dot info country names as per the Board decision of the Montevideo meeting of ICANN.
Meeting:
The GAC warmly thanks the Internet Society of China and sponsors for hosting its meeting.
Next face to face meeting of the GAC will be held in March 2003 in Rio de Janeiro Brazil to with ICANN's next meetings.
I wonder if it would be appropriate to move to the wording of the bylaw recommendations.
Vinton Cerf: There are two possibilities.
One would be to go through that now and the other would be to reserve that to the time when we get to the evolution and reform discussion.
If you would be available, perhaps it would be useful to entertain those remarks at that time.
But if you don't mind answering one small question that I have about your general report.
You mentioned the phrase "interim secretariat" with regard to the European Commission's undertaking.
Do I understand from this that the European Commission will undertake something as an interim step and that something else will happen thereafter?
Paul Twomey: What is expected is that the offer made by the European Commission to host a secretariat and have some resources and also have people from other members seconded potentially or supporting, that offer is to be considered further by the GAC probably in some sort of two month or so time frame.
I forget the exact time frame.
But when we say interim, interim in the sense of to be reviewed.
Vinton Cerf: Thank you very much, Paul.
Are there any other questions from the Board for Paul?
Thank you very much, Paul.
I'd like to call on the chairman of the root server advisory committee, Jun Murai, to make his report.
Root-Server System Advisory Committee Report
Jun Murai: It's working.
I think it's okay.
Okay; sorry.
Thank you, Vint.
This is Jun Murai, Chair of RSSAC, the Root Server System Advisory Committee.
The Root Server Advisory Committee is basically creating advice to the Board regarding the root name servers.
Root name servers are basically I don't have to repeat this -- but very briefly, the root servers are the set of DNS name servers, which are serving the root zone file.
And the role of the root name server operators is basically to update the database and then share the database among the distributed root servers, and to make it available to everyone.
That is the goal of the root name servers. Currently there are 13 distributed around the world.
You see the map, we have used for the Y2K events, but anyway, you can view how they are distributed.
Actually, three of them are outside the U.S., and the rest are in the United States.
Those could be found on the website.
We are have had 13 meetings in total, starting from March 1999 in Singapore, and the last one was in Yokohama.
People may notice that unlike the other ICANN created meetings, because of the convenience we are mainly having the meetings along with IETF meetings, so the last one was the Yokohama IETF meeting, and the next one will be in Atlanta.
Let me talk you about the diversity of the root name server because I think that's most of the people's concerns, especially this time because of the incident reported in this month.
The root name servers are a distributed system as I described.
The 13 root name servers are located at distributed locations all over the world.
Each of them, however, are a very carefully designed mechanism to provide the robustness by its own.
And so there are different hardware platforms, different types of systems, and different types of vendors. So everything is diverse which is a key issue to keep the entire distributed system, the root name server system, as robust as possible.
And so for the servers, there are contingency plans for server outage or difficulties on operation on each of the server.
And the servers are kept in professional facilities, very strong hardware physical environments.
And the operators are different personalities, multiple operators per servers, and a very strong social network, which is, you know, communicating almost every day over the e mail. Also we have alternative way to communicate with each other -- multiple alternative ways to communicate -- for the cases like incident that occurred and also for the security reasons, we have established encrypted communication channels.
This is what the root server operator community is using, encrypted messages, for most occasions.
There are technical guidelines, written technical guidelines by the IETF working group, especially RFC 2870 as guidelines for the root server operators.
So this all defines a very high quality of stability, along with other technical guidelines and each of the operators and servers are meeting these criteria. We achieve the planned strength of all of the servers.
There are physical access limitations to each of the servers and that other security controls.
So this is one of the rare opportunities, at least for some people, to see a visualization of a DDOS doc, in this case as seen on the "M" server.
Happened in whoops.
(laughter).
Jun Murai: Okay.
Well . . . .
(laughter).
Jun Murai: I don't know what happened.
Vinton Cerf: It's a denial of service attack!
(laughter).
Jun Murai: Okay.
This is a time slice covering about 90 minutes.
This is basically a graph showing the traffic monitor for one of the root server from different channels.
The "M," server, for example, has multiple channels to access to the server, and you can monitor access from the different channels, the traffic behavior, or you can notice the DDOS from this type of a graphic.
And this type of real time monitoring is operated by operators.
So within a few minutes, all of the operators have been synchronized to work against the attack.
So basically this is a summary of incident report on October 21st, DDOS attack.
On Monday, October 21st, approximately 2200 UTC, for about 90 minutes, the root name servers were all subjected to a coordinated, distributed DDOS attack.
Three of the servers didn't show any service degradation, which is very nice.
The network congestion caused by this attack caused the remaining servers to be effectively unreachable from a large portion of the network.
But enough servers remained reachable and to ensure continued service, including access from the overall Internet.
There have been no reports of visible user service errors.
There could be a minor degradation of the service slowing down from some places, but none have been reported so far.
So this is one way of demonstrating the robustness caused from the diversity and distributed design of the root server.
But anyway, the trigger alarm from a number of root server health monitors operated inside and outside the server community is indicating this incident.
And after the start of the attack and in 90 minutes, half of the root servers have been, with a lot of work, coordinated by operators using the multiple communication channels among the operators, and then totally correct operation was reestablished. reestablisedIn about two hours all have recovered.
So this shows that the system was robust and diverse enough to sustain this particular attack.
And more capacity should be added to the system in order to resist predicted future attacks.
So RSSAC continues to study ways to add needed capacity with both short term and long term approaches, and also to improve the possible communication channels for internal and external cooperation.
So that's my report on the DDOS.
And then this is explanation about the zone transfer.
I can skip this.
So the other server topics have been the other group, DNSSEC, IPv6, and IDN impact.
I already reported this on the previous meetings, but all of them have been carefully studied.
But in particular, IDN, since the progress in the IETF arena about the definition of the IDN is certainly needed–. We have reviewed the task already, and so far can report that it will have no serious impact on root server operations.
But we really need a test period to deploy the technology.
So in summary, –I have explained briefly about how DNS root system operates, security and stability issues, especially focusing on an attack report on the October incident, and created a report ton DNSSEC progress, and further cooperation with measurement groups and the IETF and other related groups. We will continue to be more active in making improvements toward the stronger robustness.
So these are the URLs, and next meeting will be during the IETF Atlanta.
Thank you very much.
Vinton Cerf: A question from Karl.
Karl Auerbach: The green?
Ah.
Technology overcomes me.
Just a point of clarification.
You said that the attacks I'm not sure of the exact word, but they were resolved within 90 minutes to 120 minutes.
Does this mean that active corrective measures were taken or that they just ceased on their own?
Jun Murai: How do we identify the recovery?
Is that your question?
Karl Auerbach: No.
Was the recovery due to active measures on the part of the root server operators or was it because the attacks stopped happening?
Jun Murai: Both.
Basically, some of the servers which degraded, you know, which were slowing down, resulted in taking active countermeasures.
And so the 90 minutes to two hours as a result.
And in order to achieve that, some of the root servers which were slowing down or impacted by the attack was due to the special nature of the attack, yes.
Karl Auerbach: Because what I'm really concerned about is whether somebody out there turned it off, which means that person could turn it back on, or whether walls were constructed and it's actually still going on and it's just having no effect?
Jun Murai: Basically, this is a DDOS attack that increases the traffic. There are very well known ways to stop or prevent that attack while you are monitoring it.
So most of the solutions are using those kinds of a methods.
Vinton Cerf: Thank you.
Just one other question for Jun.
This is somewhat following up on Karl's question.
Could we assume that the same mechanisms that would be helpful in defending against a denial of service attack against any host would be also useful in defending attack on a root server?
Jun Murai: Of course.
As I said I don't know how to stop that, but I think I know how to stop the root server attack, I hope.
(laughter) (applause).
Jun Murai: Yes, the DDOS attack is well known, very hard to prevent.
You know, the solutions to a DDOS attack could be implemented in a pretty primitive way, identifying the traffic and then removing that traffic or filtering that traffic.
And similarly for the other cases you mention.
The kind of solution that was applied to this attack could be applied to other servers or services, yes.
Vinton Cerf: One other question from Andy Mueller.
Andy Mueller Maguhn: I just recalled from a previous meeting that the distribution of a root server covering from the top down was not really tested from the case that root server "A" should be absent for whatever reason.
Was there, in the meantime, some testing made for alternative distribution of the data from one of the other root servers?
Jun Murai: Yes, that's, as I reported as, yes, part of the description in here. This from A to the other servers you are talking about?
Yes, that has been studied and that has been part of designing a new structure of distributing the original zone file to the servers.
But I'm not sure if that is related to this attack or not, though. I mean, the DDOS attack right now.
Andy Mueller-Maguhn: But alternative distribution has been tested or has been or is in construction?
Jun Murai: It has been tested in any real life server basis, but yes, it has been tested.
Vinton Cerf: Okay. Thank you very much, Jun.
I'd like to call now on Steve Crocker, who is the chairman of the Security and Stability Advisory Committee, for his report.
Security and Stability Advisory Committee Report
Steve Crocker: See if this works. Oh, my goodness.
Is there power here? I've been advised that I should remove my dark jacket for t.v. or something like this.
Thank you. I always have mixed feelings following Jun, because he does such a fantastic job. It's a pleasure to hear him. And he also sets up a number of the things that are relevant for us to talk about in our Committee.
And on the other hand, he's a hard act to follow.
Just I want to do, basically, three things: A quick review of pieces of our Committee. Here's the Committee membership. Then I'll talk generally about what we're doing. And then focus on a couple of the current events that have really occupied us in the last couple of weeks.
So here's the very distinguished group. I'm actually bowled over every time I review the total competence and experience that's embodied in this group here.
And the strength of this group is that it spans expertise in all of the operational areas. That's the good news.
And the absence of the bad news is that we're assiduously not a policy or politically oriented group as best as we can hold ourselves to that. I want to talk about general progress we've made and then the specific things in areas of zone transfer, a couple of words following up on Jun's report on the attacks and then top level domain servers and then Whois accuracy.
We set out originally to try to do a fairly comprehensive look at security issues along multiple dimensions. The protocols, the system design, the registration process, identification, and countering of threats in each of these areas.
And then one thing I'm particularly interested in is an attempt to quantify, wherever possible, progress measures and measures of goodness and safety and stability and security so that we can separate out emotional measures if things are good or if things are bad, and also provide shared model of what kind of progress we might be making.
Well, what's turned out is that I still believe strongly in all of this, and we're continuing to proceed. But it's been slower going than I had hoped.
So here was our long term schedule, which was to plot a course toward an acceptable state. And it would probably take, I thought at the time that we set this out in the Spring, a couple of years. And then assuming we made it, then we'd shift into some other mode.
And I had said last time that by the time we were in Shanghai, we would have published description, vulnerabilities, security architecture, and a measurement framework.
And the answer I one of the things that I feel strongly about is that whenever I make a report on what I did, it's important to compare it to what we said we were going to do. And the chips fall where they may.
So the answer is, we have not finished this work. It's underway. It's still coming out. But I feel the need to shift the mode of our activity a bit.
So one of the things that we're going to do is focus on individual threats and individual recommendations for those threats, and then piece that together into a larger framework as the pieces fall in place.
And this is, in essence, just an artifact of having a lot of very busy people trying to grab bits and pieces of time as we move along.
In the meantime, the events of the past few weeks have focused our attention. As Jun just reported, the denial of service attack last week was substantial and serious, but the damage to the end users was minimal or nonexistent. And so the view that we have, and I don't think we are as close to it as some of our members were, but I was sort of secondary, concur with everything that Jun has reported.
Further, that there is basic strength in the structure of the root systems and there's good redundancy, there's diversity. And that operational staffs responded quickly and vigorously. To follow up on the question that I think was it who was it who asked about the was that your question, Karl, about whether the attack subsided by itself?
So my understanding is, yes, the attack subsided by itself.
But equally, the response from the operators diminished the effect of the attack well before it subsided.
So and I'll just speak from my particular understanding of things, is that if the attack had proceeded pretty much indefinitely at the same level, so one has to keep things sort of constant, that the world would not have seen much of a change.
Of course, it's very, very unlikely that the attack would have proceeded at exactly the same level. And furthermore, even if it had, the response would have been from the protection side would have been far greater to fight back, to filter, to put up defensive measures, and so forth. So in some sense it's an academic issue as to how long one could sustain under that attack. But I think the answer to that academic question is sort of indefinitely. So if the attack were turned back on, I think the response would be equal.
But on the other hand, it's very unlikely that if the attack would be turned on it would be an identical attack. So one has to operate on that . . . .
The servers, as best we understand, did suffer under the load. Some stopped responding, some being able to give out proper answers.
But equally, none of them actually broke. They sort of stalled as opposed to –breaking, and when the load was removed, they responded, went back to their normal operation.
And so the capacity of the servers, the fact that a number of them were very well provisioned and had extra capacity, and the rapid response from the operators, I think, was the key in this case.
So what kind of lessons learned from our perspective do we take home?
Well, from a sort of a short term, immediate what kind of improvements to make, one could add yet more capacity to the servers, improve the communications, which is already pretty good, but look for ways to strengthen the communications among the operators and also, to a certain extent, with the law enforcement and other governmental and oversight committees that want to be informed immediately in case anything happens.
Vint and I think you touched on a subject that I'm now quite energized about, that these denial of service attacks, of course, are not necessarily specific, and the gun is sort of trained on the root servers in this case, and there was also some attention later on that evening to the top level domain servers.
There are things to be done, I think, that are good medicine in general on the network. And against denial of service attacks securing the edge, push back strategies, reducing the number of hosts that are bought off the shelves of as consumer products, and are public nuisances the minute they're plugged in.
And I think it's appropriate to speak about that even though it's beyond the narrow purview of the Domain Name System per se, because it, in fact, affects the entire network. And I think that we should lend a hand there. I don't think we need to be the only voice, by any means.
So that's an area that I would like to actually put some energy in over the next several months.
We from our committee's point of view, we will work to put out a report. I do not want to put out an independent report that is a redundant, extra effort. But we'll work with others.
And it also serves as a bit of a lesson for us to engage in more operational issues than we have in the past. And that's probably helpful.
And as I said, it'll open up a dialogue on generic denial of service activities.
Let me move to the zone transfer controversy.
You've all heard about this in several forums. We were asked fairly recently if we would comment on the procedures involved within the zone transfer. And our focus, of course, is on the security and stability issues as opposed to any other complications involving politics or any number of things.
It didn't take very long, I would say, to come to a conclusion that there are a small number of absolutely essential requirements, namely, that the request or the requestor has to be authenticated so you don't have a wholesale hijacking of a zone. And that there be consistency between the parent and the child so that the transfer actually works.
Then there's a number of other things which are highly desirable: Accuracy of the glue information, accuracy of the names of the name servers, that the software that's running be up to date, if it's a version of bind, that it be one that's not behind and full of known holes, or other equally competent software.
Quite a lot of attention is given to redundancy and geographic disbursement of name servers. This is important. It's first of all not as trivial to check, because one could have, for example, different name servers on t different adresses that are in fact in the same room and share the same fate with respect to power supply. So a mechanical check as opposed to some of the earlier points, which are more easier checked mechanically, a mechanical check of diversity is not so easy. But for a small number of key domains, it's relatively easy to check that.
On the other hand, the consequence of not having diversity is you simply have a higher percentage chance that you will have an outage. And that now moves into a policy area of cost and risks and so forth.
Another area that probably has had less attention than it should have is disaster recovery preparations where the disasters of interest are both physical disasters of anything from earthquake and fire, which physically destroy machines, to just network outages, but also, as the KPN-Qwest situation showed, there are business disasters that lead to dramatic interruption of service. That's a more complicated issue regarding legal and business issues as well as technical issues. But from a security and stability point of view, one way or another, it would be appropriate for all of the important servers to be operated in a way that there is a quick recovery mechanism, if possible.
And there's not a whole lot more to say at this level, because there begins from this point in the discussion a lot of complexity. So we'll leave that open.
From our point of view, we are now engaged with the IANA and with representatives from the ccTLDs to actively discuss the zone transfer procedures and see if all the parties can come to a relatively quick resolution on this.
Speaking for myself, I'd like this not to be the entire focus of our Committee's activity for sure.
And, finally, we've also been asked to comment, I guess there was general query, request for comments, on the Whois process.
And we're about to speak formally, and the content is fairly simple, that there should be a last verified date, that privacy is an element that's required in the operation of these systems, standard format should be developed, and that the Whois servers be known publicly. Nothing very deep or complex. Sort of good hygiene, in a way.
So that's the set of things that I share with you today on behalf of our quite distinguished Committee.
Vinton Cerf: Are there any questions from the Board? Karl?
Karl Auerbach: Yeah, I think the cat is definitely out of the bag that DNS is targeted. But I don't know if everybody noticed but in a magazine as mainstream as Atlantic Monthly this last month saying the best way to take down the Internet is to attack the DNS system. That was quite a surprise.
This last point about Whois, though, triggered a long lost thread we have had, which is our registrar escrow systems. That is largely the same question as standardizing data formats.
And I think this is gives new impetus to getting that system into place, the escrow system, I mean.
Vinton Cerf: Just one question from me, Steve.
In the case the attack is not a distributed one and there are a small number of sources, but they are using spoofed source addresses, do we have mechanisms now that allow us to trace back the sources? It's pretty clear that the level of packet transfers that were taking place, the amount of traffic that was aimed, was easily generated by a small number of machines that have adequately high bandwidth access to the net.
But the question is if the source addresses don't allow you to determine the source because they're being spoofed, then the only thing you can do is some form of transback. And what I don't know is whether you or the Committee knows whether those tools are readily available to ameliorate the attack.
Steve Crocker: Right. That's what led to my including a comment about securing the edge.
I think you are trying to be helpful in helping me clarify these things. I appreciate that.
The state of the art at the moment is that there is not a sure fire way to trace back these spoofed addresses, and that it would indeed be very helpful to eliminate bogus addresses or reduce them substantially, if possible, as one of the layers of defense. It won't, ultimately, stop these kinds of attacks, because in the case of a distributed denial of service attack, if you list thousands of machines, even if you can track down each one of them, they're still attacking you. But it does remove one layer of protection from the bad guys. So that's, I think, a useful thing to do.
Vinton Cerf: One more comment.
Karl Auerbach: One area that has me concerned, I don't know whether it's in the scope of the Committee or not, is some of these mechanisms may depend on alternative systems, like to get a zone file around, you write a little memory stick and drop it in Fedex and send it. But what is the cross linkage between systems as the Internet becomes increasingly part of other systems? For example, Fedex is very dependent on the Internet. And what if the telephone tree that we're using is an IP based telephone tree that depends on DNS to get DNS back up and running?
I'm concerned that we don't get ourselves into a bind where we have interdependencies that keep us from coming back.
Steve Crocker: You want to build a covariance matrix for the world here?
Karl Auerbach: Yes, something like that.
Vinton Cerf: Thank you, Steve, not only for your report, but for the work that you and your Committee are doing.
I see well, I wasn't going to open the floor up, but if you have one question, go ahead, Marilyn.
Marilyn Cade: I have an invitation.
Tony Harris and I cochair the Whois task force of the DNSO. And we welcome the comments of the SAC on Whois and would invite an opportunity to have a conference call between the Whois task force and the SAC to talk further about Whois, since we have an interim report published.
Steve Crocker: I think we can accommodate. I know just the fellow. And thank you.
Vinton Cerf: Thank you, Marilyn.
Nigel Roberts: Just a question of procedure. Are we having questions to
Vinton Cerf: To be honest with you, because I have so much on the agenda, I'm struggling. If there are questions only for clarification and if they're brief, I would try to accommodate.
But if the attendees would allow me to terminate questions when I am starting to feel pressure on schedule, I would appreciate your accommodations.
Nigel Roberts: Okay. I thought this was the Open Forum. It's a misunderstanding. I thought this was the Open Forum.
Vinton Cerf: It is an Open Forum. But the open microphone part is at the end of the meeting.
Nigel Roberts: I just thought it's appropriate when you have security questions and the questions come after the security presentations, that's all.
Vinton Cerf: I actually agree with you. So if you have a question for clarification, please go ahead.
Nigel Roberts: I certainly do. Thank you very much, Vint. Nigel Roberts.
I don't wish to sound over critical, because I know that the job related to security is extremely crucial from my own professional work as well.
But I find that the position taken by the Chairman of the Security Committee and in public by Vice President Touton which I read in the International Herald Tribune, such a mainstream publication on the flight over here, to be rather overly complacent in regard to the attacks on the root servers. And I will simply highlight this by metaphor.
In 1993, the World Trade Center was attacked. This was our 1993.
The question I've really got is that after September 11th, we had, in November, a special meeting on security and stability of the Internet. The whole meeting at Marina del Rey was devoted to this.
At that time, I and others pointed out the single point of failure, certainly as far as registries are concerned, and ccTLD registries in particular, and that was the IANA still has no mechanism for urgent updates of name server details in the event that a single ccTLD comes under this kind of attack and we wish to change name servers in a hurry. There is no method of urgent authentication, there's not even a formal method, although I believe there are informal methods, of reaching somebody outside of business hours, California time.
We said this a year ago. I'm repeating it now. I hope we don't have to come back and say, "we told you so." .
Steve Crocker: I'm still riveted back at the World Trade Center. And I now see the need to have a replicated IANA ready to go in the case that the IANA is taken out by force.
And the rest of the issue is a procedural matter with respect to ICANN, I think.
Vinton Cerf: Okay. Karl.
Karl Auerbach: I just want to mention a little known event that happened after September 11th, which was VeriSign put into play an emergency update service so that people whose had to make right now name server changes were able to do so without going through a lot of the formats. But that wasn't well known.
Vinton Cerf: Okay. Thank you very much.
And thank you, Steve.
I'd like to call now on Mr. Katoh to make a report from the IDN committee.
In case you were looking at the agenda, this is an addition to the agenda.
Internationalized Domain Names Committee Report
Masanobu Katoh: Thank you, Vint.
I will try to be relatively brief since I have had many chances to talk about this Internationalized Domain Name issue in forums such as GAC and ccTLD meetings, and we had a very interesting, you know, meeting as a workshop on Internationalized Domain Names.
This is the current members of our committee. As you can see from this list, many of us are from the countries where English is not the first language.
And this is a very, you know, brief time line or timetable of the history of the Committee. As early as March 2001 excuse me the Board created the Board IDN Working Group, which produced the status report of IDN in September 2001 in Montevideo. And at that time the Board created this IDN Committee as a broader committee.
During the last year, we did many studies and produced many documents, including those five. And I don't like to go through all those things. But I'd like to focus on one particular issue, which is the permissible code point issue.
As you know, Unicode is the basis of many of the computer languages. The current version of Unicode contains more than 95,000 character sets.
During the time of the study by IETF on the standardization of IDN protocols, we suggested IETF to look at this Unicode and try to limit, if possible, the number of character sets, because the current Unicode could be over-inclusive for the purpose of domain names. More specifically, we suggested to study carefully about the area of the symbols and icons and so on which are not necessary in many cases for the domain names, which may simply create more confusion if they are used in domain names.
That was where we were about a week ago.
On October 24th, IETF came out with the standard, which was their approval of the Internet draft. This is a list of those Internet drafts they produced.
And without much surprise to us, the standard, basically, was adopted as what we call the client side approach, namely, if you type in the domain names in non ASCII language, your computer is going to translate those non ASCII to ASCII and send the ASCII signal to the Internet or to the root.
And for this purpose, they used the algorithm of Unicode. And they also used some name preps and so forth on for various symbols and so on.
After this announcement, since well, there are many e mailing issues. We are about to start to consider more issues here.
As I said, one of the main concerns about expansion of domain names to non ASCII in the world is about the scope of character sets we can use.
As I briefly mentioned, the permissible code point issue is real. And this code point issue is very serious, particularly in this region. In Japan, in China, and in Korea, which we call our CJK area, Chinese, Japanese, Korean area, we have more than 68,000 characters within Unicode, 68,000 characters.
If we just use all those, you know, things, there are very similar characters or in many cases same characters expressed in different ways, like in case of English alphabet, you use the regular ASCII characters, but you may imagine the use of old fashioned characters, they read in the same way for humans, they mean the use of caret, but are expressed in different code points. So this may create lots of confusion. From the Internet community, there was a suggestion that when we are implementing Internationalized Domain Names, we may want to think about registration and other administrative guidelines where we can allow only a limited character set instead of the entire Unicode.
This leads to the second point. Currently, there are some companies who are already offering the second level internationalized domain names as a test bed.
And unless we have a good understanding of the impact on all those very over inclusive use of character sets, maybe we need tothink about how we should deal with those second level IDNs, too.
And also, during the course of our study last year and this year, we discussed about the potential non ASCII top level domain names.
Here's the question is whether and when we should proceed and adopt such non ASCII TLDs. Should we wait for a certain time until we are sure that those character sets are confirmed? That's the third question.
And for all those questions, we may need to proceed cautiously with more dialogues and coordination among registries doing both SLD's and potentially the top level ASCII domain names.
And lastly, the actual use of those IDNs is not coming yet. Although IETF announced the Internet draft, we need to wait for the publication of the finalInternet draft, which may come in two or three months. And also we have to wait for the software actually to implement those IDNs.
And for the implementation phase, we need to consider some of the user interface questions, whether those are software in your computer -- would it be open and can be used for everybody -- how it works for you in your computer, and so on.
So here are the suggestions and recommendation from the Committee.
First, because we don't have much time before businesses implement those IETF protocols, we should have a lot of public awareness and education.
Also, this Committee, IDN committee, has a very limited life.
In Bucharest, we extended the life of this Committee until the end of this meeting, and I'd like to ask the Board to consider the continuation of this Committee, and this time for indefinite time period.
Thank you very much.
Vinton Cerf: Thank you very much, Katoh san.
I'd like to I don't see questions, so I think you can sit down.
Masanobu Katoh: There's no question?
Vinton Cerf: It's very clear that Internationalized Domain Names introduce a fairly complex development in the Internet at several different levels, so we have work to do.
I'd like to call now on Barbara Roseman to make a report of the address supporting organization.
And before you start, Barbara, I want to tell everyone I am well aware that we've gone past the 10:00 scheduled break.
We will schedule a break very shortly.
Barbara Roseman: Thank you.
I'm Barbara Roseman, Chair of the Address Council.
This is the current composition of the Address Council, and recently Takashi was elected for a 2003-2006 term.
Cathy Wittbrodt will not be continuing, so she will be replaced.
These are the current ICANN directors that have been selected by the council.
We've recently elected Mouhamet Diop to replace Rob Blokzijl, and as you can see the terms are ending with the Annual Meeting.
Obviously this will have to be revised during the transition to the new structure.
We've continued to observe progress in the establishment of the LACNIC and Afrinic new RIRs.
LACNIC has made preparations to elect its ASO AC members at its November 2002 meeting.
They have three candidates now and anticipate they will all be elected without difficulty.
LACNIC and Afrinic have been involved in the current processes.
Work we're doing is establishing standard Board of directors selection processes.
We hope to have those published by January of next year.
It's been sort of an ad hoc procedure up to now, and there's discussion ongoing to review RFC 2050 and its current relation to active policy and whether it should be replaced with other documents, documents that would not become another RFC but would be taken outside of the domain of the IETF.
For anyone who is interested in participating, there is a global mailing list and there are already several working groups on the different documents.
The Address Council is working closely with the RIRs on the ICANN reform process discussions.
We're helping to lead discussions at local meetings, we've initiated discussions on the RIR public policy mailing lists.
We're participating in a task force with the ERC, and we're working on a transition plan for the new Board of Directors.
And that's all.
Vinton Cerf: Thank you very much, Barbara.
Just one observation.
There wouldn't be anything wrong with preparing a document outside of the IETF context but still publishing it as an RFC, would there?
Barbara Roseman: We've actually spoken about that, and there are complications with making it an RFC that it's actually a much it will be a more malleable document if we can keep it outside of the RFC context.
Vinton Cerf: Okay.
I'm a little surprised at that thinking and an RFC would be okay, but we'll take that off line.
Don't see any other questions so thank you very much, Barbara.
I'd like to call now on the Protocol Supporting Organization to make its report.
I'm sorry, I don't know who is scheduled to make that report, so I can't call upon you by name?
Stuart Lynn: Richard Hill is making it.
Vinton Cerf: Richard.
Richard Hill: We did send a e-mail.
It may not have arrived.
Have we got the URL?
Great; thanks.
Presentation technology is courtesy of W3C.
You can go on to the next one.
It's quite complete.
I'm not proposing to read the slides or anything like that.
I presumably posted it and people can look at it.
It's quite a complete report.
It covers actually activities prior to Bucharest, which I'll skip over.
And the point is, as you all know, the PSO is a consensus based advisory body which gives technical advice.
The members are listed here.
I'll read them out for the describe.
Mrs. Azucena Hernandez and Mr. Tapio Kaijanen for ETSI, Mr. Mike St. Johns and Mr. Geoff Huston for IETF, Mr. Brian Moore and Richard Hill for ITU-T.
Those are the duties of the PSO.
Again, I don't propose to read all of this out.
It will be posted on the Web.
And as you can see here, there's a fairly complete list of activities, but there was a complete report in Bucharest so I will not repeat those.
You can skip to the next line.
I'll focus on the main activities after Bucharest.
There was a discussion of an application from the International Standards Organization, ISO, for membership in PSO.
However, there was not consensus on that application so the application was not accepted and ISO was not admitted.
The PSO noted that under the rules which established the PSO, which is a memorandum of understanding between the four organizations and ICANN, that ISO could appeal the decision to the ICANN Board.
Also, we had set a deadline for nominations for election to the ICANN Board of directors, but no deadlines no nominations were received on time so we extended the deadline.
We had a smooth transfer of the Secretariat from the ITU-T to the W3C and we moved the website and the mailing list.
There were discussions on the Evolution and Reform Committee.
The PSO as such did not comment, but indivudal organizations did.
All those comments have been posted to the ICANN public comment web site and are available there.
And following the nomination process, there were two candidates for the ICANN Board, two nominees, Francisco da Silva was elected by the PSO and will join the other two directors from the PSO which are Vint Cerf and Helmut Schink.
And that concludes my presentation.
Vinton Cerf: Thank you very much, Richard.
Richard Hill: No questions?
Vinton Cerf: I don't see any questions so you can stand down.
With everyone's concurrence, I think I will try to complete the domain name supporting organization report which I assume will come from Bruce Tonkin, and then we'll take a break.
Bruce Tonkin: Thank you, Vint.
The Names Council of the DNSO met yesterday, and I'll just run through a few resolutions that were made in the meeting yesterday, and then briefly comment on progress that's occurring in the major task forces.
In terms of the resolutions, there were several resolutions that relate to the ERC reform process.
The first of those resolutions relates to the structure of the new GNSO–. It was a resolution that the GNSO Council should have three representatives per constituency, that this situation be reviewed 12 months after the formation of the Council, and the efficiency of the Council be reviewed at that time.
The second resolution also relates to the GNSO, and that is that the Names Council resolved that any variation from the principle of equal stakeholder representation and votes in the proposed Council shouldn't change.
The third and fourth resolution relate to some of the issues that have emerged over the updating of name servers at the root level and general DNS data quality issues.
The first of those is a resolution that the Names Council recommends that the ccTLD managers and the ICANN Committee for Security and Stability with input from the ICANN staff performing the IANA function jointly develop procedures that interface between the IANA function and the ccTLD managers that will include the quality of the data at the top level and that answers the question raised earlier that part of that will be looking at emergency or fast track procedures in event of emergency to update name servers.
The fourth of these resolutions is a bit more general than that and it's looking at DNS data quality, not just at the root level but also throughout the DNS.
And that's in response to a letter that the Names Council received from Dr. Stuart Lynn and Dr. Vint Cerf regarding delegating or requesting the ICANN security committee to review that.
The Names Council has resolved that the Board should ask the Committee on Security and Stability to work cooperatively with the ICANN staff in performing the IANA function, the TLD managers, and registrars to look at important procedures for improving data quality.
And that's not just a design flaw, but it includes Whois data quality.
There was procedure resolution that was just that the chair of task forces no longer needs to be a member of the Names Council, and that's also consistent with the Names Council policy assistance group recommendation as part of the ERC reform process.
Another procedural issue was the approval of a terms of reference and process to look at the deletes issues within gTLDs, and that issue is currently open for public comment.
And then just moving on to the issues of task forces.
There were discussions around two major task forces yesterday, being the Transfers Task Force and the Whois Task Force.
I think, first of all, I'd like to thank the members of those task forces that have really put in a massive amount of work to deal with quite difficult issues.
One of the things that's now emerging is how to actually implement the conclusions and the recommendations that have come from those task forces and what are the differences perhaps between a traditional government regulation where a new law is created and the population needs to abide by that law, the ICANN structure is based on contracts and so we have contracts with registries, contracts with registrars.
So even after a process of looking at improvements at a policy level, we still need to think about the practical implementation of those, and in a normal sense contracts require agreement from the two parties in an individual contract, and that becomes quite complex when you start dealing with multiple registries and hundreds of registrars.
So I think that's one of the issues ICANN needs to start looking at, is what is the most effective and efficient way to manage the output of the work of the policy council, the GNSO, into the future, and how to properly incorporate those developments into the contracts.
One of the issues that starts to come out also from the task force is the difference between the policy decision and providing detailed implementation information, and we certainly see that the task forces have done a huge amount of work to the point of specifying how to actually implement policies, and we need to just do a little bit of a review of that work and identify the higher order issues that we want general agreement on and then allow some flexibility for the registries and registrars to implement those policies.
One of the things that have become quite clear in the issues of transfers is it's quite clear that the registrant needs to authorize any changes between registrars, and the big issue is what's the most effective way of ensuring that the registrar has properly authorized the transfer.
In the area of Whois, what we're seeing is there's general agreement that the accuracy of Whois needs to be improved by any attempt to improve the accuracy will not be helpful unless we (inaudible) because (inaudible) do not place accurate information in Whois because they're trying to minimize the use of their information for other purposes.
Some of those issues also come into searchability.
While searchability and improvements are welcomed by many, they're also feared by people from the privacy point of view.
So we need to look not just at accuracy but at the same time look at access control.
So those are Whois has become a very complex issue and I think we've identified that we're not going to solve it in this short number of months, and the process will now be to prioritize, identify where we have consensus now, and use venues like the IETF to develop standards, that should take a number of years rather than a number of weeks.
Finally, I'd just like to report that the ccTLD constituency has ended its involvement in the present DNSO as of yesterday and I'd like to thank the contribution of the ccTLDs to the DNSO and in particular the present members of the elected members to the Names Council which were Elisabeth Porteneuve and Peter de Blanc who died earlier this year also made a contribution.
Vinton Cerf: Those are extraordinarily thoughtful recommendations and they are extremely timely with regard to accuracy of information and dealing with privacy issues and the like.
Stuart you had a very, very brief thing that you wanted to put up on the budget schedule for 2003 2004, so if we could do that now, then we'll take a break.
Addendum to President's Report
Stuart Lynn: Thank you, Vint, that's a very brief comment that I forgot to make in my presentation.
The budget schedule for the next financial year, 2003 2004, is delayed because we need to integrate with it what's going to be done on reform and how to integrate it with any transition planning towards reform that will occur between now and December 15th.
That schedule will be proposed and posted shortly.
It will lead to a preliminary posting of the 2003 2004 budget sometime in the February time frame.
Some have asked will there be a Budget Advisory Group.
The answer is yes.
What I will state now, because I know there are many views on this, is that the future of the budget advisory committee is something that the Finance Committee has advised me should be factored into reform planning.
And so the current structure that's used in the past year will move forward, but we hope as a part of the process to invite people from other than the funding constituencies to help provide input into that budget process.
I hope very much that those constituencies and some organizations that have budget questions or concerns or things that they want to factor into the thinking, there's no firm deadline on that but the earlier you get any thoughts and comments in, please send them to me if nowhere else.
But the process itself will start more in earnest alongside the December 14th 15th meeting in Amsterdam.
Thank you very much.
Vinton Cerf: Thank you very much, Stuart.
We'll take a break now until 10:45, which I will remind you will put us exactly an hour behind.
(break)
Vinton Cerf: We're way past starting time, and I see I have a number of absent without leave Board members. So if you see a Board member who is not up on the stage, would you kindly send them in this direction.
Well, in spite of the fact that we seem to have a dearth of Board members here, I think I am going to reconvene this meeting.
And that's a great idea. We've now automatically reduced the size of the Board to one, two, three, four, five, six seven members.
Well, eight. So I will officially reconvene the meeting now.
LACNIC Regional Internet Registry
Vinton Cerf: And I'd like to call upon Ray, are you making this report?
No, Raul is. Make a report on the current status of LACNIC. Our newest RIR.
Raul Echeberria: It works. Good morning, everybody. My name is Raul Echeberria, chairman of the Board of LACNIC.
I am here today to present to you, to the community, to the ICANN Board and staff the report the final report of the transition process of LACNIC.
Some of you may surely most of you were in ICANN meeting in Accra, Ghana, last March, where we got the provisional approval from the ICANN Board. After that, we presented, together with ARIN to the ICANN president the plan for the final steps of the transition. At this moment, we are finished with this plan and pleased to announce that we have achieved all the objectives that we included in that plan.
I make I will make a brief statement about the LACNIC process for those of you who don't know the history of LACNIC.
After that, I will make a short report about the transition.
LACNIC was created in 1999 in the timeframe of the ICANN meeting in Santiago, Chile. It was founded by the six most important stakeholders related with the Internet community in Latin America.
During 2000, we decided to incorporate LACNIC in Montevideo. We decided to take advantage of the expertise of the two countries, Brazil and Mexico, where there were national registries and IP addresses.
We signed agreements with the Brazilian and Mexican registries.The agreement signed with the Brazilian registry recognized that they are supporting all of our operational activities in Sao Paulo in their facilities. They are in charge of several hostings, the web servers, all the engineering aspects related with the software, and the Whois, and all the registration services.
Because the agreement signed with the Mexican names registry recognized that they are supporting us in all of the activities related with training activities in the region.
In 2001, we have maybe one of the most important meetings with the staff in the United States, July of 2001, where we agreed the first draft of the transition plan.
In November of 2001, ICANN formally acknowledged our application, the application submitted by LACNIC for its recognition.
And as I said before, we got the provisional approval in Ghana early this year.
And now we are in Shanghai, ending this process, and expecting to have the final recognition from ICANN.
In accordance with this plan, from the 18th of November, LACNIC will be absolutely independent.
(applause.)
Raul Echeberria: Thank you.
So we have speaking about outreach activities, we have organized three two public policy meetings. One of them, the first, in December of 2000 in Buenos Aires, the second in Sao Paulo, and in a few days, we will have public policy meeting in Mexico City, number three. Of course, all of you are invited.
As I said before, it's a way we started our transition activities in 2001 where we have the first draft of the transition plan.
As the first activity, we received training for our technical staff. We sent two persons in August of 2001 to be trained.
From November 2001, we started to analyze all the requests received by ARIN from the LACNIC mission. So this year, we have had a lot of activities related with the transition process, not only related with technical aspects, also related with the business planning and business coordination. We had two meetings in Montevideo, in February and June, where some of the ARIN staff participated in important business issues.
From July, in July of 2002, we received the database transferred from ARIN. We started to provide services of address resolution and Whois services from our own servers.
We started in last September all the invoicing activities.
We received the final visit to our staff in Montevideo and Sao Paulo, the people from ARIN to review all the things that have been done.
So before this also in 2002, we sent our business manager to ARIN's headquarters to receive training about the business issues
required in this process.
As you can see here in this graph, we started in November 2001 to evaluate all requests. But these requests were received by ARIN, and the templates used were the ARIN templates. And we applied the ARIN policies, and the locations were decided by ARIN also.
And all the records in the database were under the ARIN responsibility.
In July of 2002, we started to provide the services through our oversight using our old templates. We started to receive the requests, made decisions about the locations.
We still continue working with the second opinion of ARIN after we decided the allocation.
Following some of the requirements included in the transition plan presented in last June to the ICANN presidents, we have here a database snapshot received from ARIN. It was done.
The joint announcement of progress of transition plan was done.
The registration records imported into LACNIC database was done.
LACNIC Whois designated primary for LACNIC records was done.
Change to LACNIC policies. It will be done next 18th. We have our as I said, we have our policy meeting the 11th and 12th of November. We will approve the our own policies. We will continue applying the ARIN policies until this date.
Then we are sure that we always will have policies to be applied.
We will stop working with the ARIN second opinion also in next 18th of November.
Identifying LACNIC servers was done, set LACNIC as secondary was done, set LACNIC as primary also was done. The transfer of authority will be done next 18th of November.
All the aspects related with the administrative issues and business and accounting, all the tasks that was planned was done.
We will stop the wire transfer between ARIN and LACNIC also next 18 of November.
We have some statistics of the first phase that finished last 27th of July. This is the resources that we have analyzed and approved and denied.
The numbers corresponding with this last phase of the transition process.
We have produced documents that are available on our web site, agreements, registration service agreements, templates, letters of support received from the community, registration policies, several documents pertaining to RIRs.
Our funding now, we have adopted the same fee structure as ARIN. During the transition process, we have worked based on sharing of the revenues, getting the 35% of all the income corresponding with the registration services to companies that belong to the Latin region.
Our 2002 budget is available on our website. And we are working now on the budget of next year that will be available in the website maybe next week once approved by the Board.
LACNIC III is our next meeting. All the information is available on the website. It will be very nice to see some of you there.
To finish, I have to say gracias, thank you. But I'd like to say thank you to the other RIRs for their permanent support, to the ICANN staff for the support and guidance provided, especially to the ARIN staff for all the energies dedicated, and to Ray Plzak for his valuable contribution and his great friendship.
I'd like to pass the floor to Ray. Maybe he has some important views to share with us. Thank you.
(applause.)
Ray Plzak: Just allow me to bring up a short presentation.
Mr. Chairman, I am going to provide you with a final report, which is the ARIN assessment of LACNIC.
And I am going to address two areas of assessment. One is the structure of the RIR and second the activities and functions.
The general structure of an RIR is that it's a not for profit membership organization. There is a specific funding model that we all follow. And we also do policy development.
LACNIC has done all these things. Their membership is open to all interested parties. Their membership will elect their Executive Board. Their membership approves their activities and budget. And based upon our observation during the transition period, where we were forming a second opinion, they are conducting business in a neutral and impartial manner.
They will follow the same funding model as the rest of the RIRs by charging annual service fees. They will not charge per IP address.
And their financial reporting is open. As Raul stated, their current budget is available on their web site.
And in policy development, they will do the same as the other RIRs. It's going to be developed by the industry in their region.
And it will be a bottom up open policy process.
Briefly looking at the activities of an RIR, it is to provide support to the ICANN and ASO, perform outreach activities, and also do coordination.
And the functions that are performed by an RIR are address space management, policy development, and reverse DNS. I will now go into these in a little bit more detail.
With regards to support for ICANN and the ASO, LACNIC is fully committed to fund, in their appropriate share, the ASO secretariat. As members of the Board are aware, all of the funding for the ASO comes from the RIRs. And LACNIC has signed up to do their fair share.
They will also be participants in setting aside funds for ICANN support. We have a method between the RIRs of how to divide up our share of the budget. And they will fully participate in that as well.
And lastly, to show that they are fully committed, they have accepted an invitation to the ASO council suggesting the next Assembly be conducted at the LACNIC meeting in Santiago, Chile.
In terms of outreach, I won't go into lot of detail, but they have had meetings, they do various presentations to interested parties throughout their region. And as Raul mentioned, they do have training programs.
And they have been active in participation with the other RIRs in coordination of activities with the RIRs and registration services.
They have been very involved in engineering efforts.
There was, for example, earlier this year, in Toronto, in conjunction with a NANOG meeting, a joint RIR/engineering meeting for two days. And LACNIC was a very active participant in that as well.
And they also do these other activities that I show here.
In regards to functions, address space management. They have been processing requests for over a year. I will state categorically that in terms of the second opinion that's been rendered by the ARIN staff, that we have never come across an instance where they have made a mistake. So they know what they're doing.
In the area of terms of policy development, as Raul has indicated, they have had two previous public policy meetings. The next one is in Mexico City.
They do have an active mail list.
And I will make a point here that on their mail list not only do you see the proposals being presented in English, but you also see them in Spanish and Portuguese. And sometimes the first iteration is in English, sometimes the first iteration is in Portuguese, sometimes the first iteration is in Spanish. But within a day or two, all three languages are presented on that mail list. I think that's a very commendable thing, and it's been working very well.
And they have organized several working groups, and they will be in action at the upcoming meeting in November.
In regards to reverse DNS, they are providing it. They have the primary servers. ARIN is currently the administrative control of those domains. However, in November that will transfer to LACNIC.
I will also point out that we have executed or will have completely executed by the 18th of November a series of transfer documents which will show the continuity of the address space, moving from the ARIN database to the LACNIC database. The business and accounting records pertaining to the LACNIC members will be moved and accounted for in that manner. And also the transfer of the zone file itself will also be formally accounted for.
I would like to say a thank you to the ARIN staff.
Raul mentioned that and you were able to see for yourselves -- that there were a lot of people involved in this. And, actually, the entire staff of ARIN at some point in time has been actively engaged.
I would like to say a thank you to the ARIN staff.
So the first person I'd like to acknowledge is Richard Jimmerson, my Director of Operations.
He has been very involved in the process, particularly from the policy aspect.
Mary K. Lee, Head of our Department of Administration.
You wouldn't think that you would have to have an administration interface, but basically we did that as well.
Bob Stratton, our Business Manager, and Ginny Listman, our Director of Engineering, Susan Hamlin our Director of Member Services and Leslie Nobile Director of Registration Services.
Mr. Chair I would like to note we call our management team the "amigos" and we have a mailing list as well.
Lastly, a few final notes.
First of all, I'd like to say something about Afrinic.
We are as fully committed to the establishment of Afrinic as we were in committed to the establishment of LACNIC.
To that end, ARIN has provided a letter of support and was it was provided in four languages, English, French, Arabic and Swahili.
(inaudible) is the mentor for Afrinic but the remaining RIRs have pledged their support and will do what is appropriate to make sure that Afrinic gets off to a good start as well.
Lastly I would like to thank my very good friend Raul.
We have been through a lot together, and there have been some meetings where we may have had disagreements but when we ended the day we were in a bar someplace having a beer and commiserating.
So Raul, thank you very much.
And so thank you, gracias, obrigado.
(applause)?
Stuart Lynn: Thank you Raul and thank you Ray.
This is a very happy occasion.
And as part of this occasion, Raul and I are going to sign a document in your presence, a document that I will tell you does not become effective until tomorrow when the Board of Directors will issue a proclamation recognizing this occasion.
Although I technically have the authority to enter into this document by virtue of previous Board resolutions, it's of such importance and such a major step forward that we all want the Board, should they be willing to do so, to issue a proclamation recognizing the change.
Before going into this document, let me just emphasize one thing.
I think the work between ARIN and LACNIC has been a model of cooperation that has worked extraordinarily well and has been the most critical part of leading to this particular situation.
So besides congratulating LACNIC on its birth, and ARIN on the role that it played in helping to make that happen, let me, as President of ICANN, acknowledge that this is an extraordinary event and one that I hope will set the stage for other similar events in the future.
So let me read to you if I might a view of the importance of the occasion.
If Raul is still willing, we're going to sign.
This is the Joinder of Regional Latin-American and Caribbean IP Address Registry (LACNIC) into RIR-ICANN Memorandum of Understanding
Recitals:
In October 1999, an Address Supporting Organization Memorandum of Understanding (ASO-MOU) was entered by the Internet Corporation for Assigned Names and Numbers (ICANN), Asia Pacific Network Information Centre, American Registry for Internet Numbers, and Réseaux IP Européens Network Coordination Centre.
The parties entered into Amendment 1 to the ASO-MOU.
The ASO-MOU as amended allows additional Regional Internet Registries (RIRs) to join in signing the MOU after they have been approved by ICANN.
On 28 November 2001, the Regional Latin-American and Caribbean IP Address Registry (LACNIC) applied for recognition as a new RIR in the region of Latin America and the Caribbean.
On 14 March 2002, the ICANN Board gave its provisional approval to the LACNIC application for recognition and transition plan, subject to submission, in consultation of the ICANN President, of a revised application for full recognition of LACNIC in conformance with the criteria set forth in ICP-2 and the ASO-MOU.
A revised application submitted by LACNIC has been determined to be in conformance with the criteria set forth in ICP-2 and the ASO-MOU, and has therefore been approved by ICANN.
Therefore, it is agreed:
ICANN hereby approves LACNIC as a Regional Internet Registry eligible to sign the ASO-MOU as amended.
LACNIC hereby enters into and joins the ASO-MOU as amended.
LACNIC's joinder in the ASO-MOU shall become effective upon its proclamation by the ICANN Board.
As I mentioned, the plan is for that to happen tomorrow.
So this is to be signed by both Ray and myself Raul and myself, sorry.
I think it's a prerequisite for a director of address registries for their names to begin with r a, at least in this particular part of the in the American part of the world.
So with that, after that long proclamation statement, if Raul is still willing to join sign this statement, we will sign several copies, and there will also be an event taking place at the LACNIC meeting on November 11th and 12th in Mexico City.
Raul, are there any comments you wish to make?
Raul Echeberria: No?
Stuart Lynn: Just sign; get it done.
(laughter)
(applause).
Vinton Cerf: Well, that certainly I'm sorry, Alex, you had something you wanted to say.
Alejandro Pisanty: I will make a very brief comment at this point in time to underline for those people who are not following the address community and the addressing proceedings the Board has given to names that this is a major landmark for many here.
It's a major landmark for ICANN; it's a major landmark for the addressing community; and it is a very significant landmark for Latin America.
Very often, the first layer where you have to build trust is the most difficult one, and that is in developing countries, and not only there, but building of trust among people of different nationalities, from widely different cultures, for distances, for geographical distances which are far larger to bridge sometimes than the ones in the north.
Those of you who attended the Montevideo meeting have suddenly realized that the distances within Latin America are much larger than those that separate parts of Latin America from parts of the rest of the world, and those within many of the developed regions of the world.
And we many of us see this with a very favorable impression.
I'm a witness of the trust building labor that has taken place for years within this process, and I also see great encouragement for these examples to be followed by Afrinic as soon as possible, and find it necessary to underline these things for, again, those who could not be fully aware of the effort and significance behind this moment.
Vinton Cerf: Thank you very much, Alex.
Nii.
Nii Quaynor: Yeah, very brief.
On behalf of Afrinic, we would like to congratulate LACNIC for having been through the tough process, and at the same time, we really appreciate the example of the support that they receive from ARIN and the rest of the RIRs, and we are looking forward to also following the good example that has been established by LACNIC, and hopefully soon Afrinic will also be going through that process.
Congratulations.
Vinton Cerf: Amadeu.
Amadeu Abril i Abril: Very shortly.
First of all, indeed, congratulations.
And secondly, encouragement to keep the good work going ahead.
And just two very small things regarding Raul's presentation.
The first one is that I hope that, despite what you said, you perfectly understand that complete independence doesn't exist anymore today for any activity, and even less in the Internet.
You have formal independence, but I hope that you will keep the tradition of very close policy and managerial relationship with other RIRs within ICANN.
And the last thing is a problematical question.
Now that you have a LACNIC, perhaps you should improve your mapping because you put Santiago, Chile between Ecuador and Lima, Peru.
Raul Echeberria: They are not comments about Amadeu's comments.
I would like to thank you for all your comments and applause.
I'd like to say also that I'd like to share this moment with all the LACNIC Board members who are here present, and they are obviously a great part of this moment and this process that we are ending now.
Then I'd like to applaud them.
(applause).
Raul Echeberria: Thank you very much.
Vinton Cerf: Thank you very much, Raul.
It's very exciting to see the outcome of such a cooperative effort.
I hope we will all keep in mind this milestone as we try to cooperate together to reform ICANN, which is the subject of the next part of our Open Forum.
So I now call on our Vice Chairman, Alejandro Pisanty, to begin the presentations of the Reform and Evolution Committee.
We have several scheduled comments after his presentation, beginning with the GAC, Paul Twomey, and after that there will be an opportunity for open comments from the participants.
Alejandro Pisanty: Forgive my eyes for this delay.
I am getting to an age that Bill Gates has not come close to yet, and facing some problems that he will surely solve as soon as he's over this threshold.
(laughter).
Alejandro Pisanty: I will try to keep this presentation very contained in time, if not in content.
I will not go into a formal, full description of the bylaws, policy development process and several other formal documents that have been set in front of the Board and that have been before the community for a long time.
I will also, this time, try not to gain a few more seconds by speaking too fast, and I know of these two persons in this room who will thank me for it.
I'll start with a very slight personal detail.
My mother, after traversing Europe in refugee camps in several different countries before and shortly after 1945 and '46 went to Mexico with the luxury of speaking five different languages and became a translator and interpreter, and her memory should give me both for the effort that it takes to absorb the speech of a person in real time, especially with the pronunciation of someone that doesn't have this language as mother language.
I will go through this presentation with the purpose mostly of outlining the major tasks, a few of the procedural aspects as well as going to the substantive discussion.
This presentation has two different audiences, and I hope I am reaching appropriately to each of them.
One of them is the Board which is basically aware of the whole process, has been engaged in collective and individual discussions about many of the issues, but will have to face very important decisions tomorrow, and trying to not hide some of the difficult points we are still facing and that the Board will face as a whole.
On the other hand, there is the public, the audience here and online, which is watching and following this session by webcast and, as I said, face to face present here.
And we need a very thorough and intense session, as I am sure we will have, of discussion of the different aspects of this reform process.
I am not in any way trying to lead the discussion.
I would love to be able, in this community, to lead anywhere, but the community does not want to go. But I will certainly try to give ample room for the recognition of both the issues that we think are basically ready to be settled and those that still need some hashing and reworking
It is unfortunate, as I will quote in this chase, Lyman Chapin, one of our very appreciated and distinguished Evolution and Reform Committee members who said this morning that it has not been possible for us, humanly and materially possible for us to keep separate track of each comment received and the consideration it was given and the response that it was either given directly or for and against dialogue or in the form of drafts, bylaws language and so forth.
But this has been a very intense and extensive task.
In the presentation, I will go briefly over the process, make a general description of what we are facing.
This is not exactly an index but a general description of the presentation itself.
I will be speaking about what we have done about the focus and effectiveness of ICANN, what we have done about transparency and accountability, participation, relations with key stakeholders, and will address those problems that were identified initially by Stuart Lynn and agreed upon by the community as being some of the most significant ones for ICANN.
And then I will point out some of the controversies and types of controversies we are still facing and we have to face, the most intense ones, but there is no space in human-built laptop for the record of the whole set of controversies that have taken place around this process, and some keep going on, and then closure for the presentation.
The process we followed, it actually has roots a little bit further back in the past.
We have the DNSO review process that was started a rather long time ago in ICANN historical times.
Several questions were being raised about major changes in overhauls and procedures.
Some of the processes that had been started before ICANN was established like work group "E" of the DNSO, things like that that kept going on and that have given rise to different considerations.
But certainly the review of problems that was made by Stuart Lynn in his document, in his paper, the case for reform, was a milestone in this process, a very significant review of the problems from someone who had been an outsider and had become an insider in the process of ICANN and the working of ICANN, who had with great honesty and courage analyzed and set out the problems.
Stuart, very courageously, said from the start this will be something that costs a CEO's head and mine is up for grabs, basically.
I'm not advancing a career or anything like that with this, so it was amazingly honest and frank.
And I have to express publicly my admiration for Stuart for the stalwart manner in which he has taken this process.
He has taken incredible levels of abuse, of insult, of expressions of mistrust.
Most of the people I know, even the cooler headed ones with 100th of what has been piled up on Stuart, have just found some elegant and chivalrous way to quit, and I have to find a way to express this admiration to you, Stuart, publicly.
I will talk to my conscience later because there are other issues on the agenda.
The Board established a commitment for ICANN evolution and reform, it has been going on with its work for some time.
This is a Board committee, so it is formed by four directors, originally five; sometimes by the level of output and traffic that we have in teleconferences and mailing lists, you wouldn't think these people sleep and you would also need to consider that my colleagues in the Committee, as well as myself, have families to feed and jobs where the income comes from.
We are not engaged in any form of substance traffic or anything that's highly profitable.
We still fulfill full time jobs during the rest of our lives.
And this is to underline the fact that this is a group of volunteers but not of amateurs.
The fact that sometimes we will explain away the lack of timely responses or the lack of structured documents and so forth by the fact that this is volunteer work does not mean that it is amateur work.
We devised a procedure very early on of ongoing dialogue with the community.
In doing this, we have been aided enormously by the assistance of Stuart himself, of Joe Sims, of Louis Touton, Theresa Swinehart all who have helped us keep track of things, put up documents, find methods for dialogue and work with the community.
We believe that one of the most successful parts of the process in eliciting out comments, making them valuable for the Committee, was our method of putting out drafts which had structured questions which elicited specific responses which allowed people to go beyond paragraph one; that allowed people to know where, in our view, were the most substantive issues that had still to be decided, and that still allowed us to have the community still gave the community a very free format and a very open agenda for comment.
We had interactions with all parts of the ICANN community.
It's easy for everyone in each part of the community, whether you are in the cc world, in the GAC, in the IETF or technical standards organizations, or in the Names Council or the names community and the addressing community, it's easy to forget how important issues seem to others that are trivial to us.
And it's even more difficult to take those and the issues that seem life or death issues for some of us might be considered trivial or mechanical or something someone should solve outside in the corridor and come back with a draft from other sides of the community.
I have learned very much of the scale of problems and the relative and layered scales of these problems.
We have had these interactions with the community.
We have been listening and reading and talking, and in conversations, getting further and more elaborate responses to the things that needed to be done.
We have been processing these responses individually and collectively.
Sometimes, very often, we have been asking again for clarifications for expansions, for alternatives and opened our ears to listen to this.
We have been aided in the latest stage of the process by assistance groups who have generously contributed time and effort and high quality of thinking to produce the policy development process and a few things like that, which you have been reading.
And we have been able both to see what are the developments, the parts that develop fast, and the real tough sticking points on which advances are hard to make.
I will explain in a few more words in a moment process, key stakeholders, funding.
The solutions that have been embodied as a whole, and now are for Board action in the draft bylaws, look more or less as follows.
For the problem of better relations, more buy in, more organic participation of the different stakeholders, which are basically listed as governments, RIRs, ccTLD community, the gTLD community, and the community at large, users, and even within the user community we realize that there is still an ongoing discussion.
I mean, there's a number of e mail lists out this week where there still are people fighting it out whether it should be all individual users of the Internet or only domain name holders that participate in these processes. Still on that side of the community we have an open field.
Second, to address this problem of buy in and relations with the stakeholders, we went to the structure, which is a very basic part of the whole reform process; to make a structure that treats each part in a differentiated way, in a way that's appropriate, that is an evolution, significant evolution from the original structure of ICANN, which have foreseen more equal treatment for, let's say, the addressing protocol and names communities and supporting organizations.
In this structure, we have established based on this structure, we have established -- processes.
We have focused as much as we can for now, and we will have to develop even more as time goes on, the processes, the physiology of this system, the way it works.
It's not only the structure.
You can have ideally a perfectly balanced structure, and if these people are not working in a cooperative way or in a way that leads to results that are in the way you need to produce them and the way you need to operate, you have nothing.
So the processes we have established are intended to provide increased stability of the organization, increased predictability where you need it, and openness where you need it, and to invite trust.
As a specific example, I would say, for example, that we have strived that the processes in the generic names sphere are self contained enough, enough incentive for results et cetera, and in that sense invite a more active participation and a deeper trust from, let's say, the addressing community.
These are not negotiations where there is give and take.
This is not like moving the voting rights from one part of the Names Council to another or the balance there, but it's like encapsulating parts of the organization in such a way that other parts of the organization don't feel threatened by the fact that the Board attention will be consumed in attending to the processes within the part we intend to encapsulate.
We have intensified in the process and in the structure the interactions that take part among the different parts that have to take place.
This means, for example, that in the policy development process for the GNSO, we have several points of contact between different types of participants; that we have, for example, GAC liaisons in several parts of the process, we have at large advisory committee liaisons in specific points of the process and so forth, so we make sure that there have to be these interactions.
And we address the problem of trust twofold, and that is something that we have, in the second part, we still have a lot of work to do.
The first part, of course, is trust in ICANN; trust the Board, trust the Councils, trust the whole organization, trust the fact that the MOUs with the USG will possibly be continued, opened in certain specific ways, et cetera.
.
But there's another issue that we have been discovering again and again which has been, in the pre ICANN days since the '80s, which is significant challenge, if not lack of trust, among participants.
I would maybe caricaturize this only by saying as example as I already implied that by saying that the addressing community doesn't like to come too close to what they see as messy and noisy processes that are needed in the names sphere. I will only use these two, but if we drew all five in the vertices of a pentagon, you would see that the lines of mistrust include all combinations.
We have to increase that level of trust. And it's not a structural, not even a procedural problem, but still the Board, and in particular, by elevation, in this period, the Committee, have been set up in a difficult way, because we very often have had to provide a go between to act as a go between between different parts of the community that don't trust each other.
And the lack of mutual trust is reflected in the form of reduced trust in the Committee, in the Board, and in the whole structure.
The problem with process, as outlined by Stuart, and I think that the community should not forget, this is not only that there were problems with ICANN's processes, but that the community and the work of community was literally obsessed with process, that endless discussions took around procedural matters, not only that the procedural matters were difficult to solve, but the discusses about how to proceed were going to meta levels that were the incredible complexity and slowness.
So we have tried to address this with well defined processes, incentives within these processes, development of policies for ICANN decisions can be done within specific times, with productive objectives, with well elaborated results that hopefully the Board can one day just sign and stamp. We have transferred as much of the process to the bottom up side within the supporting organizations.
We have tried to provide safeguards for transparency, accountability, and fairness. In practical terms, in realizable terms, and taking an evolution from the already existing experience. And we have provided cross links, liaisons, et cetera, that will allow things to develop early in a collaborative way between different parts of the community that need to collaborate, in order for the procedural problems not to become a stopping point, too late in the development.
The funding problem seems to have become the less insoluble one, not to trivialize it. But ICANN is definitely understaffed. It's definitely underfunded.
However, the proposals that we are making to increase the size are very modest, seem to be available within the present rules, and could particularly be less contentious if we are engendering the financial support through larger levels of trust in the organization.
Very briefly, I will come back to the process of the committee by saying by stating the numerous forms it took in interaction with the community. There have many things that have been answered in indirect ways. We should have, we could have, we would wish to have, but we couldn't materially reply to each person.
Your idea has been mixed with such and such other persons or groups' ideas, and brought up in the form of something that by now is in the draft bylaws.
We have also have two tasks. We have emphasized over the months the fact of listening. But listening is not enough. Listening is done in different cultures, in confessionaries, it's done in parties, in bars, bartenders are charged with listening.
We were not charged only with listening, and we were certainly not charged with serving drinks, but to deliver a different product. We had to deliver something that the Board could decide upon, after extensive discussion with the community, which would involve tradeoffs, which would involve unpleasant decisions, which would involve denials or refusals to requests.
And we have done this in analytical, critical, and synthetical approach, a approach which takes in regard many different balances I have already mentioned.
We have been very careful in putting bounds on ICANN. We are the first interested in not having more and more things to deal with, which will deal with more meetings, more trouble, more times away from our jobs and families, more, more, more weight set up on the Board and on the rest of the community.
The possibility of mission creep is always out there. It has been outlined again and again, even in the last week or two, by very thoughtful papers by different thinkers in this field.
There are very little incentives for each individual ICANN Board member to allow mission creep. But in institutional theory, there is some incentive for mission creep. In fact, there are friends of mission creep all along the community. It was pointed out some time ago, for example, that in particular, it was very striking in the public forum in the Accra meeting and was underlined by Amadeu to some of the participants that they were saying cut all mission creep so you can attend to my parcel. Stop mission creep. You only have to care about competition in the markets. Stop mission creep. You only have to consider not stopping free speech on the Internet. Stop mission creep, but remember that public policy is made in governments and you have to address it within ICANN. And so forth.
So there are a lot of friends of mission creep. It must not be so creepy.
(laughter.)
Alejandro Pisanty: We have tried to establish enough deterrence to mission creep in the mission statement, in the core values. We have had endless conversations which sometimes get into the Byzantine about the value of the objective "necessary" versus "relevant" versus many other versions. All of them are subject to can be subjected to subjective decisions and subjective evolution.
We have thought with this in the bylaws for the moment, for the lack of a better alternative and for the general understanding that it does not mean go as far as you can. It means only go as far as you need.
Further out, we have been emphatic in all our documents that when we speak about policy, we speak about ICANN policy, as you speak in each of your organizations of company policy or organization policy guides for general, guides for decision making, general guidelines that reduce the arbitrariness of decisions that reduce the ad hoc characters of decisions within ICANN, not public policy, not public works policy, not transportation policy, not switch policy, not environmental policy. Just those guidelines that allow most decisions that have to be made by IANA and other operational parts in a close to mechanical way with a single, predictable result, because it's not ad hoc.
And we have established as much as possible checks, balances, and bounds which, of course, elicit the immediate response, "Hey, guys, you made an excellent work of building a complex organization. It was supposed to be simple." Yeah, simple. Executive means you have president and CEO, master of a small bunch or large bunch of flakes, maybe in a hierarchical structure. You want checks and balances, you get complexity. You want safeguards against mission creep, you get complexity. You want safeguards against any other of the things that of the things that can go wrong, like invading public policy areas, like any other thing, you get more complexity.
We think we have reduced this to the minimum possible within the constraints. The procedure we have now is a draft set of Bylaws which sets up a Board structure and rules for filling it and for its operation. We have a Nominating Committee to designate a part of the Board which has structure and rules. We have a GNSO structure, we have a policy and most of its rules, we have a specific paper on the policy development procedure which was developed by the very generous contribution of time, effort, and especially quality thinking by Rita Rodin and the assistance group.
Separately, a framework for accountability and transparency which was developed by Becky Burr, again, very conscientious and thoughtful manner.
We have, for other areas of development of ICANN reform, established an assistance group to help with the implementation with the writing and the structuring of the Bylaws that should establish the ccNSO, the Country Code Names Supporting Organization.
It has had very tough discussions with the rest of the ccTLDs, it has done admirable progress in understanding and separating the issues that have to be addressed in structuring them in time and effort, and in producing a framework which will reduce the need of right now and forever deciding what is global and what is only local in ccTLD policy, ICANN policy decisions.
We have a task force that's working intensely on coordination and consultation with the regional Internet registries. We have met for about for a total of about eight hours now this week. And we are still seeking looking forward to further interactions, profiting from the fact that we are all present here.
The IETF has published comments for the protocol numbers arena, let's say the inheritor in the minds of many in the function that was originally foreseen for the Protocol Supporting Organization.
A lot of input has come there also from representatives. They have done an admirable job of making us understand what is at stake and what each party involved here is expecting.
And we have worked as much as is possible with structure and the interactions, especially, of the Governmental Advisory Committee. The interaction has been intense. We have had very good advice from them.
For a body that frequently says that they have to have longer times and more structured forms of action, we are very impressed and grateful for the promptness and the Internet time in which they have been acting. And I am very thankful, therefore, for the effort.
And, of course, we had been expecting and now analyzed and subjected to the interpretations of our own oracles, as usual, the GAC communique.
But I come now to the more hot, sticky points, which are the controversies.
The first question one would ask oneself is, I mean, would there not be any controversies about the issues here?
The scales and the gravity of these controversies vary. Many of them could be seen, you know, as endless because there's the word "enough" does not exist in the vocabulary of some of the parties that take part in these controversies.
I will reduce this to simple examples and also give you an idea of the layering of these things.
We have an ongoing controversy about the vote equalization in the GNSO. I'm sorry for this typo. It's meant to be "GNSO." From our point of view, a corrective evolution of the constituency design.
We have discussions which have been, as I mentioned already, very hot, between the accepting the sole fact that there may be global policies in the addressing or in the ccTLD spheres.
And, of course, controversies about the various implications for geographical diversity, for efficiency and other reasons, about the number of seats every single participant here gets in the Board, in the Nominating Committee, GNSO Councils, and elsewhere.
The discussions we see in these controversies are very useful. If you can read through it in meta layers, it reveals hidden issues or issues that apparently were hidden, and maybe we were not looking enough.
It serves to reveal hidden agendas.
It serves to open the lens for better solutions.
And also to focus on the larger picture, which is taking me close to my closing note.
The long term, large scale goals the Internet community seeks through ICANN has to be the larger picture. It's not ICANN itself. The ICANN community is doing something through ICANN. We do not have to consider ourselves in face of the ICANN community, but channeling a need, a specific need of the ICANN community of the Internet community, doing it the Internet way, doing it with Internet stakeholders, doing it in an environment and in a sphere where Internet stakeholders can interact through the Internet in the Internet's original most positive, original, and innovative traditions.
And "innovative" is already an oxymoron if used with "tradition."
We invite the community to use this open forum to address the most substantive issues. We expect mostly to have either reiterations of very we know we'll have a lot of repetition. We expect that the speakers will confine their repetition to the reiteration of fundamental principles that they do not see addressed, that we will see new comments or new perspectives on how the whole thing looks now that there have been a few months to elaborate upon it.
We will propose tomorrow formally, once we have had all the input, discussion, and possible rehashing of things resulting from today's open forum, it's open also in the sense of open ears and open eyes from our part we will propose to the Board to adopt the draft Bylaws.
We will propose that the planning for a transition to a new steady state structure start immediately.
And we will and, in closing, I will thank the people who I have to thank personally, and I can identify personally in this brief moment, Stuart, Joe Sims, Louis Touton, Theresa Swinehart, Rita Rodin and the assistance group, she worked with Becky Burr, the assistance group of the ccNSO, , Denise Michel, Esther Dyson, Paul Twomey, Leslie Daigle, with whom we have had very productive interactions, if for me indirect. The people who have been sitting on the side who do this, and many people in the community who have either wanted to build the same thing we were trying in similar language or opposing it explicitly, bluntly, with arguments, with the possibility that we have to continue an open discussion instead of being what one would perceive, stabbed in the back by people who reserved their comments, went to some organization or person they thought was more powerful, and gave us a huge kick in some part of the anatomy.
I will thank you again for your attention here and leave the forum as an open forum.
Vinton Cerf: Thank you very much.
Alejandro Pisanty: I would like to propose a very specific point about the mechanics, which is is that myself or some other of the ERC members be allowed specific returns to the discussion so that we can keep it lively and we can make sure that we that the back and forth goes on instead of just having a long list of comments and complaints where there will be the complaint that they were not addressed.
Vinton Cerf: Okay. At this at this point, shall we thank you very much for all the hard work that's gone on so far. Plainly, we have a great many things to cover in the next few hours.
What I'd like to suggest, unless the other ERC Board members have specific comments, would be to invite Paul Twomey to make the GAC report specific to the ERC reform proposals, if Paul is here. And I don't see him. There he is. Okay.
And he's heading out of the room.
(laughter.)
Paul Twomey: Thank you, Vint. I wonder if we can ask the people with the equipment whether we still have the text from this morning.
Vinton Cerf: There's a body on the stage here who's trying to make that happen, Paul.
Paul Twomey: Okay. Could I just say just as we're waiting for that to come on screen, Vint, that I would like to express the appreciation of the Governmental Advisory Committee for the work being done by the ERC. Make a personal observation that I don't know what terrible and sinful things that the ERC members did prior to this, but in the next life, they should have a very good one for all the efforts they've gone through.
And the GAC has appreciated has made comments in the past about the timeliness of materials produced for comment, but has expressed its thanks for that degree of interaction that's been taking place between us over the last months.
I would like to share with the ERC, the Board, and the community some recommended amendments to the Bylaws as were posted, I think, on the 23rd of October. Is that the date of the most recent set of Bylaws?
And these amendments mostly focus around the interaction with governments and public authorities.
Vinton Cerf: We're still working on this. Apparently there's a connectivity problem. But I'm not quite sure what the solution is yet.
Other than pushing all the connectors together.
Paul Twomey: I think we're close here.
Vinton Cerf: It always seems to be a matter of cables and connectors. Let's hear it for radio connections.
My suggestion, Paul, is that we should just perhaps try to march through this.
Paul Twomey: We should.
Vinton Cerf: And we'll work on this problem of connectivity as you go along. We'll at least have the text of your comments from the transcription.
Paul Twomey: It's coming up now.
Vinton Cerf: If you talk along enough, something magic happens.
Paul Twomey: I will go through this, but I'm hoping we can rely on the text. It'll make it much easier, and just point out where there are additions suggested there involved and where there are deletions, they are done through a strike through.
If we can move through I think this is presently on the GAC web site, which is a link off the ICANN web site.
The first one on Article I, Mission and Core Values, the GAC recommended wording for Principle 3 under Section 1 of mission, which is "coordinates policy development as necessary to perform these technical functions".
Which is separate different from what's presently stated.
Moving to Article III, which deals with transparency, Section 6, Clause 1, Subclause ©, an addition where it's bolded. Keep going, ©.
"In those cases where the policy action affects public policy concerns, to request the opinion of the GAC and to take duly into account advice presented at the Board's request or at the GAC's own initiative."
I should point out also, I think, in Clause 1, in terms of public notice, the GAC requested that be changed from 14 days to at least one month.
In Article VI in Section 4, which deals with the review of –the GAC, the GAC certainly agrees with this principle and thinks the GAC itself should be open to that form of review.
Article IV, Section 4. But you will see that we add in this section where it calls for review of the Nominating Committee in each of these different organizations, we have put in, "other than the GAC."
And further down in that paragraph, added a new sentence which says "the GAC shall provide its own review mechanisms."
So the members of the GAC thought it was more appropriate the GAC run its own review mechanisms rather than having the review mechanisms be run by the Board. That's an issue of the sovereignty thing emerging in that discussion.
Vinton Cerf: My only comment is "chicken."
(laughter.)
Paul Twomey: Article VI, in terms of Board of Directors and the NonCom
Section 9 on nonvoting liaisons, that we have on the Board of Directors the nonvoting liaisons should include one appointed by the GAC. We have just deleted this phrase "established by Article XI of the Bylaws."
And then further down in Clause 4, we have put a request in that the nonvoting liaisons shall be entitled to use those materials in deliberations in their respective committee or organization.
Now, we just to explain this a little bit, we did actually take advice from ICANN's outside counsel about the nature of the fiduciary obligations on nonvoting liaisons. And we're informed that nonvoting liaisons are actually guests of the Board and as a consequence did not have fiduciary obligations. We did accept and expected to be interpreted in the implementation that if the nonvoting liaisons had access to materials, that that access to materials would have to come with some form of confidentiality process which would allow the sharing of that information in the constituency, in the committee of the organization, but which understood that we were dealing with Board papers that had a confidential nature and we are expecting some further work on that in the implementation process.
We were relieved to hear that nonvoting liaisons had no fiduciary obligations.
Moving to Section 11, talking about removal of a director or nonvoting liaison, again, for reasons of sovereignty that you can imagine, on point number 2, where it says, "any" voting [sic] "liaison may be removed," we added "other than the liaison appointed by the GAC
And I recognize that as Orwell would say, all animals are created equal, but some animals are created more equal than others. The GAC is just wanted to put that point in. Article X, again, with the GNSO council, this is just a small piece of drafting. The phrase the GAC had was "from time to time." It was just deletion of the phrase "from time to time" to make certain there would be an expectation that there was a position that could be permanently filled. We often find that use of English legal text often doesn't necessarily translate well into other people's understanding of what's intended. So we just deleted that to make it clear.
XI on advisory bodies, we actually did put forward quite a bit of material. First of all, we suggested changing the word "Advisory Committees" to "Advisory Bodies." You will see that in several sections where we changed the word "committee" to "bodies".
In section 2 that deals with the Governmental Advisory Committee, several suggestions. And these suggestions emerged after dialogues with the ERC.
First one, in Clause (a), an addition where it talks about that the GAC provided advice in areas affected by various laws and national agreements, we've included "or where they may affect public policy issues."
It's an important expansion of what exists in the original Bylaws, which was actually quite narrow.
Again, we also thought in clause (b) that the membership of the GAC should be open to determination by the GAC and, actually, not by the ICANN Board. So membership is open to all national governments. It's also open to distinct economies and recognized international fora and multinational governmental organizations and treaty organizations on the invitation of the GAC through its chair.
I think the history of this phrase by the way, I think the original words were put in for the original formation of the GAC, that when we initiated it, we had to have some mechanism, I think we put the invitation of the ICANN Board. Now that it's up and running, I don't think it's appropriate to keep that wording.
Point (c), that the GAC may adopt its own charter and internal operating principles or procedures to guide its operations.
On point (g), again, we have this deletion of the phrase "from time to time."
Point (h ) ". . . for which it or any of ICANN's supporting organizations or advisory bodies identified in articles VIII to XI seek public comment and should duly take into account any response to that notification prior to taking action."
Clause (i), now, there's now these (i), (j), and (k), are new proposals. And they're new proposals not dissimilar to those that exist for some other parts of the proposed new bylaws for other organizations.
(I) states that the GAC may put issues to the Board directly, either by way of comment or prior advice, or by way of specifically recommending action or new policy development or revision to existing policies.
(j) the advice of the GAC on public policy matters shall be duly taken into account both at the policy drafting and at the decision making stage.
ICANN will inform the GAC on how it intends to take into account of such advice.
In the event that the majority of the ICANN Board is in conflict with the GAC advice, the ICANN Board shall state the reasons why it cannot follow that advice.
In this case, the GAC and the ICANN Board will try, in good faith, and in a timely and efficient way, to find a mutually acceptable solution.
If no such solution can be found, the ICANN Board will, in its decision, explain the reasons why the GAC advice was not followed, without prejudice to the rights and obligations of GAC members with regard to public policy issues falling within their responsibilities.
It is not dissimilar to the procedure in the GNSO. And the intent here is not for the GAC to have a veto; the intent here is to have the GAC, first of all, to be quite clear, that it can put issues directly to the Board, which in the original Bylaws it was a bit unclear; and secondly not that it stopped us from doing it.
Secondly, that the intention is that if there's something being considered, the GAC's views will be considered.
If the Board decides not to follow them, there are actually written reasons why that's the case, that there would then be an opportunity for dialogue about those.
But still, the decision making power lies with the Board.
And if the Board decides still to follow a separate line to the GAC, it actually outlines why.
Clearly, this is an area where in the whole of the context GAC's responsibilities when it comes to representing public policy interests as it represents governments.
So in particular, we expect that dialogue, competition policy, those sorts of things.
Vinton Cerf: That's
Paul Twomey: I have one more section on section XI but if you want to stop now.
Vinton Cerf: Only if it's your sense if the addition of the public policy phrases poses a potential for vast mission creep, which none of us wants.
So do you think this is going to be a tool which could be limited in its scope?
Paul Twomey: I think in a matter of interpretation of Bylaws, the mission statement is a defining statement that defines the consequent Bylaws.
And as a consequence, and this is a personal statement, I must say, this is not the GAC speaking, it's a personal statement, I would consider that anything that appeared in this section would have to be read in context with section 1, article I.
Karl Auerbach: Yeah, I'm listening to these, I'm hearing mission creep in the sense that this seems to be the end of the concept of ICANN as a private body.
It seems we'd be relinquishing the role of the Board as the sovereign of this private body.
Vinton Cerf: I'd be cautious about using a term like sovereign around the GAC, but in any case, please proceed, Paul.
Paul Twomey: Karl, I take the point on Board.
There is a strong sense in the GAC community of that this idea of a private/public partnership is important.
I don't think there's any intention here, and I think the wording is quite explicit, there is not any intention to take away the final decision making power of the Board.
And that's clearly stated.
All that's asked here is, one, if the GAC has views that they be communicated.
If they're not followed, and it's really I think a point of transparency.
This is actually a transparency point, not a GAC point.
If you don't follow them, don't agree with the advice, just put down in writing why.
And then there's an opportunity for accountability, if the GAC wants to come back and say, well, please, can we have a dialogue around those reasons, that can take place.
If the Board still decides it wants to make a decision, then it's fully empowered to do so, but again, for transparency reasons can we just please have it in writing.
So I actually think, particularly some of the things you think are important, we're trying to reflect here a little bit in the transparency sense.
Karl Auerbach: I agree that this discussion, and the Board explaining its decisions is something we actually ought to have been doing better over the years, so I'm not disagreeing with your goal.
I'm disagreeing with who is actually in charge at the end.
Vinton Cerf: I see several other hands up and I apologize for having started this.
You have how much more material to present?
Paul Twomey: We have some specific wording on the new Article XI.(a) in terms of expert advice.
Vinton Cerf: I'm going to suggest to the Board members that we let you finish this and then come back.
Paul Twomey: Thank you.
If we can move, then, to what's called Attachment B.
It's the next one down.
And we would like to particularly thank the ERC for its development of this new Article XI (a).
This came as part of the interactions that took place between the GAC and the ERC on what had happened to this general topic, new Bylaws were posted and these are some amendments we suggest to those Bylaws.
These are not written with changes so a lot of this is original language, but I'm afraid I haven't got it written with the bolds and deletes so perhaps we can go through it.
One of the things that will come up in this is the original language from the ERC talked a lot about expert advice panels, and expert advisory panels and used the phrase expert advisory panels consistently while we thought what was looked for was expert advice.
And the modalities of that may be different as to how you wish to have it, so that's been reflected.
So the proposed language is Section 1, External Expert Advice, and this section is pretty much as it was in the original ERC language.
Receipt of external expert advice is intended to allow the policy development process within ICANN to take advantage of existing expertise that resides in the public or private sector but outside of ICANN.
1. In those cases where there are relevant public bodies with expertise or where access to private expertise could be helpful, the Board and constituent bodies should be encouraged to seek advice from such expert bodies or individuals. That's original GAC language.
2. Types of external expert advice. On its own initiative or at the suggestion of any ICANN body, the Board may appoint or authorize the president to appoint expert advisory panels consisting of public or private secretary individuals or entities.
So if you want to use expert advisory panels, we have no issue on that.
If the advice sought from such panels concerns issues of public policy, the provisions of Section 1.3 (b) of this article shall apply.
In addition, in accordance with Section 1.3 of this article, the Board may refer issues of public policy pertinent to matters within ICANN's mission to multinational governmental or treaty organization.
3. Process for seeking advice, public policy matters.
(a) The Governmental Advisory Committee may at any time recommend that the Board seek advice concerning one or more issues of public policy from an external source as set out above.
Now, I point out that includes private or public or multigovernmental organization.
It can be from any of those sources.
In the event that the Board determines, upon such a recommendation or otherwise, and again, we leave this decision in the hands of the Board that external advice should be sought concerning one or more issues of public policy, the Board shall, as appropriate, consult with the Governmental Advisory Committee regarding the appropriate source from which to seek the advice and the arrangements, including definition of scope and process, sorry, that should actually say definition of scope, comma, modalities and process.
There's been something missed out -- for requesting that advice.
The Board shall, as appropriate, transmit any request for advice addressed to a multigovernmental or treaty organization, including specific terms of reference, to the Governmental Advisory Committee with the suggestion that the request be transmitted by the Governmental Advisory Committee to the multigovernmental or treaty organization.
The process for seeking and advice.
Other matters.
Any reference of issues not concerning public policy to an expert advisory panel by the Board or president in accordance with Section 1. 2.a shall be made pursuant to terms of reference describing the issues on which input advice is sought and the procedures and schedule to be followed.
That's as the existing ERC language is.
I think the next two sections are as the existing ERC language is.
Proceeding to external advice and its effect.
External advice pursuant to this section shall be provided in written form.
Such advice is not binding and is intended to augment the information available to the Board or other ICANN body in carrying out their responsibilities.
The opportunity to comment by the GAC, this is important and this is an additional one, opportunity to comment.
The GAC, as well as the supporting organizations or other advisory committees, shall have an opportunity to comment upon the external advice prior to its consideration by the Board.
So just to give you a sense of what that might mean for multigovernmental organization, the Board may, either on suggestion from the GAC or on its own, decide it would like to have advice from multigovernmental organization in particular on public policy.
The obvious sort of example one could give is something on intellectual property and the request might go to WIPO; that that would go through the GAC, and be communicated to WIPO.
If WIPO is to produce a report, it would come back through the GAC, but the GAC would not be able to change that report.
It would hand the report in a pristine condition through to the Board.
What the GAC and other organizations within the ICANN framework should have a right to do is make their own observations or comments on that report.
We thought it's also important that ICANN not be that ICANN not be in a position to tell another entity, in particularly an intergovernmental organization, how it should conduct its work; hence the hesitation with advisory panels, because in WIPO's case, again, it's up to WIPO within its own treaty arrangements to determine how it does its own work.
Vinton Cerf: That's the completion?
Okay.
So I saw a few hands up.
So Amadeu.
Amadeu Abril i Abril: Okay, thanks.
Many things, but I will focus on a couple of them that are more important at this stage.
The first one, you use the expression when a public policy issues are affected.
The problem is that, in my recollection, the notion of public policy differs from person to person and from government to government, very often.
And then we have some ideas about things that are clearly public policy relating to our work for, you know, the view of the GAC.
But would the GAC consider to provide something like an initial list of issues that are public policy in their mind?
Because perhaps all these mechanisms will not work.
The second one regarding the advice from the GAC, the question is, you mention the procedural rules that the GAC would develop.
This is important also for also taking account in advice.
I mean it's not exactly the same if you get advice from the GAC that's consensus developed within the GAC that if you if it's just the simple majority opinion of someone that day with eight abstentions and ten votes against.
Up to now we've seen this is mainly consensus policies, but we will have explicit explanation of what does it exactly mean in terms of the internal support for all this advice?
Paul Twomey: Thanks for that, they're actually two good questions.
On the list of public policy, I would hesitate to give a formal definition.
I think you're quite right, those things do tend to change jurisdiction by jurisdiction.
But we have in previous communiques given examples of areas we think to be public policy and they tend to be consistent ones which are competition policy, consumer protection, security, there's a few others.
Sorry.
But they're the sort of key ones, and they are at a level higher than if I take an extreme, the policy determining, what should go in what field, in a protocol, different sort of policy questions.
So that's the sort of thing you should expect in terms of discussion.
If you look at all the GAC communiques and the things we've put to the Board they tend to be around those sorts of issues, as well as also the interests of government, which you've certainly seen on the dot info request.
As far as the issues of consensus or mere majorities or who supported what position, I think your observation puts makes it incumbent back on the GAC for the way it operates itself.
And I think the GAC members are conscious of that.
The degree to which it can produce consensus language makes its statements to the Board, I think, probably more powerful.
If it ends up with nonconsensus language, it has actually produced very clearly statements of who has agreed and who hasn't.
More importantly, it probably tends to say who has disassociated themselves from the majority language.
So I think you could expect to see that pattern repeated, that your observation is a valid one that the closer any group are to consensus, the more powerful the stated proposition.
Vinton Cerf: Hans.
Paul Twomey: Can I make one further observation.
It's usually the practice of governmental or intergovernmental organizations that although you may have members not in attendance, those who are in attendance on the day represent the position, and those who are in attendance on the day who makes the statement, particularly if it contains a statement, that is the statement of the group.
For instance, in the GAC if we have 40 members attending and we have a total membership of 80, for instance, if those 40 come to a position, it is the usual rule, that is the position of the organization.
Vinton Cerf: Okay.
Hans.
Hans Kraaijenbrink: My question concerns the Technical Advisory Committee or the Technical Liaison Group as it is defined in the revision of the 23rd of October.
I'm a bit confused by the discrepancy between Annex A and annex B to the GAC communique where there is no change, at least apparent for me, proposed for the Technical Advisory Committee/Technical Liaison Group.
It's sort of left in the middle, or am I interpreting the communique wrongly?
Paul Twomey: I don't think we really discussed it.
So Hans, can you give me further indication?
Is it because it actually appears in the text?
I notice that our text 1.a has the phrase Technical Advisory Committee but I'm not sure that's something we discussed.
Hans Kraaijenbrink: My confusion stems from the fact that in Section b there is no reference that the second section of Article XI (a) has to be deleted, and that you would like to insist on keeping what the ERC proposed to delete in the original article XI.
Paul Twomey: I have to admit that your confusion is spreading my confusion.
Hans Kraaijenbrink: Maybe I can ask it in a different way.
A different way is was there any discussion in the GAC about the Technical Advisory Committee proposed by the ERC to be transformed into a Technical Liaison Group?
Paul Twomey: There was some sort of general discussion but there was certainly no conclusion.
So we have nothing to say on the topic.
Vinton Cerf: Okay.
So now we come to an interesting time challenge because it's nominally lunchtime.
My suggestion would be to break now for lunch and to then invite public comment on the ERC proposals after we return.
The schedule for lunch says that we would return here at 2:00, one and a half hour lunchtime break.
Paul?
Paul Twomey: Thank you, Vint.
I wonder if I could just make two comments before we break for lunch.
The first comment is just to reinforce, picking up from what Karl had said which is an understandable statement, I want to reinforce the GAC's position is that while it recognized, along with other members of the community, including Stuart, that there was a need for a closer public private partnership for successful implementation of the Mission that's now been defined, it's very clearly the position of the GAC that the as it expressed in its communiques, that the Board is the final decider, the Board is the final arbiter.
The governments are not trying to take over that role.
And also, from our communique this morning, a very strong sense of one of the roles the Board plays is being in place for the consideration of many interest groups.
And I have people who agree, it's sort of like an outsource contract for us.
So this is actually a very important function that the Board plays of making judgments about the interest groups and ICANN comes from many places, so there's no way the GAC wants to take over that function.
That is the function of the Board.
A second comment, if I may, our decision around election processes for the GAC, this will be my last meeting as the chair of the GAC at ICANN.
And I just wanted we will have a new chair by, my guess, the first of January.
And I just wanted to say my thanks to the Board and to other members of the constituency, constituencies in the ICANN community, for all their assistance, help and friendship over the last what for me is a journey that started in February 1997 on ICANN.
And that I pretty much appreciated it.
I do have to make a comment.
If anybody thinks that the situation now is noisy, fractious and combative, I would remind us all what the Berlin meeting was like back in '97.
It's all now somewhat tame.
But I think there is a this organization is sorry.
This organization has a very important task to do, has an important bit of reform to do.
I've been pleased to be part of that process, and I thank you for your help and exhort you for good wishes.
Vinton Cerf: Thank you very much, Paul.
I'm sure I express the agreement of the Board that we thank you for all of your hard work as well.
(applause).
Vinton Cerf: I'll take an opportunity to roast Mr. Twomey later tomorrow.
In the meantime, I invite you to find lunch and to rejoin us here in the auditorium at 2:00.