Logo
ICANN
ICANN
Filtered Search

Are you sure you want to sign out from http://www.icann.org?

If you want to sign out from both http://www.icann.org and ICANN Account, click here.

Board Activities and Meetings

View records of actions and decisions made by the ICANN Board from recent activities and meetings.

Minutes | Regular Meeting of the ICANN Board 18 May 2013

A Regular Meeting of the ICANN Board of Directors was held on 18 May 2013 at 2:00 pm local time in Amsterdam, The Netherlands.

Steve Crocker, Chair, promptly called the meeting to order.

In addition to the Vice Chair the following Directors participated in all or part of the meeting:Sébastien Bachollet, Fadi Chehadé (President and CEO), Bertrand de La Chapelle, Chris Disspain, Bill Graham, Olga Madruga-Forti, Erika Mann, Gonzalo Navarro, Ray Plzak, George Sadowsky, Mike Silber, Bruce Tonkin (Vice Chair), Judith Vazquez and Kuo-Wei Wu.

The following Board Liaisons participated in all or part of the meeting: Francisco da Silva (TLG Liaison), Heather Dryden (GAC Liaison), Ram Mohan (SSAC Liaison); Thomas Narten (IETF Liaison); and Suzanne Woolf (RSSAC Liaison).

The following staff participated in all or part of the meeting: John Jeffrey, General Counsel and Secretary; Akram Atallah, Chief Operating Officer; Sally Costerton, Tarek Kamel, David Olive, Megan Bishop, Michelle Bright, Samantha Eisner, Dan Halloran, Denise Michel, Cory Schruth, and Amy Stathos.

