Site Map

Please note:

You are viewing archival ICANN material. Links and information may be outdated or incorrect. Visit ICANN's main website for current information.

Meeting White Paper

6 November 2006

Susan Crawford

Comments can be made to and reviewed at

Fill out and submit the questionnaire.


ICANN’s approach to meetings must be determined by core organizational goals and principles. What are these meetings for? How can ICANN’s meetings attract more constructive and effective engagement by members of the community? How can they be conducted more efficiently, at lower cost in time and money? How can they enhance the legitimacy of ICANN’s actions?

This paper represents a first cut at working through these issues. It attempts to assess the operational goals of ICANN’s meetings, address criticisms of these sessions, and present proposed solutions for consideration by the community. It is designed to be circulated in advance of the Sao Paulo meeting to facilitate a public workshop during that meeting that I will run.

This paper stems from my interest in improving the quality of ICANN’s meetings. Some of the issues it covers are also touched on by the GNSO review report prepared by the LSE, and this paper is intended to complement that effort.

The paper is divided into three parts. Part I describes the goals of ICANN meetings and provides some factual background on these meetings. Part II lists criticisms and concerns about ICANN meetings. Part III deals with proposed solutions and alternatives designed to deal with the criticisms and concerns that have been raised.

This paper makes the following recommendations:

1. There should be a public forum at the beginning of each Large Meeting. (By “Large Meeting,” I mean the three public ICANN meetings currently held per year.)

2. If ICANN continues to use local hosts for Large Meetings, the relationship should impose far fewer obligations on these local hosts.

3. ICANN should develop an online docket that shows clearly at all times the status of all decisions to be made by the Board and supporting organizations.

4. Agendas should be required to be posted online well in advance of meetings.

5. Agendas should clearly focus on the purpose of a presentation or activity, so that people know whether they need to participate. Then these agendas can tie directly to the results of the meeting.

6. All meetings should generate detailed minutes together with a summary of important actions or next steps. Everyone should be able to see clearly what arguments were advanced by particular people and how decisions were made.

7. As a default, ICANN meetings of all descriptions should be public. Those few that are private should be subject to clear guidelines about what can be said publicly about those meetings. ICANN should develop these guidelines promptly and advise all meeting attendees of them. For example, it would be good to make clear to all public meeting attendees that meetings will be recorded.

8. All correspondence to ICANN from any outside source, on substantive issues, should be publicized on the ICANN web site absent an express decision by the Board to authorize confidential treatment, in which case the existence and rationale of such a decision should be disclosed.

9. For 2008-10, ICANN should consider choosing in advance at least one hub city for one of the three Large Meetings, such as Vancouver, Frankfurt, Singapore, Paris, Hong Kong, or Los Angeles.

10. The number of Large Meetings should remain at three for the coming years.

The paper also raises questions about how the public forums, Board meetings, and scheduling assumptions behind Large Meetings could be improved, but makes no specific recommendations along these lines.

I. Background and Core Goals

A. Large Meetings

ICANN’s function is to coordinate policy regarding domain names and IP addresses. Because the ICANN community is international, ICANN has had a practice of meeting in different regions of the world (and different cities in those regions) three or four times a year since 1999:

1999: Los Angeles, California, USA; Santiago, Chile; Berlin, Germany; Singapore

2000: Marina del Rey, California, USA; Yokohama, Japan; Cairo, Egypt

2001: Marina del Rey, California, USA; Montevideo, Uruguay; Stockholm, Sweden; Melbourne, Australia

2002: Amsterdam, Netherlands; Shanghai, China; Bucharest, Romania; Accra, Ghana

2003: Carthage, Tunisia; Montreal, Canada; Rio de Janeiro, Brazil

2004: Cape Town, South Africa; Kuala Lumpur, Malaysia; Rome, Italy;

2005: Vancouver, Canada; Luxembourg City, Luxembourg; Mar del Plata, Argentina

