Skip to main content
Resources

Approved Board Resolutions | Regular Meeting of the ICANN Board

  1. Consent Agenda:
    1. Approval of Board Meeting Minutes
    2. GNSO Council Recommendations Translation and Transliteration of Contact Information
    3. Renewal of .CAT Registry Agreement
    4. Renewal of .TRAVEL Registry Agreement
    5. Renewal of .PRO Registry Agreement
  2. Main Agenda:
    1. June 2016 ICANN Meeting Venue Contracting
    2. Contracting and Disbursement for New ERP Initiative
    3. Reserve Fund Release - USG IANA Stewardship Transition Costs
    4. New gTLD Program: Path to Future Rounds
    5. Insurance Requirements for Registrar Accreditation Agreement
    6. GNSO Policy & Implementation Recommendations
    7. Appointment of 2016 Nominating Committee Chair and Chair-Elect – EXECUTIVE SESSION

 

  1. Consent Agenda:

    1. Approval of Board Meeting Minutes

      Resolved (2015.09.28.01), the Board approves the minutes of the 16 July and 28 July 2015 Meetings of the ICANN Board.

    2. GNSO Council Recommendations Translation and Transliteration of Contact Information

      Whereas, on 13 June 2013, the GNSO Council launched a Policy Development Process (PDP) on the Translation and Transliteration, addressing two charter questions, set forth at http://gnso.icann.org/en/issues/gtlds/transliteration-contact-charter-20nov13-en.pdf [PDF, 185 KB].

      Whereas, the PDP followed the prescribed PDP steps as stated in the Bylaws, resulting in a Final Report delivered on 12 June 2015.

      Whereas, the Translation and Transliteration of Contact Information Working Group (WG) reached consensus on its first recommendation and full consensus on its remaining six recommendations.1

      Whereas, the GNSO Council reviewed, and discussed the recommendations of the Translation and Transliteration of Contact Information WG, and adopted the Recommendations on 24 June 2015 by a unanimous vote (see: http://gnso.icann.org/en/council/resolutions#20150624-3).

      Whereas, the GNSO Council vote met and exceeded the required voting threshold (i.e. supermajority) to impose new obligations on ICANN contracted parties; and

      Whereas, after the GNSO Council vote, a public comment period was held on the approved recommendations, and the comments have been summarized and considered (https://www.icann.org/public-comments/transliteration-contact-recommendations-2015-06-29-en).

      Resolved (2015.09.28.02), the Board adopts the GNSO Council Policy Recommendations concerning the translation and transliteration of contact information as presented in the Final Report.

      Resolved (2015.09.28.03), the CEO, or his authorized designee(s), is directed to develop and complete an implementation plan for these Recommendations and continue communication and cooperation with the GNSO Implementation Review Team and community on the implementation work.

      Rationale for Resolutions 2015.09.28.02 – 2015.09.28.03

      Why the Board is addressing the issue now?

      The continued internationalization of the domain name systems means that an ever-larger share of Internet users do not use (or are not even familiar) with US ASCII, the technical term for the Latin-based script used in English and many other western European languages.

      Accuracy and consistency of contact information data are crucial to make it a useful source to those seeking information regarding domain name registrants. This PDP WG has considered the important issue of whether translated and/or transliterated data or data submitted in the script best known to the registrant is more likely to deliver these requirements, bearing also in mind the amount of requests for such data and the costs associated with blanket translation or transliteration.

      The Translation and Transliteration PDP Final Report received consensus support on its first recommendation and full consensus on the remaining six others. It also received unanimous support from the GNSO Council.

      Following the closing of the public comment period, the next step as outlined in Annex A of the ICANN Bylaws is consideration by the ICANN Board of the recommendations.

      What is the proposal being considered?

      The following policy recommendations are being adopted:

      Recommendation #1 The Working Group recommends that it is not desirable to make transformation of contact information mandatory. Any parties requiring transformation are free to do so on an ad hoc basis outside Whois or any replacement system, such as the Registration Data Access Protocol (RDAP). If not undertaken voluntarily by registrar/registry (see Recommendation #5), the burden of transformation lies with the requesting party.

      Recommendation #2 Whilst noting that a Whois replacement system should be capable of receiving input in the form of non-ASCII script contact information, the Working Group recommends its data fields be stored and displayed in a way that allows for easy identification of what the different data entries represent and what language(s)/script(s) have been used by the registered name holder.

      Recommendation #3 The Working Group recommends that the language(s) and script(s) supported for registrants to submit their contact information data may be chosen in accordance with gTLD- provider business models.

      Recommendation #4 The Working Group recommends that, regardless of the language(s)/script(s) used, it is assured that the data fields are consistent to standards in the Registrar Accreditation Agreement (RAA), relevant Consensus Policy, Additional Whois Information Policy (AWIP) and any other applicable polices. Entered contact information data are validated, in accordance with the aforementioned Policies and Agreements and the language/script used must be easily identifiable.

      Recommendation #5 The Working Group recommends that if the transformation of contact information is performed, and if the Whois replacement system is capable of displaying more than one data set per registered name holder entry, these data should be presented as additional fields (in addition to the authoritative local script fields provided by the registrant) and that these fields be marked as transformed and their source(s) indicated.

      Recommendation #6 The Working Group recommends that any Whois replacement system, for example RDAP, remains flexible so that contact information in new scripts/languages can be added and expand its linguistic/script capacity for receiving, storing and displaying contact information data.

      Recommendation #7 The Working Group recommends that these recommendations are coordinated with other Whois modifications where necessary and are implemented and/or applied as soon as a Whois replacement system that can receive, store and display non-ASCII characters, becomes operational.

      Finding in relation to second Charter question Based on recommendations #1-#7, the question of who should decide who should bear the burden of translating or transliterating contact information to a single common script is moot.

      Recommendation 1 was accompanied by a Minority Statement, reading as follows: Working Group member Petter Rindforth, in line with the position taken by his Constituency, the Intellectual Property Constituency (ICP),2 recommends mandatory translation and/or transliteration (transformation) of contact information in all generic top-level domains (gTLDs).

      Although he agrees that there are situations where the contact information in the local language of the registrant is the primary version, such as to identify the registrant in preparation for a local legal action, there are a number of situations where a global WHOIS search, providing access to data in as uniform a fashion as possible, is necessary for the data registration service to achieve its goals of providing transparency and accountability in the DNS. See also 5.1.1 [of the Final Report] explaining the Working Group's arguments supporting mandatory transformation of contact information in all generic top-level domains.

      Which stakeholders or others were consulted?

      Regular consultation with stakeholders took place during the lifetime of this PDP, specifically during three ICANN meetings (ICANN 49, 50 and 51), as well as public comment periods for the Preliminary Issues Report, the Initial Report and prior to Board consideration.

      What concerns or issues were raised by the community?

      The main concern that was raised by the Community was that a multi-script / multi-language database will lead to less transparency because scripts other than Latin might be less comprehensible for a majority of internet users. It would also reduce the search-ability of data. It was also feared that fraudulent registrants could hide their identity behind different scripts/languages.

      What significant materials did the Board review?

      The Board reviewed the Final Report, the GNSO Council Recommendations Report to the Board, as well as the summary of public comments and Staff's response to those comments.

      What factors did the Board find 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 supermajority support for the motion (the Council voted unanimously in favor) 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. In addition, continuing the internationalization of the domain name system is an important area of work for ICANN. The recommendations have the potential to improve user-friendliness and accuracy of contact information data throughout a truly globalized DNS.

      Are there positive or negative community impacts?

      Some of the positive impacts identified in the Final Report include (but are not limited to):

      • Registrants not familiar with US-ASCII will be able to register domain names using the script they are most familiar with;
      • Registrars are not forced to translate or transliterate data but they have to validate data regardless of which script they support – the decision on which ones those are will be regulated by demand and supply;
      • Registration costs will not increase because requiring registrars to translate or transliterate all contact information data into one script3 will inevitably lead to costs that could be passed on to registrants;
      • Allowing registrants to use the language/script they are most familiar with when registering domains will have a positive impact on data accuracy.

      Some of the negative impacts identified in the Final Report are that:

      • Those seeking to search contact information data and operating in US-ASCII might have to translate or transliterate data to be able to contact registrants (though that is true for those seeking information but not familiar with US-ASCII even if translation or transliteration were mandatory).

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

      There are no fiscal impacts on ICANN. Those members of the community and wider public might have to pay for professional translation or transliteration of contact information. However, these costs stand in stark contrast to the potential costs that would occur if under a blanket requirement every contact that is provided in a script other than US-ASCII would have to be translated or transliterated.

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

      The current WHOIS protocol is not designed for scripts other than US-ASCII. However, the Registration Data Access Protocol (RDAP) is currently being rolled out as the WHOIS replacement and it [the RDAP] is fully compatible with different scripts. Once the RDAP is implemented – or any another replacement that is capable of dealing with scripts other than US-ASCII – there will be no security, stability, or resiliency issues related to the DNS if the Board approves the proposed recommendations.

    3. Renewal of .CAT Registry Agreement

      Whereas, ICANN commenced a public comment period from 28 May 2015 to 7 July 2015 <https://www.icann.org/public-comments/cat-renewal-2015-05-28-en> on a proposed renewal Registry Agreement for the .CAT TLD <https://www.icann.org/resources/unthemed-pages/cat-2012-02-25-en>.

      Whereas, the proposed .CAT renewal Registry Agreement includes modified provisions to bring the .CAT Registry Agreement into line with the form of the New gTLD Registry Agreement.

      Whereas, the public comment forum on the proposed renewal Registry Agreement closed on 7 July 2015, with ICANN receiving fifteen (15) comments, both by individuals and organizations/groups. A summary and analysis of the comments were provided to the Board.

      Whereas, the renewal registry agreement was updated to include existing provisions concerning Whois.

      Resolved (2015.09.28.04), the proposed renewal .CAT Registry Agreement [PDF, 621 KB] is approved, and the President and CEO, or his designee(s), is authorized to take such actions as appropriate to finalize and execute the Agreement.

      Rationale for Resolution 2015.09.28.04

      Why the Board is addressing the issue now?

      ICANN and Fundació puntCAT (the "Registry Operator") entered into a Registry Agreement on 23 September 2005 for operation of the .CAT top-level domain. The current .CAT Registry Agreement expires on 19 December 2015. The proposed renewal Registry Agreement (the "Renewal Registry Agreement" or "Agreement") was posted for public comment between 28 May 2015 and 7 July 2015. At this time, the Board is approving the Renewal Registry Agreement for the continued operation of .CAT TLD by the Registry Operator.

      What is the proposal being considered?

      The Renewal Registry Agreement approved by the Board includes modified provisions to make the Agreement in line with the form of the New gTLD Registry Agreement. The modifications include: updating technical specifications; requiring the inclusion of certain GAC safeguards as public interest commitments (which are subject to enforcement by the Public Interest Commitment Dispute Resolution Procedure); requiring the use of registrars under the 2013 Registrar Accreditation Agreement after a certain threshold is reached; and updating the registry fees.

      In order to account for the specific nature of the .CAT TLD, a Sponsored TLD, relevant provisions in the 23 September 2005 Sponsored TLD Registry Agreement have been included in the Renewal Registry Agreement. Specifically, provisions in the Charter outlining the Catalan Linguistic and Cultural Community on the Internet that are within the meaning of the community and eligible for registration are identified in Specification 12. The Renewal Registry Agreement also reflects previous approvals concerning reserved names.

      Which stakeholders or others were consulted?

      ICANN conducted a public comment period on the proposed .CAT renewal Registry Agreement from 28 May 2015 through 7 July 2015, following which time the comments were summarized and analyzed. Additionally, ICANN engaged in bilateral negotiations with the Registry Operator to agree to the package of terms to be included in the Renewal Registry Agreement posted for public comment.

      What concerns or issues were raised by the community?

      Fifteen (15) members of the community participated in the public comment period. Members of the community raised three key concerns in their comments:

      • Transition of legacy TLDs to the form of the New gTLD Registry Agreement: Some public comments expressed concern regarding ICANN's process to use the new gTLD registry agreement as the starting point for renewal RAs for legacy gTLDs. These commenters suggest that taking such a position has the effect of transforming the New gTLD Post-Delegation Dispute Resolution Procedures (e.g., the Trademark Post-Delegation Dispute Resolution Procedure and the Public Interest Commitments Dispute Resolution Procedure) and the Uniform Rapid Suspension (URS) into de facto Consensus Policies without following the procedures laid out in ICANN's Bylaws for their creation. On the other hand, other comments supported ICANN's seeking consistency across registry agreements and noted that transitioning to the new form of agreement is part of permissible bilateral negotiations.
      • Inclusion of Uniform Rapid Suspension (URS) and Trademark Dispute Resolution Procedure (PDDRP) in legacy TLD renewals without going through a Policy Development Process (PDP): most of the comments received expressed their objection to the inclusion of the URS to the proposed renewal of .CAT Registry Agreement, claiming that the URS can become a consensus policy only after a full policy development process (PDP) engaged in by the entire ICANN community of stakeholders. These commenters also suggested that imposing URS on a legacy gTLD via the contracting process is an unacceptable staff intervention into the policymaking process. On the other hand, some comments expressed their support of inclusion of the URS in the Renewal Registry Agreement, stating that registries are free to go above and beyond the minimum rights protections and do not require a PDP.

      What significant materials did the Board review?

      As part of its deliberations, the Board reviewed various materials, including, but not limited to, the following materials and documents:

      What factors has the Board found to be significant?

      The Board carefully considered the public comments received for Renewal Registry Agreement, along with the summary and analysis of those comments. The Board also considered the terms agreed to by the Registry Operator as part of the bilateral negotiations with ICANN. While the Board acknowledges the concerns expressed by some community members regarding the inclusion of the URS in the Renewal Registry Agreement, the Board notes that the inclusion of the URS in the Renewal Registry Agreement is based on the bilateral negotiations between ICANN and the Registry Operator, where Registry Operator expressed their interest to renew their registry agreement based on the new gTLD Registry Agreement.

      The Board notes that the URS was recommended by the Implementation Recommendation Team (IRT) as a mandatory rights protection mechanism (RPM) for all new gTLDs. The GNSO was asked to provide its view on whether certain proposed rights protection mechanisms (which included the URS) were consistent with the GNSO's proposed policy on the introduction of New gTLDs and were the appropriate and effective option for achieving the GNSO's stated principles and objectives. The STI considered this matter and concluded that "Use of the URS should be a required RPM for all New gTLDs." That is, the GNSO stated that the URS was not inconsistent with any of its existing policy recommendations.

      Although the URS was developed and refined through the process described here, including public review and discussion in the GNSO, it has not been adopted as a consensus policy and ICANN has no ability to make it mandatory for any TLDs other than new gTLD applicants who applied during the 2012 New gTLD round.

      Accordingly, the Board's approval of the Renewal Registry Agreement is not a move to make the URS mandatory for any legacy TLDs, and it would be inappropriate to do so. In the case of .CAT, inclusion of the URS was developed as part of the proposal in bilateral negotiations between the Registry Operator and ICANN.

      Additionally, the Board considered the comments regarding transitioning legacy gTLDs to the new form of the registry agreement. The Board notes that existing registry agreement calls for presumptive renewal of the agreement at its expiration so long as certain requirements are met. The renewal agreement is subject to the negotiation of renewal terms reasonably acceptable to ICANN and the Registry Operator. The renewal terms approved by the Board are the result of the bilateral negotiations called for in the current registry agreement, and transitioning to the new form of the registry agreement would not violate established GNSO policy. As described below, the new form of the registry agreement provides some operational advantages, in addition to benefits to registrants and the Internet community including public interest commitments, requiring the use of registrars under the 2013 RAA, and the ability for ICANN to designate an emergency interim registry operator in the event that emergency thresholds for critical registry services is reached.

      Are there positive or negative community impacts?

      As part of the renewal process, ICANN conducted a review of Registry Operator's recent performance under the current .CAT Registry Agreement. The Registry Operator was found to have substantially met its contractual requirements.

      The Board's approval of the Renewal Registry Agreement also offers positive technical and operational benefits. Pursuant to Renewal Registry Agreement, in the event that any of the emergency thresholds for registry functions is reached, Registry Operator agrees that ICANN may designate an emergency interim registry operator of the registry for the TLD, which would mitigate the risks to the stability and security of the Domain Name System. Also, technical onboarding of the Registry Operator to comply with the provisions in the new gTLD agreement will allow the Registry to use uniform and automated processes, which will facilitate operation of the TLD. The Renewal Registry Agreement also includes safeguards in the form of public interest commitments in Specification 11.

      There will also be positive impacts on registrars and registrants. Transition to the new gTLD Registry Agreement will provide consistency across all registries leading to a more predictable environment for end-users and also the fact that the proposed renewal Registry Agreement requires that the Registry Operator uses ICANN accredited registrars that are party to the 2013 Registrar Accreditation Agreement (RAA) only will provide more benefits to registrars and registrants.

      Protection of Rights holders: The new gTLD agreement will allow Registry Operator to adopt additional rights protection mechanisms to protect rights holders.

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

      There is no significant fiscal impact expected if ICANN approves the proposed .CAT renewal Registry Agreement. It should be noted however that as a result of approval of the Renewal Registry Agreement, projected annual registry fees decrease from $112,000USD to $56,000USD. The nominal fiscal impact is offset by the additional benefits to registrants and the Internet community including public interest commitments, requiring the use of registrars under the 2013 RAA, and the ability for ICANN to designate an emergency interim registry operator in the event that emergency thresholds for critical registry services is reached.

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

      There are no expected security, stability, or resiliency issues related to the DNS if ICANN approves the proposed .CAT renewal Registry Agreement. The proposed renewal Registry Agreement in fact includes terms intended to allow for swifter action in the event of certain threats to the security or stability of the DNS. As part of ICANN's organizational administrative function, ICANN posted the draft renewal Registry Agreement for public comment on 28 May 2015.

    4. Renewal of .TRAVEL Registry Agreement

      Whereas, ICANN commenced a public comment period from 12 May 2015 to 5 July 2015 <https://www.icann.org/public-comments/travel-renewal-2015-05-12-en> on a proposed renewal Registry Agreement for the .TRAVEL TLD <https://www.icann.org/resources/unthemed-pages/travel-2012-02-25-en>.

      Whereas, the proposed .TRAVEL renewal Registry Agreement includes modified provisions to bring the .TRAVEL Registry Agreement into line with the form of the New gTLD Registry Agreement.

      Whereas, the public comment forum on the proposed renewal Registry Agreement closed on 5 July 2015, with ICANN receiving fifteen (15) comments, both by individuals and organizations/groups. A summary and analysis of the comments were provided to the Board.

      Whereas, the Board has determined that no revisions to the proposed .TRAVEL renewal Registry Agreement are necessary after taking the comments into account.

      Resolved (2015.09.28.05), the proposed renewal .TRAVEL Registry Agreement [PDF, 621 KB] is approved, and the President and CEO, or his designee(s), is authorized to take such actions as appropriate to finalize and execute the Agreement.

      Rationale for Resolution 2015.09.28.05

      Why the Board is addressing the issue now?

      ICANN and Tralliance Registry Management Company, LLC (the "Registry Operator") entered into a Registry Agreement on 5 May 2005 for operation of the .TRAVEL top-level domain. The current .TRAVEL Registry Agreement expires on 19 October 2015. The proposed renewal Registry Agreement (the "Renewal Registry Agreement" or "Agreement") was posted for public comment between 12 May 2015 and 5 July 2015. At this time, the Board is approving the Renewal Registry Agreement for the continued operation of .TRAVEL TLD by the Registry Operator.

      What is the proposal being considered?

      The Renewal Registry Agreement approved by the Board includes modified provisions to make the Agreement in line with the form of the New gTLD Registry Agreement. The modifications include: updating technical specifications; requiring the inclusion of certain GAC safeguards as public interest commitments (which are subject to enforcement by the Public Interest Commitment Dispute Resolution Procedure); requiring the use of registrars under the 2013 Registrar Accreditation Agreement after a certain threshold is reached; and updating the registry fees.

      In order to account for the specific nature of the .TRAVEL TLD, a Sponsored TLD, relevant provisions in the 5 May 2005 Sponsored TLD Registry Agreement have been included in the Renewal Registry Agreement. Specifically, provisions in the Charter outlining the sectors of the travel industry that are within the meaning of the community and eligible for registration are identified in Specification 12. The Renewal Registry Agreement also reflects previous approvals concerning reserved names.

      Which stakeholders or others were consulted?

      ICANN conducted a public comment period on the proposed .TRAVEL renewal Registry Agreement from 12 May 2015 through 5 July 2015, following which time the comments were summarized and analyzed. Additionally, ICANN engaged in bilateral negotiations with the Registry Operator to agree to the package of terms to be included in the Renewal Registry Agreement posted for public comment.

      What concerns or issues were raised by the community?

      Fifteen (15) members of the community participated in the public comment period. Members of the community raised two key concerns in their comments:

      • Transition of legacy TLDs to the form of the New gTLD Registry Agreement: Some public comments expressed concern regarding ICANN's process to use the new gTLD registry agreement as the starting point for renewal RAs for legacy gTLDs. These commenters suggest that taking such a position has the effect of transforming the New gTLD Post-Delegation Dispute Resolution Procedures (e.g., the Trademark Post-Delegation Dispute Resolution Procedure and the Public Interest Commitments Dispute Resolution Procedure) and the Uniform Rapid Suspension (URS) into de facto Consensus Policies without following the procedures laid out in ICANN's Bylaws for their creation. On the other hand, other comments supported ICANN's seeking consistency across registry agreements and noted that transitioning to the new form of agreement is part of permissible bilateral negotiations.
      • Inclusion of Uniform Rapid Suspension (URS) and Trademark Dispute Resolution Procedure (PDDRP) in legacy TLD renewals without going through a Policy Development Process (PDP): most of the comments received expressed their objection to the inclusion of the URS to the proposed renewal of .TRAVEL Registry Agreement, claiming that the URS can become a consensus policy only after a full policy development process (PDP) engaged in by the entire ICANN community of stakeholders. These commenters also suggested that imposing URS on a legacy gTLD via the contracting process is an unacceptable staff intervention into the policymaking process. On the other hand, some comments expressed their support of inclusion of the URS in the Renewal Registry Agreement, stating that registries are free to go above and beyond the minimum rights protections and do not require a PDP.

      What significant materials did the Board review?

      As part of its deliberations, the Board reviewed various materials, including, but not limited to, the following materials and documents:

      What factors has the Board found to be significant?

      The Board carefully considered the public comments received for Renewal Registry Agreement, along with the summary and analysis of those comments. The Board also considered the terms agreed to by the Registry Operator as part of the bilateral negotiations with ICANN. While the Board acknowledges the concerns expressed by some community members regarding the inclusion of the URS in the Renewal Registry Agreement, the Board notes that the inclusion of the URS in the Renewal Registry Agreement is based on the bilateral negotiations between ICANN and the Registry Operator, where Registry Operator expressed their interest to renew their registry agreement based on the new gTLD Registry Agreement.

      The Board notes that the URS was recommended by the Implementation Recommendation Team (IRT) as a mandatory rights protection mechanism (RPM) for all new gTLDs. The GNSO was asked to provide its view on whether certain proposed rights protection mechanisms (which included the URS) were consistent with the GNSO's proposed policy on the introduction of New gTLDs and were the appropriate and effective option for achieving the GNSO's stated principles and objectives. The STI considered this matter and concluded that "Use of the URS should be a required RPM for all New gTLDs." That is, the GNSO stated that the URS was not inconsistent with any of its existing policy recommendations.

      Although the URS was developed and refined through the process described here, including public review and discussion in the GNSO, it has not been adopted as a consensus policy and ICANN has no ability to make it mandatory for any TLDs other than new gTLD applicants who applied during the 2012 New gTLD round.

      Accordingly, the Board's approval of the Renewal Registry Agreement is not a move to make the URS mandatory for any legacy TLDs, and it would be inappropriate to do so. In the case of .TRAVEL, inclusion of the URS was developed as part of the proposal in bilateral negotiations between the Registry Operator and ICANN.

      Additionally, the Board considered the comments regarding transitioning legacy gTLDs to the new form of the registry agreement. The Board notes that existing registry agreement calls for presumptive renewal of the agreement at its expiration so long as certain requirements are met. The renewal agreement is subject to the negotiation of renewal terms reasonably acceptable to ICANN and the Registry Operator. The renewal terms approved by the Board are the result of the bilateral negotiations called for in the current registry agreement, and transitioning to the new form of the registry agreement would not violate established GNSO policy. As described below, the new form of the registry agreement provides some operational advantages, in addition to benefits to registrants and the Internet community including public interest commitments, requiring the use of registrars under the 2013 RAA, and the ability for ICANN to designate an emergency interim registry operator in the event that emergency thresholds for critical registry services is reached.

      Are there positive or negative community impacts?

      As part of the renewal process, ICANN conducted a review of Registry Operator's recent performance under the current .TRAVEL Registry Agreement. The Registry Operator was found to have substantially met its contractual requirements.

      The Board's approval of the Renewal Registry Agreement also offers positive technical and operational benefits. Pursuant to Renewal Registry Agreement, in the event that any of the emergency thresholds for registry functions is reached, Registry Operator agrees that ICANN may designate an emergency interim registry operator of the registry for the TLD, which would mitigate the risks to the stability and security of the Domain Name System. Also, technical onboarding of the Registry Operator to comply with the provisions in the new gTLD agreement will allow the Registry to use uniform and automated processes, which will facilitate operation of the TLD. The Renewal Registry Agreement also includes safeguards in the form of public interest commitments in Specification 11.

      There will also be positive impacts on registrars and registrants. Transition to the new gTLD Registry Agreement will provide consistency across all registries leading to a more predictable environment for end-users and also the fact that the proposed renewal Registry Agreement requires that the Registry Operator uses ICANN accredited registrars that are party to the 2013 Registrar Accreditation Agreement (RAA) only will provide more benefits to registrars and registrants.

      Protection of Rights holders: The new gTLD agreement will allow Registry Operator to adopt additional rights protection mechanisms to protect rights holders.

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

      There is no significant fiscal impact expected if ICANN approves the proposed .TRAVEL renewal Registry Agreement. It should be noted however that as a result of approval of the Renewal Registry Agreement, the projected annual registry fees decrease from $46,000USD to $25,000USD. The nominal fiscal impact is offset by the additional benefits to registrants and the Internet community including public interest commitments, requiring the use of registrars under the 2013 RAA, and the ability for ICANN to designate an emergency interim registry operator in the event that emergency thresholds for critical registry services is reached.

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

      There are no expected security, stability, or resiliency issues related to the DNS if ICANN approves the proposed .TRAVEL renewal Registry Agreement. The proposed renewal Registry Agreement in fact includes terms intended to allow for swifter action in the event of certain threats to the security or stability of the DNS. As part of ICANN's organizational administrative function, ICANN posted the draft renewal Registry Agreement for public comment on 12 May 2015.

    5. Renewal of .PRO Registry Agreement

      Whereas, ICANN commenced a public comment period from 28 May 2015 to 7 July 2015 <https://www.icann.org/public-comments/pro-renewal-2015-05-28-en> on a proposed renewal Registry Agreement for the .PRO TLD. <https://www.icann.org/resources/unthemed-pages/pro-2012-02-25-en>.

      Whereas, the proposed .PRO renewal Registry Agreement includes modified provisions to bring the .PRO Registry Agreement into line with the form of the New gTLD Registry Agreement.

      Whereas, the public comment forum on the proposed renewal Registry Agreement closed on 7 July 2015, with ICANN receiving fourteen (14) comments, both by individuals and organizations/groups. A summary and analysis of the comments were provided to the Board.

      Whereas, the renewal registry agreement was updated to include existing provisions concerning third-level domain registrations.

      Resolved (2015.09.28.06), the proposed renewal .PRO Registry Agreement [PDF, 586 KB] is approved, and the President and CEO, or his designee(s), is authorized to take such actions as appropriate to finalize and execute the Agreement.

      Rationale for Resolution 2015.09.28.06

      Why the Board is addressing the issue now?

      ICANN and Registry Services Corporation (the "Registry Operator") entered into a Registry Agreement on 22 April 2010 for operation of the .PRO top-level domain. The current .PRO Registry Agreement expires on 20 October 2015. The proposed renewal Registry Agreement (the "Renewal Registry Agreement" or "Agreement") was posted for public comment between 28 May 2015 and 7 July 2015. At this time, the Board is approving the Renewal Registry Agreement for the continued operation of .PRO TLD by the Registry Operator.

      What is the proposal being considered?

      The Renewal Registry Agreement approved by the Board includes modified provisions to make the Agreement in line with the form of the New gTLD Registry Agreement. The modifications include: updating technical specifications; requiring the inclusion of certain GAC safeguards as public interest commitments (which are subject to enforcement by the Public Interest Commitment Dispute Resolution Procedure); requiring the use of registrars under the 2013 Registrar Accreditation Agreement after a certain threshold is reached; and removing the maximum price cap on fees the registry is able to charge registrars.

      Specifically, The existing Registration Restrictions in Appendix 11 of the .PRO Agreement are proposed to be replaced with the set of standard public interest commitments applicable to all new gTLDs. However, the proposed renewal registry agreement has been updated to include provisions regarding the registration of third-level domain names. Also, GAC Category 1 Safeguards 1 through 3 are added to Specification 11. The Renewal Registry Agreement also eliminates the cap on the service fees that the registry is able to registrars for domain names, and reflects previous approvals concerning reserved names.

      Which stakeholders or others were consulted?

      ICANN conducted a public comment period on the proposed .PRO renewal Registry Agreement from 28 May 2015 through 7 July 2015, following which time the comments were summarized and analyzed. Additionally, ICANN engaged in bilateral negotiations with the Registry Operator to agree to the package of terms to be included in the Renewal Registry Agreement posted for public comment.

      What concerns or issues were raised by the community?

      Fourteen (14) members of the community participated in the public comment period. Members of the community raised two key concerns in their comments:

      • Transition of legacy TLDs to the form of the New gTLD Registry Agreement: Some public comments expressed concern regarding ICANN's process to use the new gTLD registry agreement as the starting point for renewal RAs for legacy gTLDs. These commenters suggest that taking such a position has the effect of transforming the New gTLD Post-Delegation Dispute Resolution Procedures (e.g., the Trademark Post-Delegation Dispute Resolution Procedure and the Public Interest Commitments Dispute Resolution Procedure) and the Uniform Rapid Suspension (URS) into de facto Consensus Policies without following the procedures laid out in ICANN's Bylaws for their creation. On the other hand, other comments supported ICANN's seeking consistency across registry agreements and noted that transitioning to the new form of agreement is part of permissible bilateral negotiations.
      • Inclusion of Uniform Rapid Suspension (URS) and Trademark Dispute Resolution Procedure (PDDRP) in legacy TLD renewals without going through a Policy Development Process (PDP): most of the comments received expressed their objection to the inclusion of the URS to the proposed renewal of .PRO Registry Agreement, claiming that the URS can become a consensus policy only after a full policy development process (PDP) engaged in by the entire ICANN community of stakeholders. These commenters also suggested that imposing URS on a legacy gTLD via the contracting process is an unacceptable staff intervention into the policymaking process. On the other hand, some comments expressed their support of inclusion of the URS in the Renewal Registry Agreement, stating that registries are free to go above and beyond the minimum rights protections and do not require a PDP.

      What significant materials did the Board review?

      As part of its deliberations, the Board reviewed various materials, including, but not limited to, the following materials and documents:

      What factors has the Board found to be significant?

      The Board carefully considered the public comments received for Renewal Registry Agreement, along with the summary and analysis of those comments. The Board also considered the terms agreed to by the Registry Operator as part of the bilateral negotiations with ICANN. While the Board acknowledges the concerns expressed by some community members regarding the inclusion of the URS in the Renewal Registry Agreement, the Board notes that the inclusion of the URS in the Renewal Registry Agreement is based on the bilateral negotiations between ICANN and the Registry Operator, where Registry Operator expressed their interest to renew their registry agreement based on the new gTLD Registry Agreement.

      The Board notes that the URS was recommended by the Implementation Recommendation Team (IRT) as a mandatory rights protection mechanism (RPM) for all new gTLDs. The GNSO was asked to provide its view on whether certain proposed rights protection mechanisms (which included the URS) were consistent with the GNSO's proposed policy on the introduction of New gTLDs and were the appropriate and effective option for achieving the GNSO's stated principles and objectives. The STI considered this matter and concluded that "Use of the URS should be a required RPM for all New gTLDs." That is, the GNSO stated that the URS was not inconsistent with any of its existing policy recommendations.

      Although the URS was developed and refined through the process described here, including public review and discussion in the GNSO, it has not been adopted as a consensus policy and ICANN has no ability to make it mandatory for any TLDs other than new gTLD applicants who applied during the 2012 New gTLD round.

      Accordingly, the Board's approval of the Renewal Registry Agreement is not a move to make the URS mandatory for any legacy TLDs, and it would be inappropriate to do so. In the case of .PRO, inclusion of the URS was developed as part of the proposal in bilateral negotiations between the Registry Operator and ICANN.

      Additionally, the Board considered the comments regarding transitioning legacy gTLDs to the new form of the registry agreement. The Board notes that existing registry agreement calls for presumptive renewal of the agreement at its expiration so long as certain requirements are met. The renewal agreement is subject to the negotiation of renewal terms reasonably acceptable to ICANN and the Registry Operator. The renewal terms approved by the Board are the result of the bilateral negotiations called for in the current registry agreement, and transitioning to the new form of the registry agreement would not violate established GNSO policy. As described below, the new form of the registry agreement provides some operational advantages, in addition to benefits to registrants and the Internet community including public interest commitments, requiring the use of registrars under the 2013 RAA, and the ability for ICANN to designate an emergency interim registry operator in the event that emergency thresholds for critical registry services is reached.

      Are there positive or negative community impacts?

      As part of the renewal process, ICANN conducted a review of Registry Operator's recent performance under the current .PRO Registry Agreement. The Registry Operator was found to have substantially met its contractual requirements.

      The Board's approval of the Renewal Registry Agreement also offers positive technical and operational benefits. Pursuant to Renewal Registry Agreement, in the event that any of the emergency thresholds for registry functions is reached, Registry Operator agrees that ICANN may designate an emergency interim registry operator of the registry for the TLD, which would mitigate the risks to the stability and security of the Domain Name System. Also, technical onboarding of the Registry Operator to comply with the provisions in the new gTLD agreement will allow the Registry to use uniform and automated processes, which will facilitate operation of the TLD. The Renewal Registry Agreement also includes safeguards in the form of public interest commitments in Specification 11 including GAC Category 1 Safeguards 1 through 3.

      There will also be positive impacts on registrars and registrants. Transition to the new gTLD Registry Agreement will provide consistency across all registries leading to a more predictable environment for end-users and also the fact that the proposed renewal Registry Agreement requires that the Registry Operator uses ICANN accredited registrars that are party to the 2013 Registrar Accreditation Agreement (RAA) only will provide more benefits to registrars and registrants.

      Protection of Rights holders: The new gTLD agreement will allow Registry Operator to adopt additional rights protection mechanisms to protect rights holders.

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

      There is no significant fiscal impact expected if ICANN approves the proposed .PRO renewal Registry Agreement.

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

      There are no expected security, stability, or resiliency issues related to the DNS if ICANN approves the proposed .PRO renewal Registry Agreement. The proposed renewal Registry Agreement in fact includes terms intended to allow for swifter action in the event of certain threats to the security or stability of the DNS. As part of ICANN's organizational administrative function, ICANN posted the draft renewal Registry Agreement for public comment on 28 May 2015.

  2. Main Agenda:

    1. June 2016 ICANN Meeting Venue Contracting

      Whereas, ICANN intends to hold its second Public Meeting of 2016 in the Latin America/Caribbean region.

      Whereas, staff has completed a thorough review of the proposed venues in Latin America/Caribbean and finds the one in Panama City, Panama to be the most suitable.

      Resolved (2015.09.28.07), the Board authorizes the President and CEO, or his designee(s), to engage in and facilitate all necessary contracting and disbursements for the host hotel/convention center for the June 2016 ICANN Public Meeting in Panama City, Panama, in an amount not to exceed US$1.1 million.

      Resolved (2015.09.28.08), specific items within this resolution shall remain confidential for negotiation purposes pursuant to Article III, section 5.2 of the ICANN Bylaws until the President and CEO determines that the confidential information may be released.

      Rationale for Resolutions 2015.09.28.07 - 2015.09.28.08

      As part of ICANN's Public Meeting schedule, presently three times a year, ICANN hosts a meeting in a different geographic region (as defined in the ICANN Bylaws). ICANN 56, scheduled for 27-30 June 2016, is to occur in the Latin America/Caribbean geographic region. A call for recommendations for the location of the meeting in Latin America/Caribbean was posted on 23 March 2015. Various parties sent a proposal to ICANN.

      The staff performed a thorough analysis of the proposals, as well as other venues, and prepared a paper to identify those that met the Meeting Selection Criteria (see http://meetings.icann.org/location-selection-criteria). Based on the proposals and analysis, ICANN has identified Panama City, Panama as the location for ICANN 56.

      The Board reviewed staff's briefing for hosting the meeting in Panama City, Panama and the determination that the proposal met the significant factors of the Meeting Selection Criteria, as well as the related costs for facilities selected, for the June 2016 ICANN Public Meeting.

      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 and venue of the meeting. This action will have no impact on the security or the stability of the DNS.

      The Board thanks all who recommended sites for the ICANN 56.

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

    2. Contracting and Disbursement for New ERP Initiative

      Whereas, ICANN has an established a need to acquire an integrated enterprise resource planning (ERP) solution.

      Whereas, during its meeting on 11 September 2015, the Board Finance Committee reviewed the financial implications of a new ERP initiative, and has considered alternatives.

      Whereas, certain members of the Board Risk Committee have reviewed the suggested ERP solution and have provided guidance to staff on risks and useful mitigation actions.

      Whereas, both the staff and the Board Finance Committee have recommended that the Board authorize the President and CEO, or his designee(s), to take all actions necessary to execute the contracts for a new ERP initiative, as reflected in the Reference Materials to this Paper, and make all necessary disbursements pursuant to those contracts.

      Resolved (2015.09.28.09), the Board authorizes the President and CEO, or his designee(s), the take all necessary actions to execute the contracts for a new ERP solution, as reflected in the Reference Materials to this Paper, and make all necessary disbursements pursuant to those contracts.

      Resolved (2015.09.28.10), specific items within this resolution shall remain confidential for negotiation purposes pursuant to Article III, section 5.2 of the ICANN Bylaws until the President and CEO determines that the confidential information may be released.

      Rationale for Resolutions 2015.09.28.09 – 2015.09.28.10

      ICANN has grown in size and complexity over the past five years in many ways including, but not limited to the following: (i) staff multiplied by three; (ii) global presence expanded to three hubs and several engagement centers; and (iii) processes became more global and complex. Meanwhile, the infrastructure of separate back office Finance, HR and Procurement systems supporting the current organization was designed and implemented at least five years ago. Securing and implementing an integrated enterprise resource planning ERP solution under a single system of record will improve systems capacity, global reporting and analysis capability, and productivity and cross-functional efficiencies, and enhance internal controls, thus accelerating ICANN's progress towards operational excellence.

      The staff performed a thorough analysis of the two options available: (i) retrofitting the existing sets of systems to marginally improve their capabilities and develop interfaces where possible; and (ii) implementing an integrated ERP solution. Though the cost of the retrofit option would be lower in the first year, the five-year total costs would exceed significantly the integrated ERP option, as the retrofit would still require a significant upgrade during the five years. In addition, the retrofit would only marginally improve the back office capabilities and efficiencies, and require developing costly, complex and high maintenance interfaces with a resulting set of capabilities much below the integrated solution.

      As a result, the integrated ERP solution is considered a viable, more cost-effective solution.

      The integrated ERP solution project has been designed as follows:

      Internal resources: The project was considered early but delayed until senior resources with extensive experience were available within the staff and each business unit involved had reached the adequate level of maturity (IT, Finance, HR, Procurement). With the hiring of a Senior Director of IT in 2014 and a VP Finance in March 2015, both having extensive experience of large systems implementation projects, the conditions were met. The internal resources include:

      1. Three subject matter expert teams: each including two levels of experts (one lead, and experts for each function)
      2. Four backfilling resources covering the period of design and implementation to ensure daily operations are carried out while adequate expert focus is provided to the ERP project
      3. One dedicated project manager (contracted) with extensive ERP implementation experience.
      4. Three IT resources: one Senior Director of IT (oversight and management), one IT business analyst and one IT manager (one for HR, one for Finance/Procurement)
      5. A steering committee including: CIIO, COO, CFO and the Senior Director of IT
      6. One HR change management resource (to be hired)
      7. Embedded ERM reviews since inception of the project.

      External Resources:

      1. Larger ERP providers have a vast network of certified business partners as well as internal consulting resources that ICANN will draw from.
      2. ICANN will select the most qualified technical consultants through a process of individual interviews.

      Technical solution: A Software-as-a-Service (SaaS) model:

      1. One ready-to-configure web-based platform, used by all the customers of the solution provider
      2. Each customer configures a wide range of capabilities, to its business unit's needs (no software development, no customization)
      3. For each function, the range of standard and optional processes is designed on the basis of process and controls best practices, ready for configuration.
      4. Platform is regularly updated and has a rich roadmap of new capabilities made available to all customers in the platform at no additional cost
      5. System's performance is monitored and managed by SaaS supplier to Service Level Agreements (SLAs)

      System security:

      1. Data transfer: designed a multi-step data conversion strategy including testing, reconciliation and validation process.
        1. ICANN will be converting historical transactional data and all master file data.
        2. All conversion programs will be thoroughly tested for accuracy and completeness.
        3. ICANN will conduct unit testing, two Conference Room Pilots (CRP), which tests our business processes to system configuration and conversion of data files.
        4. ICANN will perform a Business Pilot, which will simulate actual business process from beginning to end (for example, Order to Cash and Procure to Pay) plus complete conversion testing for historical and master file data.
      2. Data security: RFP process includes demos on disaster recovery, data center operations management, data encryption, data logs, ERP environment exclusive to ICANN:
        1. ICANN will configure to world-class standards for data security, which include data encryption, management of access controls, access and review of system logs, and configuration of access security based on good internal controls.

      Further, the Board reviewed the staff's and the Board Finance Committee's recommendations for contracting and disbursement authority for a new ERP solution.

      There will be a financial impact on ICANN to implement a new ERP solution. This impact is currently included in the FY16 Operating Plan and Budget approved by the Board on 25 June 2015. This action will not have a direct impact on the security, stability and resiliency of the domain name system.

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

    3. Reserve Fund Release - USG IANA Stewardship Transition Costs

       Whereas, on 26 April 2015, the Board authorized the withdrawal of funds from the Reserve Fund to cover costs incurred in FY15 related to the USG IANA Stewardship Transition initiative in an amount not to exceed US$7 million.

      Whereas, ICANN has incurred actual costs during its FY15 of US$8.7 million, including unforeseen independent legal advice costs of approximately US$3.1 million.

      Whereas, the Board reiterates its statement made on 25 June 2015 that the Board is "committed to supporting the community in obtaining the advice it needs in developing recommendations in support of the transition process, and also notes the importance of making sure that the funds entrusted to ICANN by the community are used in responsible and efficient ways. Assuring the continuation of cost-control measures over the future work of the independent counsel is encouraged." (See https://www.icann.org/resources/board-material/resolutions-2015-06-25-en#2.c).

      Whereas, the Board Finance Committee has recommended that the Board authorize the release of funds from the Reserve Fund to cover the actual costs incurred in FY15 related to the USG IANA Stewardship Transition initiative in an amount of US$8.7 million, and the Board agrees.

      Resolved (2014.09.28.11), the Board authorizes the President and CEO, or his designee(s), to withdraw funds from the Reserve Fund to cover costs incurred in FY15 related to the USG IANA Stewardship Transition initiative in an amount of US$8.7 million.

      Rationale for Resolution 2015.09.28.11

      The USG IANA Stewardship Transition initiative is a major initiative to which the ICANN Community as a whole is dedicating a significant amount of time and resources. ICANN's support for the Community in its work towards a successful completion of the project (including both the USG IANA Stewardship transition proposal development and accountability work) is critical for ICANN.

      Considering its exceptional nature and the significant amount of costs anticipated to be incurred, the funding of this project could not be provided through the ICANN annual operating revenue. Accordingly, when the Board approved the FY15 Operating Plan and Budget, it included the anticipated funding of the project costs (US$7 million) through a corresponding withdrawal from the Reserve Fund.

      As costs were incurred during FY15 for this project, the Board approved the withdrawal of funds from the Reserve Fund to cover the actual costs incurred in FY15 related to USG IANA Stewardship Transition initiative, up to the amount of US$7 million included in the Board approved FY15 Operating Plan and Budget.

      As the total actual costs incurred during FY15 for this project totaled US$8.7 million thus exceeding the total amount of US$7 million of withdrawal from the Reserve Fund that the Board had authorized in its decision 2015.04.26.17, ICANN is proceeding with obtaining approval from the Board to withdraw funds from the Reserve Fund for the total amount of actual costs incurred of US$8.7 million. This action will not have a direct impact on the security, stability and resiliency of the domain name system.

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

    4. New gTLD Program: Path to Future Rounds

      Whereas, Board resolution 2012.02.07.05 reaffirmed ICANN's commitment to opening an additional round of the New gTLD Program as expeditiously as possible.

      Whereas, the reviews of the 2012 round of the New gTLD Program are currently underway.

      Whereas, the Board encourages stakeholder participation in the bottom-up process to review and develop future rounds of the New gTLD Program.

      Resolved (2015.09.28.12), the Board directs ICANN staff to continue with the reviews of the New gTLD Program as scheduled, and encourages the stakeholder community to participate and support a robust and meaningful review process.

      Resolved (2015.09.28.13), the Board will follow the community work with interest and will consider guidance on future rounds once the review process and potential GNSO policy development process reach a more advanced stage.

      Rationale for Resolutions 2015.09.28.12 – 2015.09.28.13

      Why is the Board addressing this issue now?

      Numerous review and community activities are currently underway that will likely inform when the next round will take place and how it will be carried out. The Board has been asked to consider a process and timeframe for an additional round of the New gTLD Program in order to assist ICANN in the long-term planning, analysis, and budgeting necessary to achieving an effective next round.

      What are the proposals being considered?

      The Board is considering the extent to which the numerous review processes and community activities currently underway will inform when and how the next round of the New gTLD Program will be undertaken. Three options have been considered. The first establishes a target date for community input into future rounds and provides an approximate timeframe for the completion of the review process and possible PDP. It does not commit any party to a strict deadline for completion of any review or policymaking activity, but rather provides an approximate timeframe for all parties to assist their planning. The second option establishes an anticipated process by which the Board would first consider review results before tasking staff with developing implementation plans and timeframes. The third defers the establishment of a timeframe or set of prerequisites for the next found until the review process and/or PDP reach a more advanced stage.

      The Board is taking action at this time to encourage continued execution and participation in the current review processes and to defer consideration of future round planning until the reviews are at a more advanced stage.

      What stakeholders or others were consulted?

      Beginning in September 2014, ICANN staff published and collected feedback on the draft Work Plan for the New gTLD Program reviews.4 The GNSO Discussion Group on New gTLD Subsequent Procedures has played a significant role in discussing policy implications and development for the new gTLD program. While the GNSO has not formally been consulted, a recurring theme in the group's discussions has centered on what future processes should be considered in determining the next round's development. In addition, community stakeholders such as contracted parties, new registry operators, ISPs and IP operators, and members of the end-user community have all contributed their perspectives on the next round's timeframe.

      What significant materials did the Board review?

      The Board reviewed the draft Work Plan, Affirmation of Commitments (AoC), the estimated timeline for review completion based on initial estimates of activities described in the Work Plan, the GNSO Preliminary Issue Report of 31 August 2015 as well as the GNSO discussions on which it was based, Resolutions 2012.02.07.05 and 2014.11.17.10 – 2014.11.17.12 regarding commitments to open a second round as expeditiously as possible and in consultation with relevant stakeholder groups, and the Rights Protection Mechanisms Review of the safeguards put in place to mitigate potential issues with the New gTLD Program.

      What factors did the Board find to be significant?

      Given that the results of the review process are unknown and a PDP may be initiated, it is unrealistic at this early stage to establish a timeframe for opening an additional round of the New gTLD Program. The Board understands that a desire for more certainty exists throughout much of the stakeholder community, but considers it a priority at this stage to conduct meaningful reviews of the current round. It will revisit discussions of timelines and processes for future rounds at a later point.

      Are there Positive or Negative Community Impacts?

      Some in the community will likely be frustrated at the lack of commitment to a definitive timeframe or procedure. However, the Board's action attempts to ensure that adequate weight is given to the review process in order to fully assess the results of the first round of the New gTLD Program. This may be seen by some constituencies as non-responsive to questions regarding how the various reviews and processes currently underway are expected to lead to the opening of a second round. However, this approach allows for continuing community dialogue regarding the critical areas to be addressed in creating this set of steps. Moving too quickly to a second round without adequate time for review may inhibit the community from adequately considering lessons learned from the first round as part of the development of the next round. Additionally, committing to a timeframe or expected process may create unrealistic expectations on the part of stakeholder communities as to when a second round can be expected to take place.

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

      Some of the Program reviews require engaging specialized expertise, and funds have been allocated to these activities in the FY16 budget. However, there are no anticipated additional budget implications resulting from this resolution not already planned for and/or allocated.

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

      There is no immediate impact to the security, stability or resiliency of the DNS as a result of taking this resolution, but it should be noted that security, stability and resiliency of the DNS is one of the proposed areas of study.

      Is this either a defined policy process within ICANN's Supporting Organizations or ICANN's Organizational Administrative Function decision requiring public comment or not requiring public comment?

      This is not a defined policy process, as the results of the first round of the New gTLD Program have yet to be assessed and a definite policy process has yet to be established. It is likely, however, that the reviews and PDP will be subject to public comment once completed.

    5. Insurance Requirements for Registrar Accreditation Agreement

      Whereas, ICANN's Statement of Registrar Accreditation Policy ("Accreditation Policy"), adopted in 1999, provides that registrars must have and maintain commercial general liability ("CGL") insurance policies with limits of at least US$500,000, or a lesser amount if the registrar can demonstrate that a lower limit would still provide for reasonable compensation in the event of a covered loss.

      Whereas, Registrar Accreditation Agreements require that registrars maintain coverage at the US$500,000 level (without reference to the Accreditation Policy's potentially lower limits).

      Whereas, ICANN received feedback that the RAA's CGL insurance requirements do not further the Statement of Registrar Accreditation Policy's intent for the CGL insurance requirement of providing registrants with a remedy in the event of a registrar's wrongful covered acts and poses an obstacle for the development of the registrar market in developing countries.

      Whereas, ICANN solicited two rounds of public comments on this topic in May 2014 and January 2015.

      Resolved (2015.09.28.14), the CGL insurance requirement in the 2009 and 2013 RAAs is waived, and the President and CEO, or his designee(s), is directed to take the necessary steps to implement this resolution.

      Resolved (2015.09.28.15), the GNSO is requested to consider whether policy work on replacement insurance requirements should be undertaken in light of the Statement of Registrar Accreditation Policy.

      Rationale for Resolutions 2015.09.28.14 – 2015.09.28.15

      Why the Board is addressing the issue now?

      The 2009 and 2013 Registrar Accreditation Agreements require registrars to obtain Commercial General Liability insurance with a policy limit of at least US$500,000. This requirement is based on language in ICANN's Statement of Registrar Accreditation Policy, which states that registrars must have and maintain commercial general liability (CGL) insurance policies with limits of at least US$500,000, or a lesser amount if the registrar can demonstrate that a lower limit would still provide for reasonable compensation in the event of a covered loss. The RAA requirement does not incorporate the Statement of Accreditation Policy's flexibility for lower policy limits.

      CGL insurance policies generally protect businesses against liability claims for bodily injury and property damage that occur on their premises, as well as for advertising and personal injury liability in some cases. However, most CGL policies would exclude coverage for errors and omissions by the registrar. In other words, domain name holders generally would not be able to receive compensation from an insurance company (under a CGL policy) for negligent acts by the registrar, such as accidentally deleting or failing to renew a registration, or allowing a domain name to be hijacked.

      This insurance requirement poses both financial and practical challenges for some entities that seek to become an ICANN-accredited registrar. Comments from the community suggest that this requirement disproportionately disadvantages registrars and prospective registrars in places where this type of insurance is unduly expensive and/or nonexistent.

      Thus, the Board is taking action at this time to approve a waiver of the existing CGL insurance requirement in the 2009 and 2013 RAAs because Commercial General Liability insurance requirements do not seem to further their intended policy goals and pose an undue burden to prospective registrars. Despite considerable public consultation, there is no evidence that the CGL requirement has provided any benefit to registrants.

      Which stakeholders or others were consulted?

      ICANN has received feedback from prospective registrars that the required insurance in their region is difficult or impossible to obtain. ICANN conducted a workshop discussing this and other topics related to underserved regions at the Singapore ICANN meeting in 2014. ICANN has consulted with an outside insurance consultant, as well as many current and prospective registrars. ICANN solicited two rounds of public comments on this topic in May 2014 and January 2015. As part of the Board's action, the Board is encouraging the GNSO to examine this issue.

      What concerns or issues were raised by the community?

      Community members have reported to ICANN that the existing insurance requirement can be difficult or impossible to meet in many jurisdictions, particularly in jurisdictions outside North America and Europe. Some people commented that CGL insurance is not available at all in some countries and, although available in other countries, the $500,000 limit might be excessive (and therefore commercially infeasible), relative to market conditions, the cost of living, and the risks of doing business in the respective region. In addition, some commenters questioned whether the requirement remains necessary given ICANN's institutional improvements in other areas, such as compliance enforcement and data escrow. Some community members have suggested ICANN might provide new and existing registrars with a list of insurers who are known to serve existing registrar businesses so that registrars can secure the insurance required to gain ICANN accreditation.

      Other community members, however, have cautioned that registrants could be left unprotected if the CGL requirement is waived.

      What materials did the Board consider when making this decision?

      In reaching this decision, the Board considered two reports of public comments on this issue, published on 2 September 2014 [PDF, 405 KB] and 3 April 2015 [PDF, 516 KB] and Board reference materials. The Board also considered the Statement of Registrar Accreditation Policy, as well as the 2009 and 2013 Registrar Accreditation Agreements.

      What factors did the Board find to be significant when making this decision?

      The existing insurance requirement does not serve its originally intended purpose of protecting registrants from wrongful acts by registrars. Furthermore, the requirement is inhibiting competition in underserved regions of the world. Because the original insurance requirement was a matter of ICANN policy, the GNSO is the appropriate body to decide whether a replacement requirement is appropriate.

      What are the fiscal impacts of this decision?

      This decision has no fiscal impact on ICANN. Eliminating the requirement could reduce costs to registrars and prospective registrars who elect not to maintain commercial general liability insurance.

      What are the impacts of this decision on the community?

      Based on all of the information received to date, it appears that there will be no negative impact on registrants, other stakeholders, or the global public interest if the Board approves the waiver of the insurance requirement.

      This decision will have a positive impact on prospective and existing registrars, particularly those in regions where CGL insurance is unduly expensive or impossible to obtain. The impact is likely to be primarily financial, but may also encourage addition applications for registrar accreditation from both developed and developing countries.

      Approval by the Board of a waiver of the insurance requirement will further ICANN's efforts to promote registrar competition in a global environment and give the GNSO the opportunity to consider whether a replacement insurance requirement would be appropriate.

      What are the impacts on the security and stability of the Internet?

      Approval of the resolution will not impact security, stability or resiliency issues relating to the DNS.

    6. GNSO Policy & Implementation Recommendations

      Whereas, On 17 July 2013, the GNSO Council approved the charter for a GNSO non-PDP Policy and Implementation Working Group (http://gnso.icann.org/en/council/resolutions#201307) tasked to provide the GNSO Council with a set of recommendations on:

      • A set of principles that would underpin any GNSO policy and implementation related discussions, taking into account existing GNSO Operating Procedures.
      • A process for developing gTLD policy, perhaps in the form of "Policy Guidance", including criteria for when it would be appropriate to use such a process (for developing policy other than "Consensus Policy") instead of a GNSO Policy Development Process.
      • A framework for implementation related discussions associated with GNSO Policy Recommendations.
      • Criteria to be used to determine when an action should be addressed by a policy process and when it should be considered implementation.
      • Further guidance on how GNSO Implementation Review Teams, as defined in the PDP Manual, are expected to function and operate.

      Whereas, the GNSO Policy and Implementation Working Group published its Initial Recommendations Report for public comment on 19 January 2015 (see https://www.icann.org/public-comments/policy-implementation-2015-01-19-en).

      Whereas, the GNSO Policy and Implementation Working Group reviewed the input received (see public comment review tool [DOC, 267 KB]) and updated the report accordingly resulting in a Final Recommendations Report, which was submitted to the GNSO Council on 2 June 2015.

      Whereas, the Final Recommendations Report (see http://gnso.icann.org/en/drafts/policy-implementation-recommendations-01jun15-en.pdf [PDF, 1.53 MB]) was adopted unanimously by the GNSO Council on 24 June 2015.

      Whereas, on 28 July 2015, the ICANN Board directed ICANN Staff to post the proposed changes to the ICANN Bylaws as a result of the proposed recommendations in the Final Recommendations Report for public comment (see https://www.icann.org/public-comments/bylaws-amendments-2015-07-31-en).

      Whereas two comments was received in support of the proposed recommendations, including one Advice Statement from the ALAC.

      Whereas the ATRT2 recommended that "the Board should continue supporting cross-community engagement aimed at developing an understanding of the distinction between policy development and policy implementation. Develop complementary mechanisms whereby the Supporting Organizations and Advisory Committees (SO/AC) can consult with the Board on matters, including but not limited to policy, implementation and administrative matters, on which the Board makes decisions" (Recommendation #4).

      Resolved (2015.09.28.16), the Board approves the amendments to the ICANN Bylaws Article X, section 3-9 as posted for public comment addressing the new GNSO voting thresholds resulting from the GNSO Guidance Process (GGP) and GNSO Expedited Policy Development Process (EPDP).

      Resolved (2105.09.28.17), the Board approves the amendments to ICANN Bylaws Annex A as posted for public comment (see https://www.icann.org/en/system/files/files/bylaws-proposed-amendments-gnso-policy-implementation-31jul15-en.pdf [PDF, 656 KB]), creating a new Annex A-1 that outlines the GNSO EPDP.

      Resolved (2015.09.28.18), the Board approves the amendments to ICANN Bylaws Annex A as posted for public comment (see https://www.icann.org/en/system/files/files/bylaws-proposed-amendments-gnso-policy-implementation-31jul15-en.pdf [PDF, 656 KB]), creating a new Annex A-2 that outlines the GNSO GGP.

      Resolved (2015.09.28.19), the Board endorses the set of GNSO principles / requirements as they relate to policy & implementation as outlined in section 4 of the Final Recommendations Report, and directs the President and CEO, or his designee(s), as well as the ICANN community to take these principles and requirements into account as it engages on GNSO policy and implementation related issues.

      Resolved (2015.09.28.20), the Board endorses the Implementation Review Team Guidelines & Principles as outlined in Annex L of the Final Recommendations Report and directs ICANN Staff as well as the ICANN community to take these Guidelines and Principles into account as it engages on implementation related issues.

      Resolved (2015.09.28.21), the Board acknowledges the Advice provided by the ALAC and commits to carefully monitor GNSO policy development activities to ensure that user and public interests are appropriately considered and that the implementation of complex policy can be accomplished in reasonable time frames.

      Resolved (2015.09.28.22), the Board directs the President and CEO, or his designee(s), to post the relevant documents on GNSO policy and implementation related pages on the GNSO and ICANN website, and to seek and incorporate feedback on enhancements and additional supporting materials as appropriate.

      Resolved (2015.09.28.23), the Board considers ATRT2 Recommendation #4 hereby completed and invites ATRT3 to review these adopted recommendations in light of the ATRT2 findings and recommendations.

      Resolved (2015.09.28.24), the Board thanks the GNSO community and others involved for their hard work on this effort.

      Rationale for Resolutions 2015.09.28.16 - 2015.09.28.24

      Why the Board is addressing the issue?

      Mainly as a result of discussions stemming from implementation related issues of the new generic Top-Level Doman (gTLD) program, there has been an increased focus on which topics call for policy and which call for implementation work, including which processes should be used, at what time and how issues which are the subject of diverging opinions during the implementation process should be acted upon. Following several discussions, including the publication of a staff discussion paper and a community session during the ICANN46 meeting, the Generic Names Supporting Organization (GNSO) Council decided in July 2013 to form a Working Group (WG) which was tasked to develop a set of recommendations on:

      • A set of principles to underpin future GNSO policy and implementation related discussions, taking into account existing GNSO Operating Procedures.
      • A process for developing gTLD policy, possibly in the form of "Policy Guidance," including criteria for when it would be appropriate to use such a process (for developing policy other than "Consensus Policy") instead of a GNSO Policy Development Process;
      • A framework for implementation related discussions associated with GNSO policy recommendations;
      • Criteria to be used to determine when an action should be addressed by a policy process and when it should be considered implementation; and
      • Further guidance on how GNSO Implementation Review Teams, as defined in the PDP Manual, are expected to function and operate.

      The recommendations of the Working Group were adopted unanimously by the GNSO Council on 24 June 2015 and subsequently submitted to the ICANN Board for its consideration.

      Furthermore, this issue was also identified by the Accountability and Transparency Review Team 2 (ATRT2) as a priority: 'the Board should continue supporting cross-community engagement aimed at developing an understanding of the distinction between policy development and policy implementation. Develop complementary mechanisms whereby the Supporting Organizations and Advisory Committees (SO/AC) can consult with the Board on matters, including but not limited to policy, implementation and administrative matters, on which the Board makes decisions' (Recommendation #4).

      What is the proposal being considered?

      The Board's action today is to adopt recommendations from the GNSO concerning policy and implementation. The adopted recommendations include three new GNSO processes, two of which—the GNSO Guidance Process (GGP) and the GNSO Expedited Policy Development Process (EPDP)—require changes to the ICANN Bylaws. The Board's action approves the required changes to the Bylaws to implement the GNSO Guidance Process and the GNSO Expedited Policy Development Process. These new processes are intended to provide the GNSO Council with more flexibility to address policy issues through formal processes to be used if specific criteria are met. Furthermore, the Board is taking action to endorse the proposed GNSO policy & implementation principles and guidelines to guide further staff as well as community work related to GNSO policy and implementation.

      Which stakeholders or others were consulted?

      Following several discussions, including the publication of a staff discussion paper (see https://gnso.icann.org/en/correspondence/policy-implementation-framework-08jan13-en.pdf [PDF, 195 KB] and http://forum.icann.org/lists/comments-policy-implementation-31jan13/) and a community session during the ICANN46 meeting (see http://beijing46.icann.org/node/37133) the Generic Names Supporting Organization (GNSO) Council decided in July 2013 in consultation with other SO/ACs (see http://gnso.icann.org/en/correspondence/robinson-to-so-ac-leadership-23apr13-en.pdf [PDF, 236 KB]) to form a GNSO WG to address a number of specific issues as they relate to GNSO Policy & Implementation. The GNSO Working Group solicited initial input from all ICANN SO/ACs and GNSO SG/Cs at an early stage (see https://community.icann.org/x/iSmfAg). The publication of the Initial Report was accompanied by a public comment forum (see https://www.icann.org/public-comments/policy-implementation-2015-01-19-en) as well as a community session during ICANN52 (see https://singapore52.icann.org/en/schedule/wed-policy-implementation). The WG reviewed and addressed all input received as demonstrated in the public comment review tool (see https://community.icann.org/x/iSmfAg). Following the unanimous adoption by the GNSO Council of the Final Recommendations Report, the ICANN Board directed ICANN Staff to post the proposed changes to the ICANN Bylaws for public comment (see https://www.icann.org/public-comments/bylaws-amendments-2015-07-31-en). Two comments, including an Advice Statement from the ALAC, were received in support of the recommendations (see http://forum.icann.org/lists/comments-bylaws-amendments-31jul15/).

      What concerns or issues were raised by the community?

      The WG reviewed and addressed all input received as demonstrated in the public comment review tool (see https://community.icann.org/x/iSmfAg). The ALAC, in its Advice Statement in response to the public comment forum launched by the ICANN Board, supported the recommendations but also recommended that the ICANN Board carefully monitor GNSO policy development activities to ensure that user and public interests are appropriately considered and that the implementation of complex policy can be accomplished in reasonable time frames.

      What significant materials did the Board review?

      The Board reviewed the GNSO Policy & Implementation Final Recommendations Report (see http://gnso.icann.org/en/drafts/policy-implementation-recommendations-01jun15-en.pdf [PDF, 1.53 MB]) and related materials.

      What factors did the Board find to be significant? Are there positive or negative community impacts?

      The Board considers it of significant importance that these recommendations were developed by the community in consultation with ICANN staff and that these recommendations received the unanimous support of the GNSO Council. Furthermore, the Board recognizes the importance of addressing this issue, as also pointed out by the ATRT2, and is of the view that these recommendations will provide the GNSO Council with more flexibility to address policy issues through formal processes as well as providing the necessary clarity and predictability with regards to GNSO policy & implementation related issues.

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

      No fiscal impacts or ramifications are expected as a result of the implementation of these recommendations.

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

      No security, stability or resilience issues relating to the DNS have been identified in relations to these recommendations.

    7. Appointment of 2016 Nominating Committee Chair and Chair-Elect – EXECUTIVE SESSION

      Whereas, the BGC reviewed the Expressions of Interest from candidates for the 2016 Nominating Committee ("NomCom") Chair and Chair-Elect, considered the results of a 360-degree evaluation of the 2015 NomCom leadership, and conducted interviews of candidates.

      Whereas, the BGC has recommended that Stéphane Van Gelder be appointed as the 2016 NomCom Chair and Hans Petter Holen be appointed as the 2016 NomCom Chair-Elect.

      Resolved (2015.09.28.25), the Board hereby appoints Stéphane Van Gelder as the 2016 Nominating Committee Chair and Hans Petter Holen as the 2016 Nominating Committee Chair-Elect.

      Rationale for Resolution 2015.09.28.25

      ICANN's Bylaws require the Board to appoint the Nominating Committee (NomCom) Chair and NomCom Chair-Elect. See Article VII, sections 2.1 and 2.2 at http://www.icann.org/en/general/bylaws.htm - VII. The Board has delegated the responsibility for recommending the NomCom Chair and Chair-Elect for Board approval to the Board Governance Committee. See BGC Charter at http://www.icann.org/en/committees/board-governance/charter.htm. The BGC posted a call for expressions of interest (EOI) on 4 June 2015 seeking EOIs by 30 June 2015 (see (https://www.icann.org/news/announcement-2-2015-06-04-en). The call for EOIs was later extended through 20 July 2015 (see https://www.icann.org/news/announcement-2015-07-01-en). The BGC received and reviewed several EOIs, oversaw a 360-degree evaluation of the 2015 NomCom leadership and conducted interviews with candidates before making its recommendations. The Board has considered and agrees with the BGC's recommendation for the 2016 NomCom Chair and 2016 NomCom Chair-Elect. The Board also would like to thank all who expressed interest in becoming part of the 2016 NomCom leadership.

      Appointing a NomCom Chair and Chair-Elect identified through a public EOI process positively affects the transparency and accountability of ICANN, as well as supports the public interest. Adopting the BGC's recommendation has no financial impact on ICANN that was not otherwise anticipated, and will not negatively impact the security, stability and resiliency of the domain name system.

Published on 30 September 2015

Revised version published on 15 October 2015 to correct Resolutions numbering


1 For a definition of consensus levels see http://gnso.icann.org/en/council/annex-1-gnso-wg-guidelines-07apr11-en.pdf [PDF, 344 KB] (p.8).

2 see also 5.1.1 and the Public Comment Review Tool (Annex B [of the Final Report]).

3 Many assume that that would be English US-ASCII though arguments for other scripts could be convincing.

4 See https://www.icann.org/news/announcement-3-2014-09-22-en

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."