Jonne Soininen was present as an invited guest.

  1. Consent Agenda
    1. Approval of Board Meeting Minutes
    2. FY2014 Budget Approval Timing
    3. Site of the October 2014 ICANN Meeting in North America
    4. ACDR Proposal to be a UDRP Provider
  2. Main Agenda
    1. SSAC Advisory on Internal Name Certificates
    2. SSAC Budget Request
    3. BGC Subcommittee for New gTLD-Related Reconsideration Requests
    4. Any Other Business
  3. Executive Session
    1. CEO At-Risk Compensation
    2. Confidential Resolution

 

  1. Consent Agenda:

    Prior to introducing the Consent Agenda, the Chair and the President and CEO thanked the staff for their efforts in organizing the workshop.

    The Chair introduced the consent agenda items and noted that the request for redelegation for .ID was pulled from the agenda, and the item regarding the Subcommittee for the BGC was moved to the Main Agenda. Sébastien Bachollet moved and Cherine Chalaby seconded the following and the Board took the following action:

    Resolved, the following resolutions in this Consent Agenda are approved:

    1. Approval of Board Meeting Minutes

      Resolved (2013.05.18.01), the Board approves the minutes of the 11 April 2013 Regular Meeting of the ICANN Board.

    2. FY2014 Budget Approval Timing

      Whereas, the FY2014 Budget is currently out for public comment, which closes on 20 June 2013.

      Whereas, ICANN typically approves each year's budget during one of ICANN's Public meetings.

      Whereas, ICANN's mid-year meeting this year, in Durban, South Africa (14-18 July 2013), is taking place after the initiation of the 2014 Fiscal Year, which begins on 1 July 2014.

      Resolved (2013.05.18.02), the ICANN Board intends to approve the FY2014 Budget during the ICANN public meeting in Durban, South Africa.

      Resolved (2013.05.18.03), for the period of time beginning on 1 July 2013 through to the date the Board approves the FY2014 Budget, the Board directs the President and CEO to operate ICANN in a manner consistent with the FY2014 Budget that is posted for public comment.

      Rationale for Resolutions 2013.05.18.02 – 2013.05.18.03

      As per ICANN's Bylaws, the budget of any given year needs to be approved by the end of the preceding fiscal year (30 June). Historically, this approval has happened during the last ICANN Public meeting of the fiscal year (a mid-term meeting), which usually is scheduled towards the end of June. This year, the mid-term meeting is being held from 14 July – 18 July 2013, which is in the next fiscal year.

      The public comment forum on the FY2014 Budget is scheduled to close on 20 June 2013. As that is only ten days prior to the close of the fiscal year, there is limited time to assure that all public comments are reviewed and considered (including any potential changes to the draft budget that are incorporated after review of the public comment) prior to providing the budget to the Board for consideration. In addition, several members of the ICANN community have expressed a preference for each year's budget to be approved at an ICANN Public meeting.

      To allow for sufficient time for review of public comments and for the Board consideration of the comments to the budget, staff recommended to the Board Finance Committee (BFC) that the FY2014 Budget be approved by the Board at the Durban meeting. The BFC agreed and recommended the Board resolve to approve the FY2014 Budget in Durban. This action enhances the Board's accountability to the community, in that the Board is responding to stated community desires for budget approval to occur at a public meeting, as well as assuring that the Board has sufficient time to consider the community inputs prior to taking a decision on the FY2014 Budget.

      In order to allow for ICANN to operate during the beginning of FY2014, beginning on 1 July 2014 through to the date the Board approves the FY2014 Budget, ICANN requires Board authorization. Therefore, the Board is authorizing the President and CEO to operate during this period in accordance with the FY2014 Budget that was posted for public comment. This action will allow for ICANN to maintain its operations pending formal approval of the FY2014 Budget.

      The other alternative here would be to have the Board take a decision on or before 30 June 2013, and outside of a public meeting. This was not deemed preferable under all of the circumstances.

      The delay in approval of the budget, as it is accompanied with a measure to allow the operations of ICANN to continue, is not expected to have a material impact on the planned fiscal operations of the organization or the community. This decision will not have an impact on the security, stability or resiliency of the DNS.

      This is an Organizational Administrative Function of ICANN not requiring public comment.

    3. Site of the October 2014 ICANN Meeting in North America

      Whereas, ICANN intends to hold its third Meeting for 2014 in the North America region as per its policy, and in line with the Board's 20 December 2012 Resolution on 2014 meeting locations.

      Whereas, staff has completed a thorough review of all available meeting venues in North America and finds the one in Los Angeles, California to be the most suitable.

      Whereas, the Board Public and Stakeholder Engagement Committee agreed to Los Angeles, California as the site for the ICANN 2014 North America Meeting.

      Resolved (2013.05.18.04), the Board approves Los Angeles, California as the location of the ICANN 2014 North America Public meeting, which is scheduled for 12-17 October 2014.

      Resolved (2013.05.18.05), the 2014 Los Angeles ICANN Public meeting is designated as ICANN's 2014 Annual Meeting.

      Resolved (2013.05.18.06), the Board reaffirms its 20 December 2012 resolution authorizing the President and CEO to make all necessary arrangements to conduct the 2014 ICANN Meetings, including all necessary contracting and disbursements.

      Rationale for Resolutions 2013.05.18.04 – 2013.05.18.06

      Three times a year ICANN hosts a Public meeting in a different geographic region (as defined in the ICANN Bylaws) of the world. ICANN 51, scheduled for 12-17 October 2014, is to occur in the North America geographic region. Staff identified available and suitable locations, and conducted a thorough analysis of those venues to ensure that they meet the Meeting Selection Criteria. Based on that analysis, Staff recommended that ICANN 51 be held in Los Angeles, California.

      The Board reviewed Staff's recommendation for hosting the meeting in Los Angeles, California and determined that the proposal met the significant factors of the Meeting Selection Criteria used to guide site selection. The process for selection of this site does not call for public consultation, as the staff assessment of the feasibility of any site is the primary consideration.

      Meeting locations for the March 2014 (Singapore) and June 2014 (London) meetings were approved by the Board on 20 December 2012. For comparative information, the meeting facilities and production budget of the Singapore meeting is not to exceed US$885,000, the meeting facilities and production budget of the London meeting is not to exceed US$734,000; and the Los Angeles meeting has a meeting facilities and production budget not to exceed US$568,000. These numbers are exclusive of other meeting-related costs.

      There will be a financial impact on ICANN in hosting the meeting and providing travel support as necessary, as well as on the community in incurring costs to travel to the meeting. But such impact would be faced regardless of the location of the meeting. There is no impact on the security or the stability of the DNS due to the hosting of the meeting.

      This is an Organizational Administrative Function for which public comment is not required.

    4. ACDR Proposal to be a UDRP Provider

      Whereas, the Arab Center for Dispute Resolution (ACDR) submitted a proposal to ICANN to be approved as an UDRP provider.

      Whereas, the ACDR proposal was posted for public comment on 28 September 2010 and a revised version was posted on 1 March 2013, which took into account comments received; ACDR has produced a further revised proposal addressing a final issue raised in the 1 March 2013 public comment forum.

      Whereas, the revised ACDR proposal meets the suggested elements as set forth in Information Concerning Approval Process for Dispute Resolution Service Providers.

      Resolved (2013.05.18.07), the Board approves the application of ACDR to become a UDRP provider, and advises the President and CEO, through the General Counsel's Office, to enter into discussions with ACDR regarding the process for ACDR's provision of UDRP services.

      Rationale for Resolution 2013.05.18.07

      The Board's approval of the ACDR application brings to a close the work of the ACDR (in cooperation with ICANN staff) in working to meet the standards and elements of the process for approval of Uniform Domain Name Dispute Resolution Policy ("UDRP") providers. This enhances ICANN's accountability through adherence to its processes. In addition, the approval of the first UDRP provider located in the Middle East enhances ICANN's accountability to the Internet community as a whole, enhancing choice for UDRP complainants.

      The ACDR's proposal was posted twice for public comment. All of the comments received were provided to ACDR for consideration. Some of the comments in opposition addressed issues such as the level of fees, which is fully within the ACDR's purview. Other commenters suggested that ICANN develop contracts with each of its UDRP providers as a means to require uniformity among providers. Contracts have never been required of UDRP providers. On the issue of uniformity among providers, however, the ACDR's proposal does two things: first, highlighted areas where risk of non-uniform conduct was perceived (such as issues with commencement dates and definitions of writings) have been modified; second, the proposal now includes an affirmative recognition that if ICANN imposes further requirements on providers, the ACDR will follow those requirements; third, the ACDR has revised a specific portion of its Supplemental Rules that was highlighted by commenters as a potential risk to uniformity. This is a positive advancement and helps address concerns of ICANN's ability to, in the future, identify areas where uniformity of action is of its obligation to abide by ICANN modifications that could enhance uniformity among providers.

      ICANN's consideration of the ACDR's proposal also highlights the import of accountability to the community. After the community requested the opportunity to see the proposal again prior to approval, the Board agreed and asked staff to proceed with a further comment period. In addition, the Board also requested that staff report to the community on how ICANN's earlier consideration of UDRP provider uniformity issues was concluded. As a result, a briefing paper has been prepared and will be publicly posted.

      There is a minimal resource impact on ICANN as a result of this decision in assuring that ICANN staff is available to work with the ACDR in starting and maintaining its work as a provider. There is no expected impact on the security, stability or the resiliency of the DNS as a result of this decision.

      This is an Organizational Administrative Function for which public comment was received.

      All members of the Board approved Resolutions 2013.05.18.01, 2013.05.18.02, 2013.05.18.03, 2013.05.18.04, 2013.05.18.05, 2013.05.18.06 and 2013.05.18.07. The Resolutions carried.

  2. Main Agenda:

    1. SSAC Advisory on Internal Name Certificates

      Ram Mohan provided a report to the Board on the work in the SSAC on internal name certificates, including in the report called SAC 057. In short, that is that in the world today there are many instances where you can go to inside of intranet, a company's intranet, and you can simply type in http colon double slash [insert TLD] and you would get to a corporate intranet as a short form. You don't need to type in the whole name or address that is actually assigned to that intranet. Several of the names that have been applied for in the new gTLD round are those that could be of this type. There are SSL providers today that would provide a valid SSL certificate for a name that just does not exist.

      There could be a risk of collision or clashes between unallocated TLDs, domain names, as well as names that are already in existence and in use in the world. This is of course a somewhat controversial issue given that we are midway or quite a bit of the way through the new gTLD process. So the recommendation from the SSAC is to commence a study that involves actual data, getting real data from the Root Server operators, from the SSL certificate vendors, collate that data, pull it all together, to task staff to work on that, and also task staff to work with RSSAC so that RSSAC can help with the coordination with Root Servers. In addition, the recommendation is to task staff to consult with SSAC in this process given that the origin of this work was from SSAC. Finally, to ask SSAC, after all of this analysis and after the study is done, if SSAC believes that it needs to update its recommendations to the Board.

      The SSAC recommends that this type of diligence should become part of the further expansion of the DNS. There was some debate internally within the SSAC, about whether we even needed this resolution, but the thought process was 1. it sends a message that the Board and ICANN is focused on this topic and is taking deliberate action on this topic, and 2. that there is a desire to get cooperation from within the ICANN SO/AC structure and from outside. Ram confirmed that this work is just the beginning; depending on the results of the work, if directed, there may be the need to consider how to handle strings that were applied for that may be causing this type of collision. The work ordered today will help gather the facts about this.

      Suzanne Woolf confirmed that some of this work is already underway, and noted that this work is precedential in the coordination among the SSAC, RSSAC, staff and consultants. There is a lot of good work already ongoing.

      Ray Plzak compared this issue to the issue with private IP addresses and private networks, and asked if there was any coordination underway with the IETF. Ray noted that it may be premature at this time, as the issue is still being scoped, but depending on the outcomes, the IETF has years of experience with this type of issue from the IP addressing side.

      Thomas Narten suggested that a clear deadline would be helpful in the resolution, in part to help understand the timetable for the roll out of new gTLDs.

      Akram Atallah confirmed that ICANN has already started scoping out this work and should have some timely information on this, and offered that the end of June would be feasible for reporting some of the study results back to the Board.

      Ram suggested that there could be dates included for the other portions of the work as well. The Chair recommended that instead of putting specific dates in that don't produce the best results, that the Board recognize the urgency and sensitivity on this matter, and request high levels of attention on this work.

      George Sadowsky noted that this work shows the import of the SSAC in identifying potential security issues and helping work through and recommend further action.

      Bruce Tonkin suggested that it would be helpful to have some of the data collected by the various surveys to be made available to others.

      Akram confirmed that it was his understanding that the data will be publicly available, though the sources may not always be identified in the posting. The Chair noted that this will allow the SSAC analysis to be on publicly available data, which is good.

      Suzanne expressed that the credibility of the results Is very important, and the principle stated is clear to everyone.

      Ray stressed that having a clear data collection plan will be very important, to assure that the right information is being gathered. Ram confirmed that the SSAC will bring in outside sources as necessary to make sure the correct data is collected. The Chair confirmed that this is an operational detail that will be left to staff to design.

      The Chair thanked the SSAC and the RSSAC for the initiative on this issue, and confirmed that the Board will continue to monitor this work. The Chair asked for an update at the next meeting.

      The Board then took the following action:

      Whereas, the delegation of TLDs in a way that promotes security and a good user experience is a longstanding topic of importance to ICANN's Board and the global Internet community.

      Whereas, on 15 March 2013, the ICANN Security and Stability Advisory Committee (SSAC) published SAC 057: SSAC Advisory on Internal Name Certificates.

      Whereas, enterprises have local environments that may include strong assumptions about which top-level domains exist at the root level of the public DNS, and/or have introduced local top-level domains that may conflict with names yet to be delegated at the root level of the public DNS.

      Whereas, in its stewardship role, ICANN wishes to determine what these potential clashes are.

      Resolved (2013.05.18.08), the Board directs the President and CEO, in consultation with the SSAC, to commission a study on the use of TLDs that are not currently delegated at the root level of the public DNS in enterprises. The study should consider the potential security impacts of applied-for new-gTLD strings in relation to this usage.

      Resolved (2013.05.18.09), the Board requests RSSAC to assist ICANN in the collection of data and observations related to root server operations that are relevant for the study, and to work with root server operators to enable sharing of such data and observations as appropriate, in the most expedient way possible.

      Resolved (2013.05.18.10), The Board directs the President and CEO to reach out to the Certificate Authority/Browser forum to collect statistics on the distribution of internal name certificates by top-level domain, in the most expedient way possible.

      Resolved (2013.05.18.11), the Board requests the SSAC to consider offering additional advice based on its assessment of the issues identified in the ICANN study, in the most expedient way possible.

      Rationale for Resolutions 2013.05.18.08 – 2013.05.18.11

      Why the Board is addressing the issue now?

      The internal certificate issue identified by SSAC in SAC 057 is a symptom that enterprises have local environments that include strong assumptions about the static number of top-level domains and/or have introduced local top-level domains that may conflict with names yet to be allocated. Regardless of whether these assumptions are valid or not, to be proactive in its stewardship role, ICANN wishes to determine what security and stability implications these potential conflicts have, especially since applications for new gTLDs are in the process of being evaluated by ICANN for delegation into the root. This study also sets a precedent for potential future TLD rounds, where similar studies might need to be conducted as a matter of due diligence.

      What are the proposals being considered?

      The Board requests the ICANN President and CEO to commission a study on the use of TLDs not currently delegated at the root level of the public DNS in enterprises. The study would also consider the potential security impacts of applied-for new-gTLD strings in relation to this usage. In fulfilling the study, the Board is also considering requesting RSSAC to assist root operators in providing some statistics and observations. Finally the Board is considering requesting the SSAC to consider whether it has additional advice for the Board based on its analysis of the study.

      What Stakeholders or others were consulted?

      The SSAC presented the "SAC 057: SSAC Advisory on Internal Name Certificates" to the ICANN community in Beijing. As a result, the SSAC received feedback from the community on this issue and their input informed the SSAC's request.

      What concerns or issues were raised by the community?

      Some community members have raised concerns about the use of TLDs that are not currently delegated at the root level of the public DNS and its impact to enterprises when ICANN delegates these TLDs into the public DNS. Some have asked for an evaluation of such risks so that the ICANN community can make informed decisions. Some have said that their studies show no significant risk to the security and stability of the DNS and have exhorted ICANN to continue on the course of evaluation and eventual delegation of all successful gTLD applications, regardless of conflict due to internal name certificates.

      What significant materials did Board review?

      The SSAC Report on Internal Name Certificates1 [PDF, 1.14 MB], The SSAC Report on invalid Top Level Domain Queries at the Root Level of the Domain Name System (15 November 2010 with corrections)2 [PDF, 507 KB], Report of the Security and Stability Advisory Committee on Root Scaling (6 December 2010)3 [PDF, 175 KB]

      What factors the Board found to be significant?

      In taking its action, the Board considered the recommendations of the SSAC in SAC 045, 046 and 057.

      Are there Positive or Negative Community Impacts?

      The Board's action to direct staff, through the President and CEO, to commission a detailed study on the risks related to the use of TLDs that are not currently delegated at the root level of the public DNS in enterprises will provide a positive impact on the community as it will enhance the understanding of this issue by providing additional information on security impacts of applied-for new-gTLD strings in relation to this usage. This will permit the community and the Board to understand in more detail the potential security and stability concerns if TLDs that are in conflict are delegated, and the impact on the overall functionality of the Internet.

      Are there fiscal impacts/ramifications on ICANN (Strategic Plan, Operating Plan, Budget); the community; and/or the public?

      This action is not expected to have an impact on ICANN's resources, and directing this work to be done may result in changes to the implementation plans for new gTLDs. While the study itself will not have a fiscal impact on ICANN, the community or the public, it is possible that study might uncover risks that result in the requirement to place special safeguards for gTLDs that have conflicts. It is also possible that some new gTLDs may not be eligible for delegation.

      Are there any Security, Stability or Resiliency issues relating to the DNS?

      SAC057 has identified several security risks to the DNS. This study intends to provide a more quantitative view of the problem, and to provide information that would inform future decisions.

      This is an Organizational Administrative Function for which public comment is not required. However, any recommendations arising out of the work directed through this resolution are likely to require community input prior to Board consideration.

      All members of the Board approved of Resolutions 2013.05.18.08 – 2013.05.18.11. The Resolutions carried.

    2. SSAC Budget Request

      Ray Plzak moved and Judith Vazquez seconded the proposed resolution.

      George Sadowsky then introduced the issue, noting that there were some community budget requests that cannot wait until approval of the entire annual budget. One of those requests was from the SSAC, and was not presented for approval with an earlier group of community requests. However, the Board Finance Committee believes that this request for SSAC member travel to the Durban meeting is reasonable and should be approved, and that is the recommendation to the Board.

      The Chair noted that there is a structure of supporting organizations and advisory committees within ICANN, and each serves different functions and purposes within ICANN. Particularly among the advisory committees, each group is very dissimilar from each other. As a result, it's hard to be formulaic in handling these types of requests, and treating each AC as if it is the same as the others. It is important for the role of each AC to be considered as part of the budget requests, as we value the role and time that each AC puts in. Here, the SSAC is comprised of independent experts that advise ICANN on security and stability, and that issue of a high priority to ICANN.

      The Board then took the following action:

      Whereas, on 11 April 2013, the Board approved SO/AC budget requests submitted through the Fast-Track Process for inclusion in the FY2014 Budget.

      Whereas, the Board did not approve at that time a request from the SSAC regarding additional travel to the ICANN meeting in Durban.

      Resolved, (2013.05.18.12), the Board now approves the SSAC request in the amount of US$20,000 for additional travel to the ICANN meeting in Durban for inclusion in ICANN's Fiscal Year 2014 budget as part of the SO/AC Additional Budget Requests Fast-Track Process.

      All members of the Board approved Resolution 2013.05.18.12. The Resolution carried.

      Rationale for Resolution 2013.05.18.12

      The SO/AC Additional Budget Requests submitted through a Fast-Track Process is leading to a budget approval earlier than usual and is a reasonable accommodation for activities that commence near the beginning of FY14. This slight augmentation to ICANN's established budget approval process and timeline helps facilitate the work of the ICANN Community and of the ICANN Staff, and does not create additional expenses.

      Upon the recommendation of the Board Finance Committee, and in light of the specific role that the SSAC plays within ICANN, this decision is important to the work regarding the security, stability and resiliency of the DNS, though no direct anticipated impact on the security, stability or resiliency on the DNS is expected as a result of this decision.

      This is an Organizational Administrative Function for which ICANN received community input.

    3. BGC Subcommittee for New gTLD-Related Reconsideration Requests

      Bruce Tonkin introduced the item, noting that on all matters, Board members have an ongoing dutiy to identify potential conflicts and disclose those conflicts. In terms of the New gTLD Program, there is also the New gTLD Program Committee which is a way to draw a bright line around the those members who are determined to have actual or potential conflicts of interest in relation to the Program. Within the Board Governance Committee, which hears and makes recommendations to the Board on Reconsideration Requests, some of the members of the BGC are not on the New gTLD Program Committee. Now that there are applicants who are not satisfied with results of the New gTLD Program, they are starting to bring Requests for Reconsideration, and there is expectation that this will continue. As a result, the BGC can take each Request on a case by case basis for conflicts determination, or a subcommittee can be formed, of those BGC members who are members of the New gTLD Program Committee, and that will be the base group of members that will hear new gTLD-related Requests. There is a concern that doing a case-by-case determination could be a burden, given the time sensitivity in responding to Requests for Reconsideration. As a result, the BGC recommends the use of a Subcommittee for this purpose. The Subcommittee would have the opportunity to bring in other members of the Board that have expertise on certain issues, if appropriate. Also the BGC Recommendations are publicly posted, so there could be a later chance for input as well, prior to Board or NGPC decision on a particular request.

      Ray Plzak asked about the quorum requirements and the optimal size of the Subcommittee. Ray noted a concern that if the Subcommittee is three members and only two were required for quorum, that would only be the two of the six members of the BGC, which could raise an optics issue.

      The General Counsel and Secretary confirmed that the BGC could recommend the optimal size. The recommendation here is that it be formed of the members of the BGC.

      Bruce confirmed that the BGC is only seeking Board approval for the formation of the Subcommittee at this time, and is not yet naming the membership of the Subcommittee, so those issues can be discussed further.

      George Sadowsky noted that he does not see the need for a Subcommittee, as the issue raised within a Reconsideration Request could be one where one of the excluded members acutlly doesn't have a conflict. The default should be allowing recusal when there's a conflict, not pre-determining the conflict.

      Bruce confirmed that this is creating an opt-in situation as opposed to an opt-out. It will be a standing committee that can be called on the short notice that is sometimes needed for Reconsideration Requests. Now, the fully BGC has to receive notice and participate in a meeting, and then determine the conflicts, which takes a lot of time. This is an efficiency measure, as is the NGPC.

      George noted that this is different from the NGPC, which covers a wide range of issues. Reconsideration Requests are on individual optics.

      Bruce confirmed that at no point is there an assumption that everyone present at the NGPC is unconflicted on a particular issue; the conflict determination needs to be made each time, just as with items in front of the Board.

      Olga Madruga Forti noted that there could be efficiencies from the subcommittee, and it is important for all on the Board to have decisions made without any suggestion of conflict of interest. The ability for conflicted directors to provide expertise seems to call this into question, so Olga requested more information on this process.

      Bruce confirmed that there could be situations where a director actually does not have a conflict of interest on a topic – then they could participate. Similarly, if a director has a specific expertise in an area, they could offer advice on that to the Board if invited. It goes to the opt-in versus opt-out structure.

      The Chair stated that one of the concerns may be that it is only at the Subcommittee or Board impetus to invite an interested director in because of expertise. It may be helpful to provide a mechanism for the director to self-identify the area of expertise.

      Bertrand de La Chapelle noted that its clear that the Board is trying to do the right thing and exemplify good behavior. But this also raises administrative issues of quorum and time and efficiency. Bertrand understood George's position, that the conflicts relating to the Reconsideration Requests arising out the New gTLD Program could be different than the conflicts as they relate generally to the Program. Reconsideration itself necessitates case-by-case decisions, and opt-out is likely the better way to go. There is also the possibility, as suggested by Ray, that quorum issues, mixed with specific conflict issues, could remove everyone from hearing the Request. Should an opt-in approach be ultimately chosen, it would be enhanced by providing more specifics on the expert-involvement process that Bruce was discussing.

      The Board then discussed some proposed modifications to the resolution, and Mike Silber raised the concern that this issue should go back to the BGC, as opposed to editing the resolution on the fly.

      Board members then agreed that it would be appropriate for the BGC to provide some more input on this matter, and that a vote on the proposed resolution should not happen at this time.

    4. Any Other Business

      The Board received a brief report from the President and CEO regarding an idea to creation some Presidential Advisory Groups on specific topic that could help build out some guidance for strategic issues faced by the organization. This item is still in its formative stages, and the President and CEO agreed to consult with interested members of the Board to help guide and frame the work of these committees. The President and CEO also reported to the Board on the development of a process for identification of an approval of Board travel needs outside of the ICANN meetings and Board workshops, as well as the use of the ICANN Speaker's Bureau process.

  3. Executive Session

    The Board entered an executive session without staff present. The Board undertook the following actions during its executive session:

    1. CEO At-Risk Compensation

      Whereas, each Board member has confirmed that he/she does not have a conflict of interest with respect to establishing the amount of payment for the President and CEO's FY13 T2 at-risk compensation payment.

      Whereas, the Compensation Committee recommended that the Board approve payment to the President and CEO for his FY13 T2 at-risk compensation.

      Resolved (2013.05.18.13), the Board hereby approves a payment to the President and CEO for his FY13 T2 at-risk compensation component.

      Resolved (2013.05.18.14), specific items within this resolution shall remain confidential as an "action relating to personnel or employment matters", pursuant to Article III, section 5.2 of the ICANN Bylaws.

      Rationale for Resolution 2013.05.18.xx

      When the President and CEO was hired, he was offered a based salary, plus an at-risk component of his compensation package. Consistent with all ICANN staff, the President and CEO is evaluated against specific goals that he sets in coordination with the Compensation Committee.

      In Beijing, the Compensation Committee recommended that the Board approve the President and CEO's at-risk Compensation for the second trimester of FY13 and the Board agrees with that recommendation.

      While this will have a fiscal impact on ICANN, it is an impact that was contemplated in the FY13 budget. This decision will not have an impact on the security, stability or resiliency of the domain name system.

      This in an Organizational Administrative Function that does not require public comment.

    2. Confidential Resolution

      [Resolutions Redacted]

      Resolved (2013.05.18.18), specific items of this resolution [Resolutions 2013.05.18.15, 2013.05.18.16 and 2013.05.18.17] shall remain confidential as an "action relating to personnel or employment matters", pursuant to Article III, section 5.2 of the ICANN Bylaws, and the entire resolution shall remain confidential pursuant to this same Bylaws provision pending determination by the President and CEO that the non-confidential portion can be made public.

      Rationale for Resolutions 2013.05.18.15 – 2013.05.18.18

      [Rationale Redacted]

Published on 28 June 2013

1 See http://www.icann.org/en/groups/ssac/documents/sac-057-en.pdf [PDF, 1.14 MB]

2 See http://www.icann.org/en/groups/ssac/documents/sac-045-en.pdf [PDF, 507 KB]

3 See http://www.icann.org/en/groups/ssac/documents/sac-046-en.pdf [PDF, 175 KB]

Related Documents