2006: São Paulo, Brazil; Marrakech, Morocco; Wellington, New Zealand

2007: [Asia Pacific region]; San Juan, Puerto Rico; Lisbon, Portugal

Each of these meetings costs between US $600,000 and $700,000 in total to hold. At the moment, local hosts cover expenses relating to venue costs, registration, audiovisual equipment, security, internet access, insurance, signage, coffee breaks, a gala reception, and other miscellaneous items. Local hosts bid to run ICANN meetings, and typically find sponsors to cover many of the expenses associated with each meeting. (ICANN’s RFP for local hosts, which sets out the requirements ICANN has for meetings, can be seen at

It is fair to say that local hosts find the burden of hosting a meeting to be substantial. The meetings have grown quite a bit over the years (currently about 800 people attend each meeting), and professional assistance is often needed by the local host to tie everything together. Local hosts need to arrange for large meeting rooms and hundreds of hotel rooms to be available. Equipment costs sometimes turn out to be high (printer/copiers, microphones, projectors). ICANN brings the webcasting equipment, but local hosts are responsible for the rest of what is needed to project a meeting. Local hosts often end up spending a good deal of money on the web site for the meeting and on registration services. Last-minute changes in the schedule of the meetings frequently are needed by members of the community, which makes life difficult for local hosts. ICANN meetings have bandwidth needs that are extreme, and the size of the meeting dictates that a major conference center with hotel rooms be secured. Most local hosts underestimate how much effort and money will be needed to make all of these arrangements.

ICANN, for its part, covers the travel and hotel expenses of Board, staff, and many community members to these meetings, and pays for meals for the Board and staff (and some members of the community). ICANN’s 2006-07 budget for all meetings (including regional outreach meetings, which are separate from these three large meetings) is $5.9 million (of a total budget of approximately $30 million).1 No one on ICANN’s staff works fulltime on meeting arrangements. There are two ICANN employees who spend at least half their time on meetings and one who spends a piece of his time on technical/security arrangements for meetings. ICANN has also retained an independent contractor who spends 70% of his time on ICANN meetings. For shorthand purposes, we will call the current set of three large meetings Large Meetings.

The core goals of the Large Meetings, each of which lasts a week and currently attracts approximately 800 participants, are (at least):

1. Work on policy development in face-to-face meetings. Indeed, a central purpose of meetings is to reach and demonstrate the kind of consensus needed to adopt binding rules -- and/or to determine that that is not possible and thus to make clear that the issues on which consensus cannot be reached will be dealt with by decentralized decisionmaking and local laws. ICANN is supposed to be a forum for the discussion of policy, and these meetings provide opportunities to advance those discussions.

2. Inform Board and Staff and members of the community regarding key domain name policy issues. (As a practical matter, addressing policy is not made at ICANN meetings.)

3. Hold Board meetings.

Large Meetings generally include several public workshops, meetings of various support organizations and advisory groups (some of which are public and some of which are not), and public forums. The Board meets to debate and take action as a Board in public. The GNSO meets to develop consensus policies. The CCNSO meets to educate and coordinate. The GAC meets to formulate advice to the Board. Other groups, such as the NRO, the Nominating Committee, SSAC, and various task forces use the occasion of ICANN meetings to consult with their members. There is no registration fee required for members of the public to attend Large Meetings.

It would be worthwhile to discuss in Sao Paulo whether the goals listed in this paper for Large Meetings are the right ones, and whether they reflect reality. Should Large Meetings be more like trade shows? Should we encourage more businesses to attend that don’t necessarily involve themselves in policymaking? Are they networking events or policy events or regional outreach events?

B. Other Meetings

Large Meetings are a substantial part of ICANN’s operations. But there are many other kinds of ICANN meetings. For example, the Board has recently begun to hold weekend retreats (two per year), which are private. Additionally, there are task force meetings, constituency meetings, GNSO working session meetings, and other offline and online meetings.

In particular, ICANN has also begun to hold Regional Meetings. Following the installation of ICANN’s regional liaison team in early 2006, outreach events for Latin American and for the Baltic region and Eastern Europe were held in October 2006. ICANN now has six regional liaisons who meet with various stakeholders in their region. They interact with registrars, registries, ccTLD managers, and others. Also, regional registrar meetings and ccTLD workshops have been participated in by ICANN. ICANN plans to have or participate in about two to three regional-related events per year per region.

I cannot tell how much all of this is non-Large Meeting activity is costing ICANN, but I wanted the community to be aware that not all ICANN activity happens at Large Meetings.

1. Latin America

ICANN co-organized with UNAM, Universidad Nacional Autónoma de México, a video conferencing session aimed at providing information and participation opportunities to all stakeholders (including governments), with a special focus on developing countries in Latin America. The objectives of the session were to:

1. Bring greater understanding to stakeholders in Latin America of what ICANN is responsible for and how to participate in the GAC;
2. Through greater participation, awareness and capacity building, better response to specific issues of regional interest;
3. Identify means for addressing improved participation in ICANN from developing countries.

Participants came from eleven different countries and were in fifteen sessions that went on for six hours. From Argentina, for example, there was participation from ISPs, e-business/business, addressing community, gTLD interests, ALAC, and the government. The event was webcast. The meeting used an expensive infrastructure, the use of which was donated by several participants (Clara network – Latin America’s Internet II)., and

2. Eastern Europe

A Baltic Region and Eastern Europe International Seminar, "The Internet and the Post-WSIS Environment: Enhancing Dialogue Among the Stakeholders," took place in Riga, Latvia, on 4 October 2006. This event was co-organized by the Secretariat of Special Assignments Minister for Electronic Government Affairs of Latvia and ICANN, with partners including Finland's EU Presidency. The event was attended by over 100 participants from the region, ranging from Russia, Georgia, Moldova, Lithuania, Finland, Sweden, and Kazakhstan. Panel sessions addressed issues ranging from global Internet governance and regional developments to specific issues such as ccTLDs, IDNs, and security. ICANN contributed approximately US $4,000 to help with the conference room and facilities. Local hosts and sponsors paid for regional travel, participation, food, etc. See

3. Regional Registrar Meetings

In May 2006, ICANN hosted a meeting focused on topics of interest to registrars in the European region. Some registries also attended, and there were approximately 50 people there in total. There have been requests for more meetings like this one.

4. ALAC Meetings

ICANN’s regional liaison network has helped to organize several At Large RALO formation events, including two in Europe and one in Latin America. The event in Latin America, which attracted about 36 people, was held prior to the CITEL meeting in Argentina. The events in Europe were in Berlin and Frankfurt – each attracted about 20 people.

5. ccTLD Regional Meetings

ICANN has been organizing or participating in various workshops for ccTLD registries around the world since early 2004. ISOC and ICANN have worked together on these seminars. (see

The purpose of these workshops is to provide local operators with technical training so that they can contribute to maintain stable, reliable and secure services for their respective communities. The workshops also touch on registry policies and management procedures.

Workshops organized by ISOC have also provided a hands-on clinic in a lab environment for ccTLD technical staff to learn about existing tools and software for registry operations. This includes demonstrations with the toolset developers so participants can determine how to best format their data to register domains for their ccTLDs, set up name-service, exchange secondaries, create WHOIS data, etc. Users get expert advice on how to automate and scale up their current operations, and pointers on how to structure their existing data for use with open source toolsets.

ccTLD managers attending the seminars have the chance to meet with their regional peers, to share best practices and to learn from past experiences.
ccTLD workshop in Sofia, Bulgaria, October 24-26
(focus: Balkan area registries plus Eastern Europe registries)

ccTLD workshop in Dubai, United Arab Emirates, November 20-21
(in parallel to GITEX 2006 in Dubai)

Other ccTLD workshops ICANN has participated/sent staff to:

Pacific Region ccTLD Workshop
20th - 24th June 2006
Apia, Samoa

Atelier ccTLD Dakar
7th - 10th December 2005
Dakar, Senegal

Nairobi ccTLD Workshop
12th - 15th September 2005
Silver Spring Hotel, Nairobi Kenya

Atelier DNS AfTLD
Administration technique des noms de domaine internet nationaux
17th - 21st December 2004
Yaoundé (Cameroun)

Bangkok ccTLD Workshop
7th - 12th October 2004
Bangkok, Thailand

Amsterdam ccTLD Workshop
19th - 22nd June 2004
Amsterdam, The Netherlands

Question for discussion: Should there be GAC regional meetings? Should these meetings be tied to ccTLD workshops?

II. Criticisms

Criticisms of ICANN’s Large Meetings can be divided, roughly, into physical, organizational, and policymaking categories.

On the physical side, they have been criticized for being too time consuming for everyone involved. It is very difficult in this fast-paced world for anyone to take a week for a single meeting. Sometimes they have been in locations that are one or two hops away from main airline hubs, and there have been some criticisms of this practice. The physical setup for Large Meetings can vary wildly – at times the meetings and the hotel rooms are in the same place, and at times they are not. ICANN’s constant travel schedule, always to different locations (in combination with the length of the meetings), has given rise to suggestions that ICANN “insiders” are on boondoggles.2

Organizationally, Large Meetings have been criticized for being repetitive, non-inclusive, and non-transparent. A few of the sub-meetings inside ICANN Large Meetings are not public, and most are not made available online in any form. Proposals and information are often not circulated in a timely manner in advance of meetings. At times, the same reports are repeated over and over again in different submeetings.

ICANN does not have a set protocol for what may be reported about “private” meetings, which has also caused difficulties from time to time. Nor does ICANN have a set protocol for what must be reported about “public” meetings, which makes those meetings difficult for outsiders and remote participants to follow.

As to policymaking, it is not always clear whether decisions actually get made as a result of Large Meetings, although face to face contact does seem important to policymaking generally. There does not seem to be enough interactive conversation among constituencies, although this is changing over time. Not all issues are well formulated, and in general it is very difficult for “outsiders” to understand what is going on. The status of decisions is hard to ascertain. Registrants and the public don’t have much access to what happens at Large Meetings. The Board meeting is heavily scripted, although public, and doesn’t prompt much interest or real discussion. As a whole, the meetings seem to have a traditional rhythm of their own that is not necessarily tied to any set of principles.

The LSE’s recent review of GNSO policymaking raised several of these points. It is available here: The LSE has suggested that GNSO take over decision-making regarding its own procedures and operations.

There is also support within the ICANN “community” for the Large Meetings. Some face to face contact is extremely helpful for reaching consensus on policy issues. Having Large Meetings three times a year allows members of different parts of the community to see each other regularly and collaborate. There is a sense that outreach to different “local internet communities” around the world is important to ICANN’s continued mission and credibility. Intersessional (between meeting) progress is difficult for some groups to make, and the meetings provide a prompt for work to continue. Many groups feel it is important to have time with the Board, and that is only possible at these meetings. The number of ICANN subgroups and the complexity of their interactions sometimes seems to make the great number of days needed for these meetings necessary.

Key questions that should be discussed in Sao Paulo include:

1. How can Large Meetings be run better?
2. How can the results of meetings be made more transparent?
3. Are new Regional Meetings fulfilling some of the outreach interests associated with Large Meetings in the past? What are the benefits and burdens of switching to hub locations for at least some of the 2008 Large Meetings?
4. Are we holding the right number of Large Meetings?

The following section sets forth initial responses to these questions. It is intended to serve as a guide to discussion.

III. Solutions and Questions

1. How can Large Meetings be run better?

In Sao Paulo, we are trying out a new meeting format that is intended to reduce the number of days per Large Meeting and increase the quality of the public forum discussion. It is also aimed at having breaks be uniform so that members of different groups can mingle more easily.

The meeting will run Monday through Friday. We will start with a public forum on Monday morning (this is a change from prior practice), and there will be workshops on Tuesday and Wednesday morning. Thursday will be a second public forum (all day), and Friday morning will be (as is traditional) the Board meeting. Monday, Tuesday, and Wednesday afternoons will be devoted to internal constituency and supporting organization meetings (GAC, ccNSO, GNSO, ALAC).

The idea is that starting with a public forum will allow different groups to report on what they have accomplished during the period between meetings. This kind of level-setting is now absent from the meetings, and it may help with letting “outsiders” know what has happened before the meeting and will happen during the meeting. This first public forum can provide a kind of agenda-setting for the week.

We hope that meetings between the Board and all participants in the ICANN process taking place at the beginning of Large Meetings (and guided by a detailed agenda) will provide ample opportunity for iterative conversations between the Board and the public.

A. Suggestions for Public Forums

It might be good to have public forum sessions that are not aimed at reporting to, or replying to, the Board. It seems that cross-constituency dialogue on focused issues would be more helpful to ICANN’s mission. One proposal that has been raised is to have public forums devoted to particular issues that some member of the community, or someone on ICANN’s staff, is prepared to raise in some detail. Board members would simply be members of the discussion group, and would not be up on an elevated stage. This would allow for sustained conversation on serial topics. Some of this already happens in the public forum, but the format to date has been one of “talking up” to the Board.

ICANN should get away from the idea that the only communications that are needed are to the Board. The Board, as a whole, shouldn't be the target of a communication until and unless someone is claiming the existence of consensus (or proposing a Board resolution or decision of some type). Much of the needed communication is among constituencies -- attempting to see if there is a need for a rule and a prospect for broad agreement on a particular proposed rule. That kind of communication can be more or less continuous, especially if the progress of the discussions can be accurately reflected in a docket (as discussed elsewhere in this paper).

Should the last public forum be after the public Board meeting, so that the Board can respond to questions about what it has done?

Clearly we need translation services for the public forums. What is the plan for making these work, and how much will it cost?

B. Suggestions for Constituency Meetings

It has been suggested that ICANN have clear protocols for what it means to have a “public” meeting within a Large Meeting and what it means to have a “private” meeting. The default setting should be public, which means meetings can be transcribed and reported on in any format. What it means to have a “private” meeting needs to be defined. If the expectation is that only authorized members of the particular constituency or group (and what it means to be authorized) may attend, then that should be clearly stated in advance. If the expectation is that no record may be published of the meeting, that should be stated as well. IETF does this in advance of its meetings.

In particular, it would be good to make clear in advance that public meetings may be recorded in a variety of ways.

C. Schedule Suggestions

It may be desirable to have as many of ICANN’s constituencies/SOs as possible meeting in the same place and at the same time. To that end, does the five-day schedule proposed for Sao Paulo help? Or, would it be better to let each constituency/SO decide where and when to meet, without attempting to coordinate under the umbrella of a Large Meeting? What changes to the schedule would best serve ICANN’s core goals of coordination, face to face policymaking, and information flow?

The Board meeting that closes the week is heavily criticized and thinly attended. How could Board meetings be improved? Are they still necessary components of Large Meetings? Should the Board meet before the forums, instead of after, so that there can be feedback on the Board’s actions?

D. Local Host Suggestions

The current burden on local hosts of Large Meetings is great, and leads at times to some difficulties in carrying off ICANN meetings. These meetings are very large and very expensive. Sometimes local hosts use meeting planners to arrange for hotel rooms etc. (There is little incentive for conference organizers to sponsor meetings and provide their services for free.) Because those meeting planners are sometimes paid per room, room contracts may end up being highly centralized (i.e., meeting attendees can’t make their own direct arrangements for rooms but have to go through a central planner), overpriced, and difficult to adjust.

If we continue using local hosts for Large Meetings (a question considered below), it might make sense to change the nature of the obligations imposed on local hosts.

RIPE,3 for example, gets sponsorship directly for its meetings, with the RIPE Network Coordination Center providing almost all of the support.4 The RIPE NCC has dedicated meeting staff and brings in a logistics and technical team. There is no local host.

The IETF Secretariat makes all arrangements for hotel rooms and meeting rooms itself, but has a tradition of having local hosts provide a “terminal room” and a social event at IETF meetings. “In return for hosting the terminal room/social event, the Host receives public acknowledgment by the IETF, and will be given the opportunity to make a technical presentation to the IETF.”5

It might make sense to treat a local host as another sponsor of a Large Meeting. The host could provide a reception or other service that would promote them without obliging them to take care of all arrangements.

ICANN’s needs for Large Meeting equipment currently provided by local hosts are complex. ICANN could provide this equipment for each region, but solving the power of getting power to seats and rooms will continue to pose a challenge. ICANN might need to work with an outside logistics company (which will be expensive). ICANN could provide a registration software package and use the local host’s help to find people to work by the hour to register attendees. ICANN could provide the web page for each meeting instead of relying on the local host to do this, while local hosts could help with information about local attractions etc.

The local host relationship changes with each ICANN meeting. At times, it has been difficult for one or the other side of the relationship (or both). Whether or not we continue to hold meetings in different places each year, it may make sense to change the terms of this relationship for 2008.

2. How can the results of meetings be made more transparent?

It seems that there are several things we could do to make the results of ICANN meetings more transparent.

ICANN should develop an online docket that shows clearly at all times the status of all decisions to be made by the Board and supporting organizations. This will greatly facilitate remote and online participation.

Agendas should clearly focus on the purpose of a presentation or activity, so that people know whether they need to participate. Then these agendas can tie directly to what the results of the meeting was. At the moment, agenda-practice varies across groups.

We clearly need to have all meetings generate detailed minutes together with a summary of important actions or next steps. In particular, I recommend that ICANN Board meetings be recorded or summarized in detail, so that all participants can see clearly what arguments are advanced by particular Board members and how decisions are made. For meetings that are not “scribed,” we should encourage volunteer taking of minutes and make those minutes available.

All correspondence to ICANN from any outside source, on substantive issues, should be publicized on the ICANN web site absent an express decision by the Board to authorize confidential treatment, in which case the existence and rationale of such a decision should be disclosed.

Remote participation remains a major problem for ICANN meetings. We should have

1) advance instructions that make it clear how to participate remotely (what software, what pages, where to send questions, etc.)

2) get presentations in advance via a standardized tool that uploads them to a shared space. In parallel, push to get all presentations available for archiving.

