Skip to main content
Resources

Approved Board Resolutions | Regular Meeting of the ICANN Board

  1. Consent Agenda
    1. Approval of Board Meeting Minutes
    2. Appointment of Joe Abley to the Security & Stability Advisory Committee
    3. Technical Liaison Group Bylaws Revisions
    4. New gTLD Program Committee Membership
  2. Main Agenda
    1. Protection of IGO-INGO Identifiers in All gTLDs PDP
    2. Formation of Board Working Group on Nominating Committee Recruitment & Selection Process and Size & Composition
    3. GNSO Thick Whois Policy Development Process Recommendations

 

  1. Consent Agenda:

    1. Approval of Board Meeting Minutes

      Resolved (2014.02.07.01), the Board approves the minutes of the 8, 16, 17, 20 and 21 November Meetings of the ICANN Board.

    2. Appointment of Joe Abley to the Security & Stability Advisory Committee

      Whereas, the Security and Stability Advisory Committee (SSAC) does review its membership and make adjustments from time-to- time.

      Whereas, the SSAC Membership Committee, on behalf of the SSAC, requests that the Board should appoint Joe Abley to the SSAC.

      Resolved (2014.02.07.02), the Board appoints Joe Abley to the SSAC.

      Rationale for Resolution 2014.02.07.02

      The SSAC is a diverse group of individuals whose expertise in specific subject matters enables the SSAC to fulfill its charter and execute its mission. Since its inception, the SSAC has invited individuals with deep knowledge and experience in technical and security areas that are critical to the security and stability of the Internet's domain name system

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

      The SSAC's continued operation as a competent body is dependent on the accrual of talented subject matter experts who have consented to volunteer their time and energies to the execution of the SSAC mission. Joe Abley has been participating in the SSAC as part of his role as Director of DNS Operations at ICANN. He now has joined Dyn as a Principal Architect. Joe Abley brings experience regarding DNS operations and significant technical depth of understanding with respect to the DNS and DNS-related issues of the SSAC.

    3. Technical Liaison Group Bylaws Revisions

      Whereas, the ICANN Bylaws currently call for the Technical Liaison Group (TLG) to appoint a non-voting liaison to the ICANN Board as well as a voting delegate to the Nominating Committee (NomCom).

      Whereas, the Bylaws set out areas of responsibility for the entities comprising the TLG, including the appointment of experts from whom the ICANN Board can seek advice on relevant matters; these experts have never been appointed.

      Whereas, in 2011, ICANN commissioned a review of the TLG which identified that focus was needed to establish effective mechanisms to provide the Board with the technical advice that it may need, noting that the current form of operation of the TLG has not achieved this goal.

      Whereas, the proposed Bylaws revisions are intended to allow the component entities of the TLG to focus their energies on their advisory functions.

      Whereas, in resolution 2013.09.28.15, the Board directed the Chair of the ICANN Board, in coordination with the President and CEO, to initiate communications with the component entities of the TLG to facilitate their identification of experts in fulfillment of Article XI-A, Section 2, Paragraph 6 of the ICANN Bylaws and the resulting strengthening of the TLG advisory mechanism.

      Whereas, in resolution 2013.09.28.16 the Board directed the President and CEO to publish for public comment proposed Bylaws revisions relating to the TLG liaison to the Board and the appointment of a voting member of the Nominating Committee.

      Whereas, the proposed amendments were posted for public comment on 30 October 2013.

      Whereas, staff provided the Board with a summary and analysis of the public comment received.

      Whereas, the Board has reviewed and considered the summary and analysis of the public comment and has determined that the Bylaws revisions attached to the Reference Materials at Attachment A, address the issues discussed above.

      Resolved (2013.02.07.03), the Board approves the Bylaws revisions as they were posted for public comment at http://www.icann.org/en/news/public-comment/bylaws-amend-tlg-30oct13-en.htm, subject to two non-substantive changes made solely for clarification.

      Rationale for Resolution 2014.02.07.03

      Background on the TLG

      The Technical Liaison Group (TLG) is one of the advisory mechanisms set out in the ICANN Bylaws. One of the key functions that the TLG entities are supposed to perform include identifying and appointing experts to whom ICANN can direct technical questions. To date, these experts have not been appointed. The TLG is comprised of four organizations: (i) the European Telecommunications Standards Institute (ETSI); (ii) the International Telecommunications Union's Telecommunication Standardization Sector (ITU-T); (iii) the World Wide Web Consortium (W3C); and (iv) the Internet Architecture Board (IAB). The TLG has primarily focused its efforts on the annual appointment of a Liaison to the ICANN Board and a voting delegate to ICANN's Nominating Committee (NomCom). The need for the focus of the TLG to change has been an ongoing conversation within ICANN, as noted in the organizational review of the TLG that was commissioned by ICANN in 2010 (available at http://www.icann.org/en/groups/reviews/tlg), which resulted in recommendations to change the structure of the TLG.

      Why is the Board addressing the issue now?

      The ICANN Board has recently been reviewing the fundamental question of how it can obtain the advice that it needs. One core of that work is addressing how the Board receives the advice that it needs, and how the advice arising out of ICANN's advisory mechanisms is better tracked. Advice on technical matters is one of those key areas where the existing advisory mechanism of the TLG is not is not meeting the Board's needs or the mission as stated in the Bylaws. The Board's action today, addressing how to improve the advisory function of the TLG, is part of the Board's renewed focus on organizing and strengthening its activities.

      What is the proposal being considered?

      The action being considered today is to adopt the Bylaws revisions relating to the TLG that were posted for pubic comment. The effect of these revisions is the discontinuation of the TLG's appointment of a Liaison to the Board, as well the TLG's appointment of a voting delegate to the ICANN NomCom. The discontinuation of these appointment obligations should allow the TLG entities to focus their attention on the provision of advice to ICANN, as opposed to the appointment of individuals who are not authorized to represent the panoply of views of the entities within the TLG. Instead of focusing their efforts on the appointment of a Board Liaison or a NomCom delegate, the primary task remaining with each TLG entity will be to focus on the appointment of experts that the Board can call upon for advice.

      The Liaison role does not offer this more global access to expertise, as the TLG Liaison role rotates on an annual basis, and no one Liaison is able to deliver a coordinated position representing all of the TLG entities.

      The Bylaws revisions do not represent any change to the role of the TLG, which is to "channel technical information and guidance to the Board and other ICANN entities." Nor is there any change to four entities of the TLG. This proposed change is directed towards simplifying the role of the TLG entities in anticipation of the evolution and enhancement of how those entities provide technical advice to the Board.

      Which stakeholders or others were consulted?

      On 30 October 2013, ICANN initiated a public comment on the proposed Bylaws revisions. (See http://www.icann.org/en/news/public-comment/bylaws-amend-tlg-30oct13-en.htm.) The public comment forum closed on 20 December 2013. The Board has considered the one comment received in adopting this Resolution.

      What concerns or issues were raised by the community?

      ICANN received one substantive response during the course of the public comment forum. The commenter expressed support for the intent to increase the availability of technical advice to the Board and the effectiveness of the TLG. The commenter recommended that the elimination of the TLG Liaison not occur until, at least, a mechanism to seek regular advice from the TLG is in place. The commenter opposed the removal of the NomCom TLG delegate on the basis that the removal is likely to hinder the NomCom's community outreach to technical communities. (See http://forum.icann.org/lists/comments-bylaws-amend-tlg-30oct13/msg00002.html.)

      With respect to the strengthening of TLG advisory mechanism, the Board notes that this issue has already been addressed by the Board on 28 September 2013 in resolution 2013.09.28.15.

      With respect to the concern regarding outreach to the technical communities, the Board notes that each of the four organizations that make up the TLG are already engaged in ongoing community outreach efforts. The removal of the NomCom TLG delegate does not prevent these organizations from continuing with their outreach efforts.

      This action is anticipated to have a positive fiscal impact on ICANN. The removal of the Liaison to the Board and the NomCom will provide a financial savings to ICANN. This savings should be considered in the broader context of the additional costs that may be associated with the Board's commitment to strengthen the TLG advisory mechanism and with the TLG member entities identifying experts to provide ICANN with the technical advice called for in the Bylaws.1 Further, the anticipated evolution and enhancement of how ICANN receives advice on technical matters could have a positive impact on how ICANN addresses matters relating to the security, stability or resiliency of the DNS.

      The proposed Bylaws revisions were posted for public comment at http://www.icann.org/en/news/public-comment/bylaws-amend-tlg-30oct13-en.htm from 30 October 2013 to 20 December 2013. The Bylaws adopted do contain two non-substantive changes in Article XI, section 2.5 that were made for clarification purposes for which further public comment is not required.

      This decision is an Organizational Administrative Function that has already gone through a public comment period.

    4. New gTLD Program Committee Membership

      Whereas, on 10 April 2012 the Board created the New gTLD Program Committee, to which it delegated all legal and decision making authority of the Board relating to the New gTLD Program as set forth in its Charter, which excludes those things that the Board is prohibited from delegating by law, or pursuant to Article XII, Section 2 of the ICANN Bylaws.

      Whereas, the Board Governance Committee Subcommittee for Conflicts & Ethics on new gTLDs has determined that Steve Crocker no longer has a conflict of interest with respect to the New gTLD Program, and that determination has been accepted by the Board.

      Resolved (2014.02.07.04), Steve Crocker is hereby approved as a voting member of the New gTLD Program Committee (NGPC). The new membership of the NGPC is as follows:

      • Cherine Chalaby (Chair)
      • Fadi Chehadé
      • Steve Crocker
      • Chris Disspain
      • Heather Dryden (Liaison)
      • Bill Graham
      • Bruno Lanvin
      • Olga Madruga-Forti
      • Erika Mann
      • Gonzalo Navarro
      • Ray Plzak
      • George Sadowsky
      • Mike Silber
      • Jonne Soininen (Liaison)
      • Kuo-Wei Wu

      Rationale for Resolution 2014.02.07.04

      The Board reaffirms its Rationale for Resolutions 2012.04.10.01-2012.04.10.04, stating in full: In order to have efficient meetings and take appropriate actions with respect to the New gTLD Program for the current round of the Program and as related to the Applicant Guidebook, the Board decided to create the "New gTLD Program Committee" in accordance with Article XII of the Bylaws and has delegated decision making authority to the Committee as it relates to the New gTLD Program for the current round of the Program which commenced in January 2012 and for the related Applicant Guidebook that applies to this current round.

      Establishing the New gTLD Program Committee (NGPC) without conflicted members, and delegating to it decision making authority, has provided some distinct advantages, including helping eliminate any uncertainty for conflicted Board members with respect to attendance at Board meetings and workshops since the New gTLD Program topics can be dealt with at the Committee level. Further, it has provided the community with a transparent view into the Board's commitment to dealing with actual, potential or perceived conflicts.

      The Board Governance Committee (BGC) Subcommittee for Conflicts & Ethics on new gTLDs initially evaluated all Board members' statements of interest related to new gTLDs when the membership of the NGPC was first established. The Subcommittee continues to review new Board members' new gTLD related statements of interest and any changes in previously made statements of interest for the purposes of determining if any Board member (including voting Directors and no-voting Liaisons) has an actual, potential or perceived conflict of interest such they should not be a member of the NGPC.

      When the Subcommittee first evaluated the statements of interest, Steve Crocker was determined to be conflicted. Dr. Crocker has recently reported some changes to his statement of interest relating to new gTLDs and the Subcommittee has thoroughly evaluated those changes. The Subcommittee has determined the Steve Crocker is no longer generally conflicted as it relates to new gTLDs. As such, the Subcommittee has recommended that Dr. Crocker be made a voting member of the NGPC. The Board agrees.

      This resolution should have a positive impact on the community and ICANN as a whole, particularly the fact of increasing the number of Board members who participate in decisions surrounding the new gTLD Program.

      No fiscal impact is anticipated as a result of this action and there will be no impact on the security, stability and resiliency of the domain name system.

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

  2. Main Agenda:

    1. Protection of IGO-INGO Identifiers in All gTLDs PDP

      Whereas, on 17 October 2012, the GNSO Council launched a Policy Development Process (PDP) on the Protection of IGO-INGO Identifiers in All gTLDs addressing the questions set forth in the PDP Working Group Charter at http://gnso.icann.org/en/issues/igo-ingo-charter-15nov12-en.pdf [PDF, 189 KB].

      Whereas, the PDP followed the prescribed PDP steps as stated in the ICANN Bylaws and the GNSO PDP Manual, and resulted in a Final Report delivered to the GNSO Council on 10 November 2013.

      Whereas, the Protection of IGO-INGO Identifiers in All gTLDs Working Group (IGO-INGO WG) reached consensus on twenty-five recommendations in relation to the issues outlined in its Charter.

      Whereas, the GNSO Council reviewed, and discussed the recommendations of the IGO-INGO WG, and adopted the WG's consensus recommendations by a unanimous vote at its meeting on 20 November 2013 (see http://gnso.icann.org/en/council/resolutions#20131120-2).

      Whereas after the GNSO Council vote, a public comment period was held on the approved recommendations, and the comments received have been summarized and published (http://www.icann.org/en/news/public-comment/igo-ingo-recommendations-27nov13-en.htm).

      Whereas, the GAC advised the ICANN Board in the Buenos Aires Communiqué that it remained committed to continuing the dialogue with the NGPC on finalizing the modalities for permanent protection of IGO acronyms at the second level, and the NGPC is actively working on the issue.

      Resolved (2014.02.07.05), the Board acknowledges receipt of the GNSO Council's unanimous recommendations on the Protection of IGO-INGO Identifiers in All gTLDs as set forth in the IGO-INGO WG's Final Report (see http://gnso.icann.org/en/issues/igo-ingo-final-10nov13-en.pdf [PDF, 644 KB]), and requests additional time to consider the recommendations so that it may take into account advice from the GAC addressing the same topic.

      Resolved (2014.02.07.06), the Board directs the ICANN Board New gTLD Program Committee to: (1) consider the policy recommendations from the GNSO as it continues to actively develop an approach to respond to the GAC advice on protections for IGOs; and (2) develop a comprehensive proposal to address the GAC advice and the GNSO policy recommendations for consideration by the Board at a subsequent meeting.

      Rationale for Resolutions 2014.02.07.05 – 2014.07.06

      Why is the Board addressing this issue now?

      In response to the GAC advice on protecting the identifiers of the RCRC, IOC and IGOs in the New gTLD Program, the Board tasked the GNSO with developing policy in response to the GAC advice. In its deliberations, the GNSO Council determined that a Policy Development Process (PDP) was required to resolve the issue as to special protections of strings at the top and second levels for international organizations. In October 2012, the GNSO Council approved the initiation of a PDP on this issue. The PDP Working Group published its Initial Report for public comment on 14 June 2013, followed by its Final Report on 10 November 2013. The Final Report included over twenty consensus recommendations from the WG and Minority Statements from the RCRC, IGO and INGO representatives who participated in the WG, the GNSO's Non-Commercial Stakeholder Group and ICANN's At Large Advisory Committee. All the WG's consensus recommendations were approved unanimously by the GNSO Council.

      Following the closing of the public comment period on these recommendations and adoption by the GNSO Council of a Recommendations Report to the ICANN Board, the next step as outlined in Annex A of the ICANN Bylaws is consideration by the ICANN Board of the GNSO recommendations. The Bylaws require the Board to "meet to discuss" the GNSO policy recommendations "as soon as feasible, but preferably not later than the second meeting after receipt of the Board Report from the Staff Manager.

      In addition, Article XI, Section 2.1 of the ICANN Bylaws permits the GAC to "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." The GAC issued advice to the Board on the New gTLD Program through its Beijing Communiqué dated 11 April 2013, its Durban Communiqué dated 18 July 2013, and its Buenos Aires Communiqué dated 20 November 2013. The ICANN Bylaws require the Board to take into account the GAC's advice on public policy matters in the formulation and adoption of the polices. If the Board decides to take an action that is not consistent with the GAC advice, it must inform the GAC and state the reasons why it decided not to follow the advice. The Board and the GAC will then try in good faith to find a mutually acceptable solution. If no solution can be found, the Board will state in its final decision why the GAC advice was not followed.

      What is the proposal being considered?

      Before considering the resolving the substantive issues concerning the GNSO policy recommendations, the Board is considering how it would like to proceed on this topic as a procedural matter.

      The GNSO unanimously adopted the policy recommendations in the Final Report on the IGO-INGO PDP. The policy recommendations are being transmitted to the Board for review and consideration pursuant to the ICANN Bylaws. The GAC has also issued advice to the Board on protections for IGOs in the context of the New gTLD Program - most recently in its Buenos Aires Communiqué. Because the advice relates to the New gTLD Program, the ICANN Board New gTLD Program Committee (NGPC) is considering the GAC advice. The NGPC has not yet finalized is proposal to address the GAC's advice relating to protections for IGOs but is actively working on the issue.

      In general, the GNSO recommendations are largely consistent with the advice submitted by the GAC to the ICANN Board. However, there are specific GNSO policy recommendations that differ from the GAC's advice. At this time, the Board is considering acknowledging the policy recommendations of the GNSO in the Final Report on the IGO-INGO PDP, but requesting additional time to consider the recommendations given that the NGPC is actively working on addressing the GAC's advice on the same topic. The Board is considering taking a holistic approach to considering the GNSO policy recommendations and the GAC's advice by directing the NGPC to (1) consider the policy recommendations from the GNSO as it continues to actively develop an approach to respond to the GAC advice on protections for IGOs, and (2) develop a comprehensive proposal to address the GAC advice and the GNSO policy recommendations for consideration by the Board at a subsequent meeting.

      What significant materials did the Board review?

      The Board reviewed the GNSO Council Recommendations Report to the Board, the summary of public comments and the WG Final Report. The Board also reviewed the GAC's Beijing Communiqué, Durban Communiqué and Buenos Aires Communiqué.

      The concerns and issues raised by the community and stakeholders on the GNSO policy recommendations and the GAC's advice will be discussed when the Board considers the substance of the GNSO policy recommendations and the GAC's advice. At that time, the Board will also consider the fiscal impacts or ramifications on ICANN and the community. There are no security, stability, or resiliency issues related to the DNS if the Board approves the proposed recommendations.

      This decision is taken following a Policy Development Process that has been subject to a public comment process.

    2. Formation of Board Working Group on Nominating Committee Recruitment & Selection Process and Size & Composition

      Whereas the Board previously received the Final Report of the NomCom Finalization Review Working Group on 12 March 2010, which called for a review in three-years' time of issues of the composition, size and recruitment function of the Nominating Committee.

      Whereas the Structural Improvements Committee (SIC) recommends that it is time to complete the follow-up work anticipated in the Final Report and that a Board Working Group be established for such purpose.

      Resolved (2014.02.07.07), the Board approves the establishment of a Board Working Group on Nominating Committee (BWG-NomCom) in accordance with the Charter recommended by the SIC, the membership of which will be addressed by the Board Governance Committee.

      Rationale for Resolution 2014.02.07.07

      The Board is addressing the issue of NomCom recruitment and selection processes and the size and composition of NomCom, because NomCom plays a key role in the accountability mechanisms of ICANN. Because of the perceived deficiencies of the current NomCom structure and the changes in the composition of ICANN stakeholders, it is appropriate to address these critical issues at this time.2 The proposed Working Group is expected to consider matters of significance to the community, thus demonstrating ICANN's accountability in conducting the process of nominating qualified individuals into key leadership positions in a trusted and transparent manner. The Working Group will follow up on recommendations made in a previous organizational review mandated by ICANN bylaws, in line with the direction of the Review Finalization Working Group (recommendation 10) to address the size and composition and recruitment and selection functions of the NomCom.

      In considering this action, the Board reviewed materials referenced below and the recommendations offered by the SIC, including the Charter for the Working Group and considered the option of adding non-Board members to the Working Group for additional community perspective.

      There is no anticipated fiscal impact from this decision, and there will be no impact on the security, stability and resiliency of the domain name system as a result of this action.

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

      Related materials:

    3. GNSO Thick Whois Policy Development Process Recommendations

      Whereas, on 14 March 2012, the GNSO Council launched a Policy Development Process (PDP) on the use of 'thick' Whois by all gTLD Registries, both existing and future (see PDP WG Charter, set forth at https://community.icann.org/x/vIg3Ag).

      Whereas the PDP followed the prescribed PDP procedures as stated in the Bylaws and due process resulting in a Final Report delivered on 21 October 2013.

      Whereas the Thick Whois PDP Working Group (WG) reached full consensus on the recommendations in relation to the issues outlined in the Charter.

      Whereas the GNSO Council reviewed and discussed the recommendations of the Thick Whois PDP WG, and adopted the Recommendations on 31 October 2013 by a Supermajority and unanimous vote (see http://gnso.icann.org/en/council/resolutions#20131031-1).

      Whereas the GNSO Council vote exceeded the required voting threshold set forth in the ICANN Bylaws to impose new Consensus Policies on ICANN contracted parties.

      Whereas the GNSO Council resolved to convene a Thick Whois Implementation Review Team to assist ICANN Staff in developing the implementation details for the new policy should it be approved by the ICANN Board.

      Whereas after the GNSO Council vote, a public comment period was held on the approved recommendations, and the comments received strongly supported the recommendations (http://www.icann.org/en/news/public-comment/thick-whois-recommendations-06nov13-en.htm).

      Resolved (2014.02.07.08), the Board adopts the GNSO Council Policy Recommendations for a new Consensus Policy on Thick Whois as set forth in section 7.1 of the Final Report (see http://gnso.icann.org/en/issues/whois/thick-final-21oct13-en.pdf [PDF, 1.23 MB]).

      Resolved (2014.02.07.09), the Board directs the President and CEO to develop and execute on an implementation plan for the Thick Whois Policy consistent with the guidance provided by the GNSO Council. The President and CEO is authorized and directed to work with the Implementation Review Team in developing the implementation details for the policy, and to continue communication with the community on such work.

      Rationale for Resolutions 2014.02.07.08 – 2014.02.07.09

      Why is the Board addressing this issue now?

      ICANN specifies Whois service requirements for generic top-level domain (gTLD) registries through the Registry Agreement (RA) and the Registrar Accreditation Agreement (RAA). Registries and registrars satisfy their Whois obligations using different service models. The two common models are often characterized as "thin" and "thick" Whois registries. This distinction is based on how two distinct sets of data are managed. One set of data is associated with the domain name, and a second set of data is associated with the registrant of the domain name.

      • A thin registry only stores and manages the information associated with the domain name. This set includes data sufficient to identify the sponsoring registrar, status of the registration, creation and expiration dates for each registration, name server data, the last time the record was updated in its Whois data store, and the URL for the registrar's Whois service.

      • With thin registries, registrars manage the second set of data associated with the registrant of the domain and provide it via their own Whois services, as required by Section 3.3 of the RAA for those domains they sponsor. COM and NET are examples of thin registries.

      • Thick registries maintain and provide both sets of data (domain name and registrant) via Whois. INFO and BIZ are examples of thick registries.

      To explore the possible benefits of requiring all gTLD registries to provide thick Whois, the GNSO Council initiated a Policy Development Process on 14 March 2012. The PDP Working Group was formed and was tasked to consider the following topics as part of its deliberations:

      • Response consistency
      • Stability
      • Access to Whois data
      • Impact on privacy and data protection
      • Cost implications
      • Synchronization / migration
      • Authoritativeness
      • Competition in registry services
      • Existing Whois applications
      • Data escrow
      • Registrar Port 43 Whois requirements

      The Working Group published its Initial Report for public comment on 21 June 2013, followed by its Final Report on 21 October 2013, which received the unanimous consensus support from the PDP WG as well as the GNSO Council. A public comment period followed the GNSO Council vote, as specified in the ICANN Bylaws. The comments reflected strong support for the GNSO recommendations, with no opposition or concerns raised by any stakeholder group or constituency. As a result, this issue and the GNSO recommendations are ripe for consideration by the ICANN Board.

      What is the proposal being considered?

      The following recommendations are being considered:

      #1: The provision of thick Whois services, with a consistent labeling and display as per the model outlined in specification 3 of the 2013 RAA3, should become a requirement for all gTLD registries, both existing and future.

      Furthermore, the GNSO Council recommended that:

      #2: Following the adoption of the Final Report and recommendations by the GNSO Council, the subsequent public comment forum (prior to Board consideration) and the notification by the ICANN Board to the GAC, specifically request input on any considerations related to the transition from thin to thick Whois that would need to be taken into account as part of the implementation process.

      #3: As part of the implementation process a legal review of law applicable to the transition of data from a thin to thick model that has not already been considered in the Expert Working Group (EWG) memo4 is undertaken and due consideration is given to potential privacy issues that may arise from the discussions on the transition from thin to thick Whois, including, for example, guidance on how the long-standing contractual requirement that registrars give notice to, and obtain consent, from each registrant for uses of any personally identifiable data submitted by the registrant should apply to registrations involved in the transition. Should any privacy issues emerge from these transition discussions that were not anticipated by the WG and which would require additional policy consideration, the Implementation Review Team is expected to notify the GNSO Council of these so that appropriate action can be taken.

      Which stakeholders or others were consulted?

      In additional to regular updates to the GNSO Council, workshops were organized to inform and solicit the input from the ICANN Community at ICANN meetings (see for example http://durban47.icann.org/node/39777 and http://beijing46.icann.org/node/37029).

      Constituency / Stakeholder Group Statements were requested as well as input from other ICANN Supporting Organizations and Advisory Committees at an early stage of the process. Almost all GNSO Stakeholder Groups and Constituencies provided input, in addition to the At-Large Advisory Committee (see https://community.icann.org/x/WIRZAg).

      The WG also opened a public comment forum on the Initial Report on 21 June 2013.

      All comments received on the Initial Report have been reviewed and considered by the Thick Whois PDP Working Group (see section 6 of the Final Report).

      Furthermore, comments were solicited on the Final Report following GNSO Council approval and prior to consideration by the ICANN Board (see http://www.icann.org/en/news/public-comment/thick-whois-recommendations-06nov13-en.htm).

      In addition, the Board notified [PDF, 815 KB] the GAC of its upcoming consideration of this issue and at the request of the GNSO Council the GAC was specifically encouraged to provide any considerations related to the transition from thin to thick Whois that would need to be taken into account as part of the implementation process (no input has been received at the time of the submission of this paper).

      What concerns or issues were raised by the community?

      No community concerns have been raised in relation to the Final Report and its recommendations. All other comments received prior to the publication of the Final Report were reviewed and addressed by the PDP WG as outlined in section 6 of the Final Report and reflected in the WG's final recommendations.

      What significant materials did the Board review?

      The Board reviewed the GNSO Council Recommendations Report to the Board, as well as the summary of public comments. The Board also observed that although the Whois Review Team did not make any specific recommendations at the time of their Final Report [PDF, 1.44 MB] as no specific thick Whois policy existed to be reviewed, it did recommend that 'the Internet Service is overhauled to provide enhanced usability for consumers, including the display of full registrant data for all gTLD domain names' which would essentially be achieved by requiring all gTLDs to operate under a thick Whois model.

      What factors the Board found to be significant?

      The recommendations were developed following the GNSO Policy Development Process as outlined in Annex A of the ICANN Bylaws and have received the unanimous support from the GNSO Council. As outlined in the ICANN Bylaws, the Council's unanimous (supermajority) support for the motion obligates the Board to adopt the recommendation unless by a vote of more than two-thirds, the Board determines that the policy is not in the best interests of the ICANN community or ICANN.

      Are there positive or negative community impacts?

      Numerous benefits are expected as a result of requiring thick Whois for all gTLD registries, as outlined in the Thick Whois PDP Final Report (see http://gnso.icann.org/en/issues/whois/thick-final-21oct13-en.pdf [PDF, 1.23 MB]). Nevertheless, it should be recognized that a transition of the current thin gTLD registries will affect over 120 million domain name registrations. As a result, Staff intends to proceed carefully in the preparation and implementation of the recommended transition from thin to thick Whois. Staff expects there to be modest financial impacts associated with the transition as covered in section 5.6 of the Final Report- cost implications. Specifically, there will be a one-off cost involved in the actual transition from thin to thick, but Staff believes this can be managed in a way to minimize such costs. Moreover, recognizing that most registrars already transact registrations through thick TLDs and the only registry currently operating thin gTLDs (Verisign) also operates thick gTLDs, the affected contracted parties should not require a significant learning curve or new software systems in order to proceed with the transition.

      Are there fiscal impacts or ramifications on ICANN (strategic plan, operating plan, budget); the community; and/or the public?

      In addition to those changes required in process for registrars and gTLD registries as outlined in the previous section, there will likely be fiscal impacts related to implementation of the policy for example in relation to the requested legal review of potential privacy issues that may arise from the discussions on the transition from thin to thick Whois; updating of compliance complaint forms, FAQs and supporting documents, but these costs are anticipated to be within the current budget and/or will be anticipated for the next fiscal year starting in July 2014.

      Are there any security, stability or resiliency issues relating to the DNS?

      There are no security, stability, or resiliency issues related to the DNS if the Board approves the proposed recommendations, since thick Whois has already been implemented in other gTLD registries, and is a requirement for new gTLDs. Moreover, ICANN has experience in managing similar transitions such as when the .org registry was transitioned from a thin to a thick registry in 2004.

      This decision is taken following a Policy Development Process that has been subject to a public comment process.

Published on 11 February 2014


1 Rationale for Resolution 2014.02.07.03 was updated on 18 February 2014 to highlight that the fiscal impacts of adopting the resolution should be considered in context of additional costs that may be associated with the Board's previous commitment to strengthen the TLG advisory mechanism established in the Bylaws.

2 Errata Note: Rationale for Resolution 2014.02.07.07 was updated on 18 February 2014 to clarify that the Board's decision to create a NomCom Working Group is to address the perceived structural deficiencies of the NomCom – not the composition of the NomCom. The original text stated, "Because of the expressed concerns about the real and perceived deficiencies of the current NomCom and the changes in the composition of ICANN stakeholders, it is appropriate to address these critical issues at this time."

3 http://www.icann.org/en/resources/registrars/raa/approved-with-specs-27jun13-en.htm#whois

4 See http://forum.icann.org/lists/gnso-thickwhoispdp-wg/pdfLtpFBYQqAT.pdf [PDF, 146 KB]

Domain Name System
Internationalized Domain Name ,IDN,"IDNs are domain names that include characters used in the local representation of languages that are not written with the twenty-six letters of the basic Latin alphabet ""a-z"". An IDN can contain Latin letters with diacritical marks, as required by many European languages, or may consist of characters from non-Latin scripts such as Arabic or Chinese. Many languages also use other types of digits than the European ""0-9"". The basic Latin alphabet together with the European-Arabic digits are, for the purpose of domain names, termed ""ASCII characters"" (ASCII = American Standard Code for Information Interchange). These are also included in the broader range of ""Unicode characters"" that provides the basis for IDNs. The ""hostname rule"" requires that all domain names of the type under consideration here are stored in the DNS using only the ASCII characters listed above, with the one further addition of the hyphen ""-"". The Unicode form of an IDN therefore requires special encoding before it is entered into the DNS. The following terminology is used when distinguishing between these forms: A domain name consists of a series of ""labels"" (separated by ""dots""). The ASCII form of an IDN label is termed an ""A-label"". All operations defined in the DNS protocol use A-labels exclusively. The Unicode form, which a user expects to be displayed, is termed a ""U-label"". The difference may be illustrated with the Hindi word for ""test"" — परीका — appearing here as a U-label would (in the Devanagari script). A special form of ""ASCII compatible encoding"" (abbreviated ACE) is applied to this to produce the corresponding A-label: xn--11b5bs1di. A domain name that only includes ASCII letters, digits, and hyphens is termed an ""LDH label"". Although the definitions of A-labels and LDH-labels overlap, a name consisting exclusively of LDH labels, such as""icann.org"" is not an IDN."