3) ensure that for remote participation, there is a low-bit rate audio channel available that is separate from video.

4) have a clear process for dealing with remote questions.

5) have Jabber room availability (information about where the rooms are)

6) have a proper archive of the meeting. This includes presentations, logs of jabber rooms (if there are any), archives of audio/video, minutes, etc.

7) work towards getting closed-captioning available to remote participants (recognizing
that this may not be easy)

8) encourage volunteer minute-taking for meetings that aren't scribed

9) have detailed agendas, links to the archives, remote participation advice, etc. in a one-stop starting place

At Sao Paulo, we should discuss whether these or other steps should be taken to increase transparency.

3. Are new Regional Meetings fulfilling some of the outreach interests associated with Large Meetings in the past? What are the benefits and burdens of switching to set locations for some of the 2008 Large Meetings?

Given the increase in activity at the regional level and the number of Regional Meetings now going on, it may make sense to begin thinking of the Large Meetings as merely part of the overall package of ICANN activities rather than as the only important events.

Regional outreach activities and Regional Meetings are aimed at empowering new and old members of the ICANN community to participate more effectively in ICANN policy processes. These regional meetings can focus on helping ICANN learn about the technical, administrative and policy issues that affect particular local internet communities. Attendees can learn about how to influence the ICANN policy development process and how ICANN works, and ICANN can get feedback about its functions. It is not necessary to attend ICANN Large Meetings in person in order to influence policy, but those who attend Regional Meetings will certainly have a better understanding of what is going on at the Large Meetings.

It is clear that being a local host for an ICANN meeting is a mixed blessing. Hosts have a constant struggle with raising sponsorship support, finding adequate facilities, ensuring connectivity, and many other issues. On the other hand, for some local hosts having an ICANN meeting is a prestigious event that they can use to promote their goals. Often the local community participates heavily in the Large Meeting, and their participation is a great benefit to ICANN. And ICANN has no doubt benefited from its efforts to act as internationally as possible in its meetings arrangements.

As ICANN matures, and as the Regional Meetings become more significant, it may make sense to consider trying a new regime for 2008-2010 Large Meetings. (The experiment would need to last for more than one year for ICANN to gain any leverage in arranging for better terms for meetings facilities.) We could switch to a set of three or fewer set locations for these years that are centers for airline travel. In other words, we could move towards “all hub” meetings or to a hybrid approach that combines hubs with non-hubs. No meeting will be equally convenient for everyone, but such an arrangement could be equally inconvenient for everyone.

Benefits of such an approach might include greater predictability of meetings arrangements, less “boondoggle” appearance, some ability (perhaps limited) to negotiate advantageous longterm financial arrangements for meetings, and easier visa arrangements.

Downsides of such an approach might include some loss of international variability (hub cities might be more homogenous) and possibly more expensive accommodations at times. The costs of having meetings in major airline hubs would likely be about the same as having meetings in smaller cities, given savings available for air fares in company with potentially higher costs for accommodations.

We could experiment in 2008-10 with having some meetings in cities in which our presence is not necessarily dependent on the help of a local host. For example, we could choose Vancouver, Frankfurt, Singapore, Paris, Hong Kong, or Los Angeles, in advance, as places for one or more meetings per year. (Los Angeles has the benefit of being home to many ICANN staff members, which would lower costs.)

We will need to make this decision promptly. The 08-09 budget will be finalized in May of 2007. Bids for the 2008 meetings would be due (if we do not change the system) in July 2007 at the latest.

4. Are we holding the right number of Large Meetings?

Since 2003, there have been three Large Meetings per year. Having two meetings a year instead of three might increase the quality of these meetings, because groups and constituencies would need to accomplish a good deal intersessionally. It might (arguably) be less easy to push issues off until the next meeting if there were fewer meetings.

On the other hand, it may be that some groups feel they can only accomplish work by meeting in person. In that case, two meetings would (arguably) be too few.

On balance, it seems for the moment that three Large Meetings is probably the right number.

1 The note in the budget on this amount reads: “This line item includes budget for ICANN meetings, Board travel and staff travel. Also included are ICANN attended or sponsored meetings as indicated in the operating plan. This year ICANN has also included a provision to provide some assistance to selected volunteer members of the ICANN community who could not otherwise attend task force or other ICANN meetings. Travel assistance will be provided on a case-by-case basis only after the trip request is evaluated and deemed to have a value-added component for ICANN and the community.”

2 From Wikipedia : “ Boondoggle is also known in the business world, for trips taken to "exotic" or popular locations for a meeting. Usually, these meetings could have been either handled over the phone or not occurred all together.”

3 RIPE (Réseaux IP Européens) is a collaborative forum open to all parties interested in wide area IP networks. The objective of RIPE is to ensure the administrative and technical co-ordination necessary to enable the operation of the Internet within the RIPE region.”

4 A RIPE Meeting is a five-day event where Internet service providers, network operators and other interested parties from Europe and the surrounding regions gather.” RIPE charges a fee (EUR 400 for the week) to attend.


© Internet Corporation for Assigned Names and Numbers

Privacy Policy | Terms of Service | Cookies Policy