Thank you Rinalia. ----------------------------------------------------------------------------- Tijani BEN JEMAA Executive Director Mediterranean Federation of Internet Associations (FMAI) Phone: +216 98 330 114 +216 52 385 114 -----------------------------------------------------------------------------
Le 12 août 2016 à 21:50, Rinalia Abdul Rahim <rinalia.abdulrahim@gmail.com> a écrit :
Dear ALAC and Regional Leaders,
The Board met on 9 August 2016. Below is the set of resolutions/decisions. Quite a few important items approved including those related to the IANA Stewardship Transition and the GNSO Policy Recommendations on Proxy and Privacy Services.
See https://www.icann.org/resources/board-material/resolutions-2016-08-09-en <https://www.icann.org/resources/board-material/resolutions-2016-08-09-en> for 9 August 2016 approved ICANN Board resolutions. Text pasted below.
Best regards,
Rinalia
<>Skip to main content <https://www.icann.org/resources/board-material/resolutions-2016-08-09-en#mai...> Log In <https://www.icann.org/users/sign_in>Sign Up <https://www.icann.org/users/sign_up> <https://www.icann.org/> <https://www.icann.org/get-started> <https://www.icann.org/resources/pages/beginners-guides-2012-03-06-en> <https://www.icann.org/en/about/participate/newcomers> <https://www.icann.org/en/about/participate/fellowships> <https://www.icann.org/news> <https://www.icann.org/news/announcements> <https://www.icann.org/news/blog> <https://www.icann.org/news/multimedia> <https://www.icann.org/en/news/press> <https://www.icann.org/resources/pages/global-newsletter> <https://www.icann.org/policy> <https://www.icann.org/policy#what_is_policy> <https://www.icann.org/policy#how_is_policy_developed> <https://www.icann.org/policy/implementation> <https://www.icann.org/policy#updates> <https://www.icann.org/policy#participate> <https://www.icann.org/policy#staff> <https://www.icann.org/public-comments> <https://www.icann.org/public-comments#open-public> <https://www.icann.org/public-comments#closed-public> <https://www.icann.org/public-comments#upcoming-public> <https://www.icann.org/public-comments/archive> <https://www.icann.org/resources> <https://www.icann.org/resources/pages/board-of-directors-2014-03-19-en> <https://www.icann.org/resources/pages/accountability-2012-02-25-en> <https://www.icann.org/en/resources/registrars> <https://www.icann.org/en/resources/registries> <https://www.icann.org/en/resources/compliance> <https://www.icann.org/resources/pages/help-2012-02-03-en> <https://www.icann.org/community> <https://www.icann.org/community#groups> <https://www.icann.org/community/explore> <https://features.icann.org/calendar> <https://www.icann.org/community/demographics>
<https://www.icann.org/stewardship-accountability> <https://www.icann.org/stewardship> <https://community.icann.org/display/acctcrosscomm/WS1+-+Enhancing+ICANN+Acco...> <https://www.icann.org/stewardship-implementation> Resources About ICANN <https://www.icann.org/resources/pages/welcome-2012-02-25-en> Board <https://www.icann.org/resources/pages/board-of-directors-2014-03-19-en> Accountability <https://www.icann.org/resources/accountability> Governance <https://www.icann.org/resources/pages/governance-2012-02-25-en> Groups <https://www.icann.org/resources/pages/groups-2012-02-06-en> Business <https://www.icann.org/resources/pages/business> Civil Society <https://www.icann.org/resources/pages/civil-society-2016-05-24-en> Contractual Compliance <https://www.icann.org/resources/pages/compliance-2012-02-25-en> Registrars <https://www.icann.org/resources/pages/registrars-0d-2012-02-25-en> Registries <https://www.icann.org/resources/pages/registries-46-2012-02-25-en> GDD Metrics <https://www.icann.org/resources/pages/metrics-gdd-2015-01-30-en> Identifier Systems Security, Stability and Resiliency (IS-SSR) <https://www.icann.org/resources/pages/is-ssr-2014-11-24-en> ccTLDs <https://www.icann.org/resources/pages/cctlds-21-2012-02-25-en> Internationalized Domain Names <https://www.icann.org/resources/pages/idn-2012-02-25-en> Universal Acceptance Initiative <https://www.icann.org/resources/pages/universal-acceptance-2012-02-25-en> Policy <https://www.icann.org/resources/pages/policy-01-2012-02-25-en> Public Comment <https://www.icann.org/public-comments> Root Zone KSK Rollover <https://www.icann.org/resources/pages/ksk-rollover-2016-05-06-en> Technical Functions <https://www.icann.org/resources/pages/technical-functions-2015-10-15-en> Contact <https://www.icann.org/resources/pages/contact-2012-02-06-en> Help <https://www.icann.org/resources/pages/help-2012-02-03-en> Approved Board Resolutions | Special Meeting of the ICANN Board
09 Aug 2016
Consent Agenda: <https://www.icann.org/resources/board-material/resolutions-2016-08-09-en#1> Approval of Minutes <https://www.icann.org/resources/board-material/resolutions-2016-08-09-en#1.a> Main Agenda: <https://www.icann.org/resources/board-material/resolutions-2016-08-09-en#2> Root Zone Evolution Review Committee (RZERC) Charter <https://www.icann.org/resources/board-material/resolutions-2016-08-09-en#2.a> Rationale for Resolutions 2016.08.09.02 – 2016.08.09.03 <https://www.icann.org/resources/board-material/resolutions-2016-08-09-en#2.a...> PTI Articles of Incorporation <https://www.icann.org/resources/board-material/resolutions-2016-08-09-en#2.b> Rationale for Resolution 2016.08.09.04 <https://www.icann.org/resources/board-material/resolutions-2016-08-09-en#2.b...> Root Zone Maintainer Agreement <https://www.icann.org/resources/board-material/resolutions-2016-08-09-en#2.c> Rationale for Resolutions 2016.08.09.05 <https://www.icann.org/resources/board-material/resolutions-2016-08-09-en#2.c...> ICANN Restated Articles of Incorporation <https://www.icann.org/resources/board-material/resolutions-2016-08-09-en#2.d> Rationale for Resolutions 2016.08.09.06 – 2016.08.09.07 <https://www.icann.org/resources/board-material/resolutions-2016-08-09-en#2.d...> GNSO Policy Recommendations on Privacy & Proxy Services Accreditation <https://www.icann.org/resources/board-material/resolutions-2016-08-09-en#2.e> Rationale for Resolutions 2016.08.09.08 – 2016.08.09.10 <https://www.icann.org/resources/board-material/resolutions-2016-08-09-en#2.e...> Consideration of BGC Recommendation on Reconsideration Request 16-3 (.GAY) <https://www.icann.org/resources/board-material/resolutions-2016-08-09-en#2.f> Consideration of Dot Registry v. ICANN IRP Final Declaration <https://www.icann.org/resources/board-material/resolutions-2016-08-09-en#2.g> Rationale for Resolutions 2016.08.09.11 – 2016.08.09.13 <https://www.icann.org/resources/board-material/resolutions-2016-08-09-en#2.g...> Consideration of Request for Cancellation of HOTEL Top-Level Domain S.a.r.l's (HTLD's) Application for .HOTEL <https://www.icann.org/resources/board-material/resolutions-2016-08-09-en#2.h> Rationale for Resolutions 2016.08.09.14 – 2016.08.09.15 <https://www.icann.org/resources/board-material/resolutions-2016-08-09-en#2.h...> Executive Session - Confidential: <https://www.icann.org/resources/board-material/resolutions-2016-08-09-en#3> Ombudsman FY16 At-Risk Compensation <https://www.icann.org/resources/board-material/resolutions-2016-08-09-en#3.a> Rationale for Resolution 2016.08.09.16 <https://www.icann.org/resources/board-material/resolutions-2016-08-09-en#3.a...> Officer Compensation <https://www.icann.org/resources/board-material/resolutions-2016-08-09-en#3.b> Rationale for Resolution 2016.08.09.16 – 2016.08.09.20 <https://www.icann.org/resources/board-material/resolutions-2016-08-09-en#3.b...>
<> Consent Agenda: <> Approval of Minutes Resolved (2016.08.09.01), the Board approves the minutes of the 25 June and 27 June 2016 Meetings of the ICANN Board.
<> Main Agenda: <> Root Zone Evolution Review Committee (RZERC) Charter Whereas, ICANN developed the proposed Root Zone Evolution Review Committee (RZERC) charter in cooperation with the Implementation Oversight Task Force (IOTF) and the Cross Community Working Group on Naming Related Functions (CWG-Stewardship).
Whereas, the proposed charter is consistent with the IANAStewardship Transition Coordination Group (ICG) proposal that the Board approved and transmitted to the National Telecommunications and Information Administration (NTIA) on 10 March 2016.
Whereas, ICANN commenced a public comment period from 30 June 2016 to 10 July 2016 <https://www.icann.org/public-comments/draft-rzerc-charter-2016-06-10-en <https://www.icann.org/public-comments/draft-rzerc-charter-2016-06-10-en>> on the proposed charter <https://www.icann.org/en/system/files/files/draft-rzerc-charter-10jun16-en.p... <https://www.icann.org/en/system/files/files/draft-rzerc-charter-10jun16-en.pdf>> [PDF, 43 KB].
Whereas, the public comment forum on the proposed charter closed on 10 July 2016, with ICANN receiving seven comment submissions by both individuals and organizations/groups. Upon review of these comments, ICANN coordinated with the impacted parts of the ICANNcommunity to address the concerns and revise the charter appropriately.
Whereas, the RZERC charter calls for a representative from the ICANN Board to serve in the Committee.
Resolved (2016.08.09.02), the Board approves the RZERC charter as revised in response to public comment, and the President and CEO, or his designee(s), is authorized to take such actions as appropriate to form the RZERC.
Resolved (2016.08.09.03), the Board appoints Suzanne Woolf to serve on the RZERC.
<> Rationale for Resolutions 2016.08.09.02 – 2016.08.09.03 Why the Board is addressing the issue now?
On 10 March 2016, the Board approved and transmitted the IANA Stewardship Transition Coordination Group (ICG) proposal to the National Telecommunications and Information Administration (NTIA) and directed ICANN to proceed with implementation planning. One of the requirements in the naming portion of the ICG proposal is the formation of a standing committee to review proposed architectural changes to the content of the DNS root zone, the systems including both hardware and software components used in executing changes to the DNS root zone, and the mechanisms used for distribution of the DNS root zone. The Committee shall, as determined necessary by its membership, make recommendations related to those changes for consideration by the ICANN Board. The Board's approval at the recommendation of the Committee is the CWG-Stewardship's proposed replacement for NTIA's current role, which would no longer be in place if the IANA Functions Contract lapses. As part of implementation planning, ICANNnamed this standing committee Root Zone Evolution Review Committee (RZERC) and worked with the community to draft a charter for the Committee.
What is the proposal being considered?
The proposed charter describes the purpose, scope of responsibilities, and composition of the Committee. The charter also sets out how the Committee will conduct itself, including frequency and method of meetings, how decisions will be made, records of proceedings, as well as conflict of interest. Lastly, the charter sets out requirements for review and amendments to the charter.
Which stakeholders or others were consulted?
ICANN consulted with the Implementation Oversight Task Force (IOTF) as well as the CWG-Stewardship in the development of the proposed charter. ICANN also conducted a public comment period on the proposed charter from 10 June 2016 through 10 July 2016, following which time the comments were summarized and analyzed.
What concerns or issues were raised by the community?
Seven (7) members of the community participated in the public comment period. Members of the community raised one key concern in their comments.
The concern was that the scope of responsibilities of the RZERC as drafted seems to overlap with the responsibilities of the RSSAC. The scope of the RZERC as drafted is to consider architectural and operational issues that impose potential risk to the root zone and the root system. Commenters suggested that this scope could be interpreted to mean that the RZERC could consider issues relating to the operation of the root servers, which is a responsibility of the RSSAC. To address this concern, ICANNworked with the RSSAC to modify the scope of the RZERC to clarify that the RZERC is expected to review proposed architectural changes to the content of the DNS root zone, the systems including both hardware and software components used in executing changes to the DNS root zone, and the mechanisms used for distribution of the DNS root zone. The Committee shall, as determined necessary by its membership, make recommendations related to those changes for consideration by the ICANN Board.
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:
The proposed RZERC charter <https://www.icann.org/en/system/files/files/draft-rzerc-charter-10jun16-en.p... <https://www.icann.org/en/system/files/files/draft-rzerc-charter-10jun16-en.pdf>> [PDF, 43 KB] Public comments <https://forum.icann.org/lists/comments-draft-rzerc-charter-10jun16/ <https://forum.icann.org/lists/comments-draft-rzerc-charter-10jun16/>> Summary and analysis of public comments IANA Stewardship Transition Coordination Group (ICG) proposal <https://www.icann.org/en/system/files/files/iana-stewardship-transition-prop... <https://www.icann.org/en/system/files/files/iana-stewardship-transition-proposal-10mar16-en.pdf>> [PDF, 2.32 MB] The RZERC charter as modified in response to public comment. Are there positive or negative community impacts?
The Board's approval of the charter is an important step in the implementation planning process to fulfill one of the requirements from the ICGproposal, which was endorsed by the global stakeholder community and approved by the Board on 10 March 2016.
Are there fiscal impacts or ramifications on ICANN(strategic plan, operating plan, budget); the community; and/or the public?
There is no fiscal impact expected.
Are there any security, stability or resiliency issues relating to the DNS?
The approval of the proposed charter would be an important step toward ensuring security, stability and resiliency of the DNS post transition. The RZERC's scope of responsibility will be to provide the ICANNBoard with recommendations regarding proposed architectural changes to the content of the DNS root zone, the systems including both hardware and software components used in executing changes to the DNS root zone, and the mechanisms used for distribution of the DNS root zone.
<> PTI Articles of Incorporation Whereas, on 14 March 2014, the National Telecommunications and Information Administration (NTIA) of the United States Department of Commerce announced its intention to transition the stewardship of the IANA Functions to the global multistakeholder community.
Whereas, on 10 March 2016, Internet Corporation for Assigned Names and Numbers (ICANN) accepted and transmitted to the NTIA the following transition documents: (i) the IANA Stewardship Transition Coordination Group's IANA Stewardship Transition Proposal, (the "ICG Proposal") and (ii) the Cross Community Working Group on Enhancing ICANN Accountability's Work Stream 1 Report (collectively, the "Transition Proposals").
Whereas, the ICG Proposal included a requirement that ICANN develop an affiliate to perform the naming-related IANA functions under a contract with ICANN, PTI. The ICGProposal required PTI to be a California Nonprofit Public Benefit Organization, and ICANN is to be the sole member of PTI.
Whereas, ICANN lawyers worked diligently with the independent counsel to the Cross Community Working Group to Develop an IANAStewardship Transition Proposal on Naming Related Functions ("CWG-Stewardship") to develop Articles of Incorporation for the new PTI. Those draft Articles were posted for public comment for a period of 30 days.
Whereas, upon the close of the comment period, a detailed analysis of the comments was performed and modifications were made to the Articles in response to the public comments. ICANN coordinated with the independent law firm on the revisions.
Whereas, ICANN's General Counsel has asserted that the proposed PTI Articles of Incorporation remain consistent with the Transition Proposals and recommends that ICANNproceed to forming the affiliate to allow for implementation planning to continue.
Resolved (2016.08.09.04), the ICANN Board authorizes ICANN's CEO, or his designee, to proceed with the formation of PTI, including the filing of the proposed PTI Articles of Incorporation as revised after public comment.
<> Rationale for Resolution 2016.08.09.04 The authorization for ICANN to proceed with the formation of PTI, through the filing of the PTI Articles of Incorporation, is a crucial step in the planning for the implementation of the Transition Proposals. This is a key step for ICANN's report to NTIA on the status of implementation planning. This timely authorization to move forward with the formation of PTI is necessary to support the global multistakeholder community's work towards a successful completion of the stewardship of the IANAfunctions.
These PTI Articles are product of collective work of the internal and external legal teams along with the intensive work of the CWG-Stewardship. The PTI Articles were posted for a 30-day public comment period, and three comments were received. Each of the comments was considered and analyzed, and explanation was provided on whether the PTI Articles required modification to reflect the issues raised within the comment.
With the small number of comments, the Articles did not require significant change in response to those comments. The changes that were made included a modification to the purpose of PTI to more accurately reflect PTI's limited, narrow role to perform the IANAfunctions. Another change was made to reflect the proper threshold needed to amend the PTI Articles.
In taking this action, the Board relied upon:
ICG's IANA Stewardship Transition Proposal <https://www.icann.org/en/system/files/files/iana-stewardship-transition-prop...> [PDF, 2.32 MB] Report of Public Comments on PTI Articles of Incorporation Draft PTI Articles of Incorporation The Board also relied upon the General Counsel and Secretary's affirmation that PTI Articles reflect the Transition Proposals, as well as the inputs of independent counsel to craft the PTI Articles to support the ICG Proposal.
Authorizing the formation of PTI is in line with ICANN's commitment to accountability and transparency. This action confirms ICANN's commitment to implement the Transition Proposals and all of the elements in those Proposals.
Forming PTI is not anticipated to have any impact on the security, stability or resiliency of the DNS, though the PTI will be essential to ICANN's security, stability and resiliency work. There will be resource implications, including significant resources to support a new affiliate.
This is an Organizational Administrative Function for which public comments were received.
<> Root Zone Maintainer Agreement Whereas, the National Telecommunications and Information Agency (NTIA) officially requested that Verisign and ICANN work together to develop a proposal on how best to transition NTIA's administrative role associated with root zone management in a manner that maintains the security, stability, and resiliency of the Internet's domain name system in a 4 March 2015 letter to ICANN.
Whereas, in August 2015, ICANN and Verisign submitted a proposal to NTIA in response to its request <https://www.ntia.doc.gov/files/ntia/publications/root_zone_administrator_pro... <https://www.ntia.doc.gov/files/ntia/publications/root_zone_administrator_proposal-relatedtoiana_functionsste-final.pdf>> [PDF, 247 KB]. The proposal outlines two parts, a parallel testing period of the of Root Zone Management Systems (RZMS) and a Root Zone Maintainer Agreement (RZMA) with Verisign for Verisign to continue performing the root zone maintainer function it performs today under the Cooperative Agreement <https://www.ntia.doc.gov/page/verisign-cooperative-agreement> with the Department of Commerce.
Whereas, NTIA specified in a 9 June 2016 letter to ICANN that a finalized RZMA and successful completion of the parallel testing period are pre-conditions to the IANA Stewardship transition.
Whereas, the completion of the RZMA is a requirement from the package of proposals that the Board approved on 10 March 2016 to transition NTIA's stewardship of the IANA function to the global multistakeholder community and, because the RZMA exceeds US$500,000 in total, requires that the Board approves to delegate signature authority to the CEO.
Whereas, the parallel testing period of the RZMS successfully concluded on 6 July 2016 <https://www.icann.org/news/announcement-2016-07-14-en <https://www.icann.org/news/announcement-2016-07-14-en>>.
Whereas, ICANN and Verisign finalized negotiations on the terms of the proposed RZMA for Verisign to perform the root zone maintainer function, and published the proposed RZMA for a 30-day notice period as required by the IANAStewardship Transition Coordination Group (ICG) proposal <https://www.icann.org/news/blog/root-zone-management-transition-update-prese... <https://www.icann.org/news/blog/root-zone-management-transition-update-preservation-of-security-stability-and-resiliency>>.
Whereas, the proposed RZMA contains provisions that incorporate relevant requirements from the Cross Community Working Group on Naming Related Functions (CWG-Stewardship).
Whereas, the Board Finance Committee reviewed the financial aspects and implications of the RZMA and found (i) that the proposed costs of the contract were reasonable, (ii) that the procurement process had been respected, (iii) that the costs were affordable, and recommended approval by the Board as a result.
Resolved (2016.08.09.05), the proposed RZMA 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 Resolutions 2016.08.09.05 Why the Board is addressing the issue now?
In a 4 March 2015 letter, the National Telecommunications and Information Agency (NTIA) "officially requested that Verisign and ICANN work together to develop a proposal on how best to transition NTIA's administrative role associated with root zone management in a manner that maintains the security, stability, and resiliency of the Internet's domain name system." In August 2015, ICANNand Verisign submitted a proposal to NTIA in response to its request <https://www.ntia.doc.gov/files/ntia/publications/root_zone_administrator_pro... <https://www.ntia.doc.gov/files/ntia/publications/root_zone_administrator_proposal-relatedtoiana_functionsste-final.pdf>> [PDF, 247 KB]. The proposal outlines two parts, a parallel testing period of the of Root Zone Management System (RZMS) and a Root ZoneMaintainer Agreement with Verisign for Verisign to continue performing the root zone maintainer function it performs today under the Cooperative Agreement <https://www.ntia.doc.gov/page/verisign-cooperative-agreement> with the Department of Commerce.
Completion of the RZMA is also specified as one of the requirements from the package of proposals that the Board approved on 10 March 2016 to transition NTIA's stewardship of the IANA function to the global multistakeholder community and, because it exceeds US$500,000 in total, requires that the Board approves to delegate signature authority to the CEO.
Since last August, ICANN and Verisign have had ongoing discussions and negotiations regarding the terms of the RZMA. Negotiations concluded in June and the proposed RZMA was published for a 30-day public notice period on 30 June 2016. The 30-day public notice period ended on 30 July 2016 and the Board has considered the proposed RZMA for approval.
What is the proposal being considered?
The proposed RZMA allows Verisign to continue providing services for root zone maintenance, root zone signing with the ZSK, and distribution of the root zone file and related files to the root zone operators at a nominal fee. The RZMA provides for an 8-year term with robust service level agreements that can be modified via a change control process should the customers of IANA require changes to these service level agreements. The change control process also allows for changes to the Root Zone Management System as root zone management evolves to meet the needs of the community. While the 8-year term of the RZMA is intended to promote the security, stability and resiliency of root zone maintenance operations by having Verisign continue in its role, the agreement also provides a capability for the community, through a consensus-based community-driven process, to cause ICANNto transition the function to another service provider after three years. The full RZMA was posted for a 30-day public notice period on 30 June 2016 as required by the ICG proposal and can be viewed at <https://www.icann.org/iana_imp_docs/63-root-zone-maintainer-agreement-v-1-0 <https://www.icann.org/iana_imp_docs/63-root-zone-maintainer-agreement-v-1-0>>.
Which stakeholders or others were consulted?
ICANN held discussions and negotiations with Verisign, Inc. to finalize the proposed RZMA, which was then posted for a 30-day public notice period from 30 June through 30 July 2016.
What concerns or issues were raised by the community?
No significant issues or concerns were brought to ICANN's attention during the 30-day public notice period.
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:
Verisign Cooperative Agreement with the United States Government <https://www.ntia.doc.gov/page/verisign-cooperative-agreement <https://www.ntia.doc.gov/page/verisign-cooperative-agreement>> 4 March 2015 letter from NTIA Verisign/ICANN Proposal in Response to NTIARequest – Root ZoneAdministrator Proposal Related to the IANAFunctions Stewardship Transition <https://www.ntia.doc.gov/files/ntia/publications/root_zone_administrator_pro... <https://www.ntia.doc.gov/files/ntia/publications/root_zone_administrator_proposal-relatedtoiana_functionsste-final.pdf>> [PDF, 247 KB] Root Zone Maintainer Agreement <https://www.icann.org/iana_imp_docs/63-root-zone-maintainer-agreement-v-1-0 <https://www.icann.org/iana_imp_docs/63-root-zone-maintainer-agreement-v-1-0>> IANA Stewardship Transition Coordination Group (ICG) proposal <https://www.icann.org/en/system/files/files/iana-stewardship-transition-prop... <https://www.icann.org/en/system/files/files/iana-stewardship-transition-proposal-10mar16-en.pdf>> [PDF, 2.32 MB] What factors has the Board found to be significant?
The Board carefully considered the RZMA to ensure it contains provisions that would allow ICANN to meet the requirements of the community for the transition, such as:
The ability to modify service level agreements due to recommendations from the Customer Standing Committee The ability to make modifications to the Root Zone Management System due to recommendations from the Root ZoneEvolution Review Committee The ability for the community, through a consensus-based community-driven process, to cause ICANN to transition the maintainer function to another service provider The Board also carefully considered the terms of the RZMA to ensure that the maintainer function can continued to be operated in a secure, stable, and reliable manner post transition. Are there positive or negative community impacts?
A key goal of the proposed RZMA and continued engagement with Verisign, Inc. for the performance of the maintainer function is to provide secure and stable operations of the root zone through the IANAStewardship transition and beyond. The Board's approval of the proposed RZMA would ensure that expectations of IANA customers will continue to be met.
Are there fiscal impacts or ramifications on ICANN(strategic plan, operating plan, budget); the community; and/or the public?
Verisign, Inc. has historically solely performed the maintainer function at no cost and contracting directly with Verisign, Inc. for the continued performance of this work is desirable to ensure continuity, security and stability during the transition period. The terms of the RZMA allow for the community, through a consensus-based community-driven process, to cause ICANNto transition the maintainer function to another service provider. This contract creates a nominal annual fee of USD 300,000 per year due to Verisign, Inc. for the performance of the maintainer function. The ICANN Board Finance Committee has reviewed the financial aspects and implications of the proposed RZMA and recommended approval of the RZMA to the ICANN Board, on the basis of this review.
Are there any security, stability or resiliency issues relating to the DNS?
The Board's approval of the proposed RZMA would ensure continuity, security and stability of the operation of the root zone during the transition period and beyond.
<> ICANN Restated Articles of Incorporation Whereas, on 14 March 2014, the National Telecommunications and Information Administration (NTIA) of the United States Department of Commerce announced its intention to transition the stewardship of the IANA Functions to the global multistakeholder community.
Whereas, on 10 March 2016, Internet Corporation for Assigned Names and Numbers (ICANN) accepted and transmitted to the US National Telecommunications and Information Agency the following transition documents: (i) the IANA Stewardship Transition Coordination Group's IANAStewardship Transition Proposal, (the "ICG Proposal") and (ii) the Cross Community Working Group on Enhancing ICANNAccountability's Work Stream 1 Report (collectively, the "Transition Proposals").
Whereas, the ICANN Articles of Incorporation need to be restated in order to align with the new ICANN Bylaws and for consistency with the Transition Proposals.
Whereas, ICANN lawyers worked diligently with the independent counsel to the CCWG-Accountability to develop Restated Articles of Incorporation for ICANN. Those Restated Articles were posted for public comment for over 40 days.
Whereas, upon the close of the comments, a detailed analysis of the comments was performed and modifications were made to the Articles in response to the public comments. ICANNcoordinated with the independent law firms on the revisions.
Whereas, ICANN's General Counsel has asserted that the proposed Restated ICANNArticles of Incorporation remain consistent with the Transition Proposals and recommends that the Board approve the amendment to ICANN's Articles and authorize ICANN to proceed to filing at the appropriate time.
Resolved (2016.08.09.06), the ICANN Board approves the proposed amendments to ICANN's Articles of Incorporation, which shall be deemed effective upon the expiration the IANA Functions Contract between ICANN and NTIA.
Resolved (2016.08.09.07), the ICANN Board authorizes ICANN's CEO, or his designee, to proceed with the filing of the Restated Articles of Incorporation once they are effective.
<> Rationale for Resolutions 2016.08.09.06 – 2016.08.09.07 The adoption of the Restated Articles of Incorporation is another key step in the planning for the implementation of the Transition Proposals. The Board is being taking this action now to support ICANN's transition planning status report to NTIAdue on 12 August 2016. The adoption of amendments to ICANN Articles of Incorporation completes the changes to ICANN's key governance documents that is necessary to align with the Transition Proposals and support the global multistakeholder community's work towards a successful completion of the stewardship of the IANAfunctions.
These Restated Articles were developed jointly between the legal teams in coordination with the ICANN community. The external counsel to the CCWG-Accountability, as well as ICANN's lawyers, worked closely with the CCWG-Accountability to confirm its understanding and support of the document. The proposed Restated Articles were posted for public for over 40 days, including a requested extension. Six comments were received. Each of the comments was considered and analyzed, and explanation was provided on whether the Articles required modification to reflect the issues raised within the comment. The legal teams continued their close coordination in developing the necessary updates to the Articles.
The changes to the draft Articles based on comments were limited.
In taking this action, the Board relied upon:
ICG's IANA Stewardship Transition Proposal <https://www.icann.org/en/system/files/files/iana-stewardship-transition-prop...> [PDF, 2.32 MB] Cross Community Working Group on Enhancing ICANN Accountability (CCWG-Accountability) Work Stream 1 Report ("Report") to the ICANNBoard <https://www.icann.org/en/system/files/files/ccwg-accountability-supp-proposa...> [PDF, 6.03 MB] Report of Public Comments Proposed Restated Articles of Incorporation (clean and redline to existing Articles) The Board also relied upon the General Counsel and Secretary's affirmation that the Restated Articles reflect the Transition Proposals, as well as the work of the independent counsel to craft the Articles in support of the Transition Proposals.
The adoption of these Articles is in line with ICANN's commitment to accountability and transparency, as this completes the key governance document that ICANN needs to put in place to provide the community with the new and enhanced accountability tools. This action confirms ICANN's commitment to adopt the accountability changes.
The adoption of these Restated Articles is not anticipated to have any impact on the security, stability or resiliency of the DNS. The resource implications for these Restated Articles are the same as the potential resource implications identified for the implementation of the new ICANN Bylaws.
This is an Organizational Administrative Function for which public comments were received.
<> GNSO Policy Recommendations on Privacy & Proxy Services Accreditation Whereas, on 31 October 2013, the GNSO Council approved the charter for a Working Group to conduct a Policy Development Process that had been requested by the ICANN Board concerning the accreditation by ICANN of privacy and proxy domain name registration service providers, as further described at http://gnso.icann.org/en/drafts/raa-pp-charter-22oct13-en.pdf <http://gnso.icann.org/en/drafts/raa-pp-charter-22oct13-en.pdf> [PDF, 463 KB].
Whereas, the PDP followed the prescribed PDP steps as stated in the ICANN Bylaws, resulting in a Final Report being delivered to the GNSO Council on 8 December 2015.
Whereas, the Privacy & Proxy Services Accreditation Issues PDP Working Group (WG) reached Full Consensus on all its final recommendations (see http://gnso.icann.org/en/issues/raa/ppsai-final-07dec15-en.pdf <http://gnso.icann.org/en/issues/raa/ppsai-final-07dec15-en.pdf> [PDF, 1.24 MB]).
Whereas, the GNSO Council reviewed and discussed the final recommendations of the Privacy & Proxy Services Accreditation Issues PDP WG, and adopted the recommendations on 21 January 2016 by a unanimous vote (see http://gnso.icann.org/en/council/resolutions - 201601 <http://gnso.icann.org/en/council/resolutions#201601>.)
Whereas, the GNSO Council vote exceeded the required voting threshold (i.e. supermajority) to impose new obligations on ICANNcontracted parties.
Whereas, in accordance with the ICANN Bylaws, a public comment period was opened on the approved recommendations to provide the community with a reasonable opportunity to comment on their adoption prior to action by the ICANN Board, and the comments received have been summarized and reported (see https://www.icann.org/en/system/files/files/report-comments-ppsai-recommenda... <https://www.icann.org/en/system/files/files/report-comments-ppsai-recommenda...> [PDF, 299 KB]).
Whereas, the ICANN Bylaws provide that the Board is to request the GAC's opinion regarding "any policies that are being considered by the Board for adoption that substantially affect the operation of the Internet or third parties, including the imposition of any fees or charges" and "take duly into account any advice timely presented" as a result.
Whereas, the Board notified the GAC of the publication of the GNSO's final recommendations for public comment on 19 February 2016 (see https://gacweb.icann.org/download/attachments/27492514/2016-02-19-Steve-Croc... <https://gacweb.icann.org/download/attachments/27492514/2016-02-19-Steve-Crocker-to-Thomas-Schneider-GNSO-PDP.pdf?version=1&modificationDate=1456046942000&api=v2>[PDF, 819 KB]).
Whereas, in its Marrakech Communiqué issued on 9 March 2016 the GAC advised the ICANN Board that it needed more time to consider potential public policy concerns relating to the adoption of the final PDPrecommendations (see https://gacweb.icann.org/download/attachments/28278854/GACMorocco 55 Communique FINAL.pdf?version=1&modificationDate=1458046221000&api=v2 <https://gacweb.icann.org/download/attachments/28278854/GAC%20Morocco%2055%20Communique%20FINAL.pdf?version=1&modificationDate=1458046221000&api=v2>[PDF, 567 KB]).
Whereas, on 15 May 2016 the Board acknowledged receipt of the GNSO's PDPrecommendations and resolved to consider them at its first meeting following ICANN56 to enable the GAC to provide timely advice, if any (see https://www.icann.org/resources/board-material/resolutions-2016-05-15-en - 2.a <https://www.icann.org/resources/board-material/resolutions-2016-05-15-en#2.a>).
Whereas, in its Helsinki Communiqué issued on 30 June 2016 the GAC advised the ICANN Board to direct that the GAC's concerns be effectively addressed to the greatest extent feasible by the Implementation Review Team that is to be convened to implement the adopted recommendations (see https://gacweb.icann.org/display/gacweb/Governmental+Advisory+Committee?prev... <https://gacweb.icann.org/display/gacweb/Governmental+Advisory+Committee?preview=/27132037/43712639/20160630_GAC%20ICANN%2056%20Communique_FINAL%20.pdf>[PDF, 328 KB]).
Resolved (2016.08.09.08), the Board hereby adopts all the final recommendations of the Privacy & Proxy Services Accreditation Issues PDP Working Group, as passed by a unanimous vote of the GNSO Council on 21 January 2016 ("Privacy/Proxy Policy Recommendations").
Resolved (2016.08.09.09), the Board directs the President and CEO, or his authorized designee, to develop and execute an implementation plan, including costs and timelines, for the Privacy/Proxy Policy Recommendations consistent with ICANN Bylaws Annex A and the Implementation Review Team Guidelines & Principles endorsed by the Board on 28 September 2015 (see https://www.icann.org/resources/board-material/resolutions-2015-09-28-en - 2.f <https://www.icann.org/resources/board-material/resolutions-2015-09-28-en#2.f>), and to continue communication with the community on such work. In the event that policy issues arise in the course of implementation discussions, they should be referred back to the GNSO in accordance with the framework for implementation associated with GNSO policy recommendations, including the Implementation Review Team Guidelines & Principles.
Resolved (2016.08.09.10), the Board acknowledges the GAC's advice from the Helsinki Communiqué regarding the Privacy/Proxy Policy Recommendations. The Board will consider the GAC's advice and provide input to the Implementation Review Team for consideration in implementation planning.
<> Rationale for Resolutions 2016.08.09.08 – 2016.08.09.10 Why is the Board addressing the issue now?
In initiating negotiations with the Registrar Stakeholder Group for new form of Registrar Accreditation Agreement (RAA) in October 2011, the ICANNBoard also requested an Issue Report from the GNSO that, upon the conclusion of the RAAnegotiations, would start a GNSO PDP to address remaining issues not dealt with in the RAA negotiations. In June 2013, the ICANN Board approved a new 2013 RAA, and the topic of accrediting privacy and proxy services was identified as the sole issue to be resolved through a GNSO PDP. This topic had also been noted by the Whois Review Team in its Final Report, published in May 2012, in which the Review Team had highlighted the current lack of clear and consistent rules regarding these services, resulting in unpredictable outcomes for stakeholders. The Review Team thought that appropriate regulation and oversight over such services would address stakeholder needs and concerns, and recommended that ICANNconsider an accreditation system. Until the development of an accreditation program, only certain aspects of such services are covered by an interim specification to the 2013 RAA, which is due to expire on 1 January 2017 or the implementation by ICANN of an accreditation program, whichever first occurs.
The GNSO Council approved all the final recommendations from the PDP Working Group's Final Report dated 8 December 2015 at its meeting on 21 January 2016, as well as a Recommendations Report to the Board in February 2016. In accordance with the ICANNBylaws, a public comment period was opened to facilitate public input on the adoption of the recommendations following which the PDPrecommendations were forwarded to the Board for its review. On 15 May 2016, the Board resolved to consider action on the recommendations at the first Board meeting following ICANN56 in Helsinki, Finland, to enable the GAC to provide timely advice on public policy concerns raised by the PDP recommendations, if any. The GAC's advice in its Helsinki Communiqué was for the Board to direct that the GAC's concerns be effectively addressed to the greatest extent possible during the implementation phase of the PDP recommendations.
What is the proposal being considered?
The GNSO's policy recommendations include minimum mandatory requirements for the operation of privacy and proxy services; the maintenance of designated contact points for abuse reporting and the publication of a list of accredited providers; requirements related to the handling of requests for disclosure and/or publication of a customer's contact details by certain third party requesters; conditions regarding the disclosure and publication of such details as well as the refusal to disclose or publish; and principles governing the de-accreditation of service providers. The full list and scope of the final recommendations can be found in Annex A of the GNSO Council's Recommendations Report to the Board (see http://gnso.icann.org/en/drafts/council-board-ppsai-recommendations-09feb16-... <http://gnso.icann.org/en/drafts/council-board-ppsai-recommendations-09feb16-...> [PDF, 491 KB].
Which stakeholders or others were consulted?
As required by the GNSO's PDPManual, the Working Group reached out to all GNSOStakeholder Groups and Constituencies as well as other ICANN Supporting Organizations and Advisory Committees for input during the early phase of the PDP. The Working Group also held open community sessions at all the ICANN Public Meetings that occurred during the life cycle of this PDP. It also sought input on potential implementation issues from ICANN's Registrar Services and Compliance teams. Public comment periods were opened for the Preliminary Issue Report that preceded the PDP, the Working Group's Initial Report, and the GNSO Council's adoption of the Working Group's Final Report. The final recommendations as detailed in the Final Report were completed based on the Working Group's review and analysis of all the public comments and input received in response to its Initial Report.
Following the GAC's advice in its Marrakech Communiqué of 9 March 2016 and the Board's resolution of 15 May 2016, discussions also took place amongst the Board and community on the topic at ICANN56 in Helsinki, Finland.
What concerns or issues were raised by the community?
A significant number of public comments were received by the Working Group concerning the possibility that a distinction might be made between domain name registrants with domains serving non-commercial purposes and registrants who conduct online financial transactions. This had been an open question in the Working Group's Initial Report, as at the time a number of Working Group members had supported that distinction. As a result of further Working Group deliberations following review of the public comments received, the Working Group reached consensus on a recommendation that no such distinction be made for purposes of accrediting services.
Concerns had also been expressed over the need to ensure that there are adequate safeguards in place for maintaining the privacy of customer data, and that a reasonable balance is struck as between a legitimate need for access to information (e.g. by law enforcement and intellectual property rights-holders) and that of protecting privacy. Many public comments received in response to the Working Group's Initial Report also highlighted the potential dangers of disclosing private information without cause, including the threat to the physical safety of certain groups of domain name registrants and privacy/proxy customers. The Working Group's final recommendations include a number of suggested principles and policies that aim to provide more concrete guidance than exists at present for privacy and proxy services, third party requesters of customer information, and domain name registrants in relation to topics such as the handling of customer notifications, information requests and domain name transfers.
The Working Group also received several comments concerning the lack of a detailed framework for the submission and confidential handling of disclosure requests from law enforcement authorities, including from the GAC's Public Safety Working Group. In its Initial Report, the Working Group sought community input on the question as to whether and how such a framework might be developed as well as on more specific questions such as whether it should be mandatory for accredited providers to comply with express requests from law enforcement authorities in the provider's jurisdiction not to notify a customer. Based on input received, the Working Group agreed that accredited privacy and proxy service providers should comply with express law enforcement requests not to notify a customer where this is required by applicable law. Providers would be free to voluntarily adopt more stringent standards or otherwise cooperate with law enforcement authorities. The Working Group's Final Report also contains a suggestion for certain minimum requirements that could be included if such a framework is to be developed during the implementation phase of the adopted PDP recommendations.
What significant materials did the Board review?
The Board reviewed the PDPWorking Group's Final Report, the GNSO Council's Recommendations Report on the topic to the Board, the summary of public comments received in response to the public comment period that was opened following the GNSOCouncil's adoption of the recommendations contained in the Final Report, and GACadvice received on the topic, as provided in the Marrakech and Helsinki Communiqués.
What factors did the Board find to be significant?
The recommendations were developed following the GNSOPolicy Development Process as set out in Annex A of the ICANNBylaws and have received the unanimous support of the GNSOCouncil. As outlined in the ICANN Bylaws, the Council's supermajority support obligates the Board to adopt the recommendations unless, by a vote of more than two-thirds, the Board determines that the recommended policy is not in the best interests of the ICANNcommunity or ICANN.
The Bylaws also allow for input from the GAC in relation to public policy concerns that might be raised if a proposed policy is adopted by the Board. The GAC had raised this possibility with respect to this PDP and the Board will continue to consider the advice that the GAC provided.
Are there positive or negative community impacts?
Developing a full accreditation program for privacy and proxy service providers will require significant resources and take a substantial period of time. It is likely that the interim specification contained in the 2013 RAA will need to be extended beyond its current expiration date of 1 January 2017, to allow for development of such a program.
Implementing the GNSO's recommendations will result in a more uniform set of standards for many aspects of privacy and proxy services, including more consistent procedures for the handling, processing and determination of third party requests by accredited providers, into which reasonable safeguards to protect consumer privacy can be incorporated and public policy concerns highlighted by the GACaddressed as far as possible. At present, there is no accreditation scheme in place for privacy and proxy services and no agreed community-developed set of best practices for the provision of such services. This PDPrepresents an attempt to develop a sound basis for the development and implementation of an accreditation framework by ICANN and is part of ICANN's on-going efforts to improve the Whois system, including implementing recommendations made previously by the Whois Review Team.
Nevertheless, as highlighted above, the implementation of all the recommendations from the PDP will be time and resource-intensive due to the scale of the project and the fact that this will be the first time ICANN has implemented such a program for this industry sector. While the RAA may serve as a useful reference point for this program, the Working Group's Final Report acknowledged that this may not be the most appropriate model for a number of reasons. Ensuring that the implementation planning addresses as fully as possible the public policy concerns that have been identified by the GAC, including possibly developing a disclosure framework for law enforcement authorities, is likely to form a substantial part of the implementation work.
The Working Group's Final Report also notes areas where additional work may be required, which could increase the community's workload in the near term. For example, the issue of privacy and proxy services in the context of domain name transfers will need to be addressed in the next review of the Inter-Registrar Transfer Policy.
Are there fiscal impacts or ramifications on ICANN(strategic plan, operating plan, budget); the community; and/or the public?
There may be fiscal impacts on ICANN associated with the creation of a new accreditation program specifically covering providers of privacy and proxy services. The implementation plan should take into account costs and timelines for implementation. As the current interim specification in the RAAapplicable to such services is due to expire on 1 January 2017, consideration will also need to be given to extending its duration upon adoption of the PDP recommendations.
Are there any security, stability or resiliency issues relating to the DNS?
There are no security, stability or resiliency issues relating to the DNS that can be directly attributable to the implementation of the PDPrecommendations. While the accreditation of privacy and proxy service providers is part of the overall effort at ICANN to improve the Whois system, it does not affect or change either the Whois protocol (including the rollout of the new RDAP) or the current features of the Whois system. The Working Group made its final recommendations with the understanding that implementation of its recommendations would be done in the context of any other policy or technical changes to the Whois system, which are outside the scope of this PDP.
<> Consideration of BGC Recommendation on Reconsideration Request 16-3 (.GAY) Item removed from agenda.
<> Consideration of Dot Registry v. ICANN IRP Final Declaration Whereas, on 29 July 2016, an Independent Review Process (IRP) Panel (Panel) issued its Final Declaration in the IRP filed by Dot Registry, LLC (Dot Registry) against ICANN (Final Declaration).
Whereas, the Panel majority declared that "the actions and inactions of the Board were inconsistent with ICANN's Articles of Incorporation and Bylaws" in that "the Board (acting through the BGC) failed to exercise due diligence and care in having a reasonable amount of facts in front of them and failed to fulfill its transparency obligations," and that the evidence before the Panel did not support a determination that the Board (acting through the BGC) exercised independent judgment in reaching the reconsideration decisions. (See Final Declaration, ¶¶ 151-152.)
Whereas, the Panel majority further declared that "Dot Registry is the prevailing party" and that ICANN shall pay to Dot Registry US$235,294.37 "upon demonstration that these incurred costs have been paid in full." (Id. ¶ 154.)
Whereas, "[t]he Panel majority decline[d] to substitute its judgment for the judgment of the CPE as to whether Dot Registry is entitled to Community priority." (Id. at ¶ 153.)
Whereas, the Panel majority did not make any recommendations to the Board as to what, if any, subsequent action the Board should take in furtherance of the Final Declaration.
Whereas, Dot Registry has stated in a letter to the Board, among other things, that its "90 page expert report" is "sufficient and compelling to assist the Board with determining that Dot Registry's applications should have passed CPE" and requesting that ICANN "proceed to contracting with Dot Registry for .INC, .LLC, and .LLP. (See https://www.icann.org/en/system/files/correspondence/jolles-to-icann-board-0... <https://www.icann.org/en/system/files/correspondence/jolles-to-icann-board-06aug16-en.pdf>[PDF, 1.5 MB]).
Whereas, the Panel considered and challenged the current standard of review employed by the BGC in reviewing Reconsideration Requests.
Whereas, in accordance with Article IV, section 3.21 of ICANN's Bylaws, the Board has considered the Final Declaration.
Resolved (2016.08.09.11), the Board accepts the findings of the Final Declaration that: (i) Dot Registry is the prevailing party in the Dot Registry, LLC v. ICANNIRP; and (ii) ICANN shall pay to Dot Registry US$235,294.37 upon demonstration that these incurred costs have been paid in full.
Resolved (2016.08.09.12), the Board has noted the other findings in the Declaration and the findings regarding the Panel majority's statements with respect to the standard of review for Reconsideration Requests referenced above, and will consider next steps in relation to Dot Registry's Reconsideration Requests or the relevant new gTLDs before the Board takes any further action.
Resolved (2016.08.09.13), in light of the recent letter received from Dot Registry and the factual inaccuracies that have been reported in online blogged reports, the Board directs the Secretary, or his designee(s), to post the Board briefing materials on this matter simultaneously with the resolutions.
<> Rationale for Resolutions 2016.08.09.11 – 2016.08.09.13 Dot Registry, LLC (Dot Registry) initiated Independent Review Process (IRP) proceedings challenging the Board Governance Committee's (BGC's) denial of Dot Registry's Reconsideration Requests regarding the Community Priority Evaluation (CPE) reports finding that Dot Registry's applications for .INC, .LLC, and .LLP, respectively, did not prevail in CPE.
Dot Registry applied for the opportunity to operate the new top-level domains .LLC, .INC, and .LLP. Dot Registry is one of nine applicants for .LLC, one of eleven applicants for .INC, and one of four applicants for .LLP. Dot Registry, however, is the only applicant that submitted community-based applications for these gTLDs.
The CPE panels evaluating Dot Registry's applications (CPE Panels) determined that the applications did not meet the criteria required to prevail in CPE, awarding only five of the 14 points needed to prevail in CPE (CPE Reports). Dot Registry filed Reconsideration Requests 14-30, 14-32, and 14-33, seeking reconsideration of the CPE Reports. On 24 July 2014, the Board Governance Committee (BGC) denied the Reconsideration Requests, finding that Dot Registry had "failed to demonstrate that the Panels acted in contravention of established policy or procedure in rendering their respective CPE Reports…."
Dot Registry initiated this IRP on 22 September 2014, challenging the BGC's denial of Dot Registry's Reconsideration Requests, as well as purportedly challenging ICANN's appointment of the Economist Intelligence Unit (EIU) as the third party provider to conduct CPEs, and the Board's response to advice from ICANN's Governmental Advisory Committee regarding .LLC, .INC, and .LLP.
In a 2-1 decision, the Panel majority declared Dot Registry to be the prevailing party, and determined that "the actions and inactions of the Board were inconsistent with ICANN's Articles of Incorporation and Bylaws." (Final Declaration at ¶ 151.) Specifically, the Panel majority declared that "the Board (acting through the BGC) failed to exercise due diligence and care in having a reasonable amount of facts in front of them and failed to fulfill its transparency obligations" and that there was not sufficient evidence to "support a determination that the Board (acting through the BGC) exercised independent judgment in reaching the reconsideration decisions." (Id. at ¶¶ 151-152.) The Panel majority further declared that ICANN "shall pay to Dot Registry, LLC $235,294.37 representing said fees, expenses and compensation previously incurred by Dot Registry, LLC upon determination that these incurred costs have been paid in full." (Id. at ¶ 154.)
The Board has noted that the Panel majority stated that "in reaching these conclusions, the Panel is not assessing whether ICANN staff or the EIU failed themselves to comply with obligations under the Articles, the Bylaws, or the [Applicant Guidebook (Guidebook)]." (Id. at ¶ 152.) Further, it is also noted that "[t]he Panel majority decline[d] to substitute its judgment for the judgment of the CPE as to whether Dot Registry is entitled to Community priority." (Id. at ¶ 153.)
The Panel majority did consider and challenge the current standard of review employed by the BGC in reviewing Reconsideration Requests, stating that it thought the standard to be applied by the BGC in "evaluating a Reconsideration Request" should be: "Is the action taken consistent with the Articles, the Bylaws, and the [Guidebook]?" (Id. at ¶ 79.) The Panel majority further indicated that, in reviewing Reconsideration Requests, "the BGC must determine whether the CPE (in this case the EIU) and ICANNstaff respected the principles of fairness, transparency, avoiding conflicts of interest, and non-discrimination as set out in the ICANN Articles, Bylaws and [Guidebook]" (id. at ¶ 88), and that third parties such as the EUI are "obligated to comply with ICANN's Articles and Bylaws." (Id. at ¶ 101.)
The Board acknowledges the important statements by the Panel with respect to the standard of review for Reconsideration Requests and will consider next steps in relation to Dot Registry's Reconsideration Requests or the relevant new gTLDs before the Board takes any further action.
As required, the Board has considered the Final Declaration. As this Board has previously indicated, the Board takes very seriously the results of one of ICANN's long-standing accountability mechanisms.
Accordingly, and for the reasons set forth in this Resolution and Rationale, the Board has accepted the Panel's Final Declaration as indicated above.
The Board also notes that it has received a letter from Dot Registry, dated 6 August 2016, stating, among other things, that its "90 page expert report" is "sufficient and compelling to assist the Board with determining that Dot Registry's applications should have passed CPE" and requesting that ICANN "proceed to contracting with Dot Registry for .INC, .LLC, and .LLP." (See Attachment B to Reference Materials and https://www.icann.org/en/system/files/correspondence/jolles-to-icann-board-0... <https://www.icann.org/en/system/files/correspondence/jolles-to-icann-board-06aug16-en.pdf>[PDF, 1.5 MB].) The Board would like to reiterate that "[t]he Panel majority decline[d] to substitute its judgment for the judgment of the CPE as to whether Dot Registry is entitled to Community priority." (Id. at ¶ 153.)
Further, the Board notes that there are numerous other applications pending for these gTLDs (nine for .INC, eight for .LLC, and three for .LLP), which also must be considered. Accordingly, as noted above, the Board will consider next steps before taking any further action with respect to Dot Registry's Reconsideration Requests, or the .INC, .LLC, or .LLP applications.
Finally, the Board also notes that there have been online blogged reports about what the Final Declaration actually says, yet many of the items reported on have been factual inaccuracies, which have been identified and corrected in Attachment C to the Reference Materials related to this agenda item.
This action is not expected to have any direct financial impact on the organization, although there could be some indirect costs, such as analysis relating to the standard on Reconsideration Requests. This action will not have any direct impact on the security, stability or resiliency of the domain name system.
This is an Organizational Administrative function that does not require public comment.
<> Consideration of Request for Cancellation of HOTEL Top-Level Domain S.a.r.l's (HTLD's) Application for .HOTEL Whereas, Travel Reservations SRL (formerly Despegar Online SRL), Famous Four Media Limited, Fegistry LLC, Minds + Machines Group Limited, Donuts Inc., and Radix FZC (collectively, .HOTEL Claimants) have requested that ICANNcancel HOTEL Top-Level Domain S.a.r.l's (HTLD's) application for .HOTEL.
Whereas, the .HOTEL Claimants' request is premised on Dirk Krischenowski's apparent business connections to HTLD, coupled with his exploitation of the portal issue that allowed parties to access confidential information of various applicants for new gTLDs, including information of several of the .HOTEL Claimants.
Whereas, ICANN's forensic investigation of the portal issue determined that Mr. Krischenowski's unauthorized access to confidential information did not occur until after HTLD submitted its application in 2012 and after HTLD elected to participate in CPE on 19 February 2014.
Whereas, ICANN has not uncovered any evidence that: (i) the information Mr. Krischenowski may have obtained as a result of the portal issue was used to support HTLD's application for .HOTEL; or (ii) any information obtained by Mr. Krischenowski enabled HTLD's application to prevail in CPE.
Resolved (2016.08.09.14), the Board concludes that cancellation of HTLD's application for .HOTEL is not warranted.
Resolved (2016.08.09.15), the Board directs the President and CEO, or his designee(s), to move forward with processing HTLD's application for .HOTEL.
<> Rationale for Resolutions 2016.08.09.14 – 2016.08.09.15 HTLD and the .HOTEL Claimants each applied for .HOTEL and were all placed in a contention set. As HTLD's application was community-based, its application was invited to participate in Community Priority Evaluation (CPE) on 19 February 2014. HTLD prevailed in CPE on 11 June 2014, thereby excluding the .HOTEL Claimants from continuing through the process.
The .HOTEL Claimants have argued that Mr. Krischenowski's exploitation of the portal issue that allowed parties to access confidential information of various applicants for new gTLDs, including information of several of the .HOTEL Claimants, coupled with Mr. Krischenowski's apparent business connections to HTLD, is cause for ICANN to cancel HTLD's .HOTEL application.
ICANN's forensic investigation of the portal issue revealed that the user credentials of Mr. Krischenowski and his associates, Mr. Oliver Süme and Ms. Katrin Ohlmer, were responsible for numerous instances of suspected intentional unauthorized access to other applicants' confidential information, which occurred from March through October 2014. Mr. Krischenowski acknowledged that he accessed confidential information of other users, but denied that he acted improperly or unlawfully. Among other things, Mr. Krischenowski claimed that he did not realize the portal issue was a malfunction, and that he used the search tool in good faith. Mr. Krischenowski and his associates also certified to ICANN that they would delete or destroy all information obtained, and affirmed that they had not used and would not use the information obtained, or convey it to any third party.
With respect to claims about Mr. Krischenowski's involvement with HTLD when he accessed the confidential information, ICANN has been informed that he was not directly linked to HTLD's .HOTEL application as an authorized contact or as a shareholder, officer or director. Mr. Krischenowski was a 50% shareholder and managing director of HOTEL Top-Level-Domain GmbH, Berlin (GmbH Berlin), which was a minority (48.8%) shareholder of HTLD.
ICANN has not uncovered any evidence that: (i) the information Mr. Krischenowski may have obtained as a result of the portal issue was used to support HTLD's application for .HOTEL; or (ii) any information obtained by Mr. Krischenowski enabled HTLD's application to prevail in CPE. HTLD submitted its application in 2012, elected to participate in CPE on 19 February 2014, and prevailed in CPE on 11 June 2014. Mr. Krischenowski's first instance of unauthorized access to confidential information did not occur until early March 2014; and his searches relating to the .HOTEL Claimants did not occur until 27 March, 29 March and 11 April 2014. Therefore, even assuming that Mr. Krischenowski did obtain confidential information belonging to the .HOTEL Claimants, this would not have had any impact on the CPE process for HTLD's .HOTEL application. Specifically, whether HTLD's application met the CPE criteria was based upon the application as submitted in May 2012, or when the last documents amending the application were uploaded by HTLD on 30 August 2013 – all of which occurred before Mr. Krischenowski or his associates accessed any confidential information, which occurred from March 2014 through October 2014. In addition, there is no evidence, or claim by the .HOTEL Claimants, that the CPE Panel had any interaction at all with Mr. Krischenowski or HTLD during the CPE process, which began on 19 February 2014.
In furtherance of the Board's 10 March 2016 resolution directing ICANN's "President and CEO, or his designee(s), to complete the investigation of the issues alleged by the .HOTEL Claimants regarding the portal configuration as soon as feasible and to provide a report to the Board for consideration following the completion of that investigation" (see 10 March 2016 Board Resolutions, available at https://www.icann.org/resources/board-material/resolutions-2016-03-10-en#2.a <https://www.icann.org/resources/board-material/resolutions-2016-03-10-en#2.a>), ICANN informed HTLD of the .HOTEL Claimants' request that ICANN cancel HTLD's .HOTEL application, provided HTLD an opportunity to respond, and sought information from HTLD regarding its association with Mr. Krischenowski. In response, Mr. Philipp Grabensee, the now sole Managing Director of HTLD, confirmed for ICANN that at the time of the challenged conduct, Mr. Krischenowski was a 50% shareholder and managing director of GmbH Berlin, which was a minority (48.8%) shareholder of HTLD. Mr. Grabensee also confirmed that Mr. Krischenowski acted as a consultant for HTLD's application at the time it was submitted (in 2012), and that Mr. Krischenowski represented HTLD in three string confusion objections initiated by HTLD against applications by Despegar and Booking.com in 2013.
Mr. Grabensee also stated that, in accessing the proprietary information, Mr. Krischenowski did not act on HTLD's behalf or in support of its application for .HOTEL. Mr. Grabensee noted that Mr. Krischenowski did not use HTLD's Login ID, did not inform HTLD's personnel about "his action," "did not provide any of the accessed information" to HTLD or its personnel, and HTLD "personnel did not have any knowledge about Mr. Krischenowski's action, and did not consent to it or approve it."
Lastly, Mr. Grabensee noted the following recent changes to HTLD's relationship with Mr. Krischenowski: (i) the business consultancy services between HTLD and Mr. Krischenowski were terminated as of 31 December 2015; (ii) Mr. Krischenowski stepped down as a managing director of GmbH Berlin effective 18 March 2016; (iii) Mr. Krischenowski's wholly-owned company transferred its 50% shares in GmbH Berlin to Ms. Ohlmer (via her wholly-owned company); (iv) GmbH Berlin will transfer its shares in HTLD to Afilias plc; and (v) Mr. Grabensee is now the sole Managing Director of HTLD.
The Board had the opportunity to consider all of the materials submitted relating to the .HOTEL Claimants' request for cancellation of HTLD's .HOTEL application. Following consideration of all relevant information provided and for the reasons set forth in the Resolution and Rationale, the Board has determined that cancellation of HTLD's .HOTEL application is not warranted, and the .HOTEL Claimants' request is therefore denied.
The Board takes these claims seriously and the Board members have exercised independent judgment in making this decision, which it deems in the best interest of the organization and the community as a whole. The Board, however, does acknowledge that, based on the information available, Mr. Krischenowski may have taken some improper actions in relation to the portal configuration issue, and the Board is considering whether this conduct should be addressed directly with Mr. Krischenowski.
This decision has no direct financial impact on ICANN and will not impact the security, stability and resiliency of the domain name system.
This decision is an Organizational Administrative Function that does not require public comment.
<> Executive Session - Confidential: <> Ombudsman FY16 At-Risk Compensation Whereas, the Compensation Committee recommended that the Board approve payment to the Ombudsman of his FY16 at-risk compensation.
Resolved (2016.08.09.16), the Board hereby approves a payment to the Ombudsman of his FY16 at-risk compensation component.
<> Rationale for Resolution 2016.08.09.16 Annually the Ombudsman has an opportunity to earn a portion of his compensation based on specific performance goals set by the Board, through the Compensation Committee. This not only provides incentive for the Ombudsman to perform above and beyond his regular duties, but also leads to regular touch points between the Ombudsman and Board members during the year to help ensure that the Ombudsman is achieving his goals and serving the needs of the ICANNcommunity.
Scoring of the Ombudsman's objectives results from both the Ombudsman self-assessment, as well as review by the Compensation Committee, with a recommendation to the Board.
Scoring the Ombudsman's annual performance objectives is in furtherance of the goals of ICANN and helps increase the Ombudsman's service to the ICANN community. While there is a fiscal impact from the results of the scoring, that impact is already accounted for in the annual budget. This action will have no impact on the security, stability or resiliency of the domain name system.
This is an Organizational Administrative Function that does not require public comment.
<> Officer Compensation Whereas, the attraction and retention of high caliber staff is essential to ICANN's operations and ICANN desires to ensure competitive compensation for staff.
Whereas, independent market data provided by outside expert compensation consultants indicates that current and proposed increases to compensation amounts for the President, GDD, General Counsel & Secretary, CFO, COO, CIO, and SVP, Policy Development Support and General Manager, ICANNRegional Headquarters - Istanbul are within ICANN's target of the 50th to 75th percentile for total cash compensation based on comparable market data for the respective positions.
Whereas, independent market data provided by outside expert compensation consultants indicates that current compensation for the CFO is below ICANN's target of the 50th to 75th percentile for total cash compensation based on comparable market data for the respective positions.
Whereas, the compensation for the President, GDD, the General Counsel & Secretary, the CFO, and the SVP, Policy Development Support and General Manager, ICANNRegional Headquarters - Istanbul, has not been adjusted since an effective date of 1 July 2014.
Whereas, the compensation adjustments for the COO and the CIO will establish better alignment with compensation review timeline of the other four Officers.
Whereas, each Board member has confirmed that they are not conflicted with respect to compensation packages for any of ICANN's Officers.
Resolved (2016.08.09.17), the Board grants the President and CEO the discretion to adjust the compensation for FY17, effective 1 July 2016, of: (i) Akram Atallah, President, GDD; (ii) John Jeffrey, General Counsel & Secretary; and (iii) David Olive, SVP, Policy Development Support and General Manager, ICANN Regional Headquarters – Istanbul, in accordance with the independent study on comparable compensation, subject to a limitation that their annual base salaries for FY17 shall not increase by more than 6% for from their current base salaries.
Resolved (2016.08.09.18), the Board grants the President and CEO the discretion to adjust the compensation for FY17, effective 1 July 2016, of Xavier Calvez, the CFO, in accordance with the independent study on comparable compensation, subject to a limitation that his annual base salary for FY17 shall not increase by more than 10% from his current annual base salary.
Resolved (2016.08.09.19), the Board grants the President and CEO the discretion to adjust the compensation for FY17, effective 1 July 2016, of Susanna Bennett, the COO, in accordance with the independent study on comparable compensation, subject to a limitation that her annual base salary for FY17 shall not increase by more than 3% from her current annual base salary.
Resolved (2016.08.09.20), the Board grants the President and CEO the discretion to adjust the compensation for FY17, effective 1 July 2016, of Ashwin Rangan, the CIO, in accordance with the independent study on comparable compensation, subject to a limitation that his annual base salary for FY17 shall not increase by more than 5% from his current annual base salary.
<> Rationale for Resolution 2016.08.09.16 – 2016.08.09.20 Attracting and retaining high caliber staff by providing a competitive compensation package is crucial to the organization. An improving job market will make more opportunities available for high caliber performers outside of ICANN.
ICANN's President and CEO has requested that he be granted the discretion to increase the FY17 base salaries of: (i) the President, GDD, the General Counsel & Secretary, and the SVP, Policy Development Support and General Manager, ICANN Regional Headquarters - Istanbul) by up to 6% of their current base salaries; (ii) the CFO by up to 10% of his current base salary; (iii) the COO by up to 3% of her current base salary; and (iv) the CIO by up to 5% of his current base salary. The President and CEO has also informed the Board that he intends to also exercise the same discretion with respect to the other members of ICANN's Executive Team who are not Officers (which does not require Board approval).
ICANN is in a critical phase that calls for continuity of certain skill and expertise, particularly with ongoing key projects including the New gTLD Program, Affirmation of Commitments and other organizational reviews underway, the U.S. Governments' IANA stewardship transition, expanding contractual compliance, and enhanced globalization efforts, among many others. Each of these projects requires knowledgeable and skilled executives to ensure ICANN's operational goals and objectives are met while ensuring that risk is mitigated to the greatest extent possible. Adhering to ICANN's employment philosophy, and providing competitive compensation, will help ensure these goals are achieved.
It should be noted, however, that previously it had been discussed that the plan was to only seek authorization to increase relevant Officers' salaries every two years. Last year, the Board authorized the President and CEO to use his discretion to adjust the base salary of the two Officers whose current compensation had not been adjusted since they started working for ICANN. These adjustments were made effective 1 July 2015, which is the same date on which all other staff realizes their salary adjustments.
In trying to better align the timing of compensation review and increases for all staff, it is being recommended that Officer's base salaries be reviewed for adjustment this year and each year hereafter. This is a change from the current two year Officer compensation review and adjustment cycle.
Continuity and retention of key personnel during key organization phases is beneficial to all aspects of the organization. Thus, salary adjustments provided under this resolution likely will have a positive impact on the organization and its effort to fulfill its mission, as well as on the transparency and accountability of the organization. There will be some fiscal impact to the organization, but that impact will not have an effect on the overall current fiscal year budget and will be covered in the FY17 budget. This resolution will not have any 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.
Published on 11 August 2016
You Tube <http://www.youtube.com/icannnews> Twitter <https://www.twitter.com/icann> LinkedIn <https://www.linkedin.com/company/icann> Flickr <http://www.flickr.com/photos/icann> Facebook <http://www.facebook.com/icannorg> RSS Feeds <https://www.icann.org/en/news/rss> Community Wiki <https://community.icann.org/> ICANN Blog <https://www.icann.org/news/blog> Who We Are <https://www.icann.org/get-started> <https://www.icann.org/en/about/learning> <https://www.icann.org/en/about/participate> <https://www.icann.org/resources/pages/groups-2012-02-06-en> <https://www.icann.org/resources/pages/board-of-directors-2014-03-19-en> <https://www.icann.org/presidents-corner> <https://www.icann.org/en/about/staff> <https://icann-openhire.silkroad.com/epostings/index.cfm?fuseaction=app.allpositions&company_id=16025&version=1> <https://www.icann.org/en/news/newsletter> <https://www.icann.org/development-and-public-responsibility> Contact Us <https://forms.icann.org/en/contact> <https://www.icann.org/resources/pages/customer-support-2015-06-22-en> <https://www.icann.org/about/staff/security> <https://www.icann.org/en/contact/pgp-keys> <https://www.icann.org/contact/certificate-authority> <https://www.icann.org/resources/pages/contact-f2-2012-02-25-en> <http://forms.icann.org/en/about/aoc-review/contact> <http://forms.icann.org/en/groups/reviews/contact> <http://forms.icann.org/en/contact/speakers> <https://www.icann.org/en/news/press> Accountability & Transparency <https://www.icann.org/en/news/in-focus/accountability/mechanisms> <https://www.icann.org/resources/pages/irp-2012-02-25-en> <https://www.icann.org/groups/board/governance/reconsideration> <https://www.icann.org/help/ombudsman> Governance <https://www.icann.org/en/about/governance> <https://www.icann.org/en/about/agreements> <https://www.icann.org/en/about/aoc-review> <https://www.icann.org/about/annual-report> <https://www.icann.org/en/about/financials> <https://www.icann.org/en/about/transparency> <https://www.icann.org/en/about/planning> <https://www.icann.org/dashboard> <https://www.icann.org/en/news/rfps> <https://www.icann.org/en/news/litigation> <https://www.icann.org/en/news/correspondence> Help <https://www.icann.org/en/help/dispute-resolution> <https://www.icann.org/en/help/dndr> <https://www.icann.org/en/help/name-collision> <https://www.icann.org/en/news/announcements/announcement-06mar07-en.htm> <http://whois.icann.org/> © 2016 Internet Corporation For Assigned Names and Numbers.Privacy Policy <https://www.icann.org/en/help/privacy>Terms of Service <https://www.icann.org/en/help/tos>Cookie Policy <https://www.icann.org/en/help/privacy-cookie-policy> 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 <http://icann.org/>"" is not an IDN."
_______________________________________________ ALAC mailing list ALAC@atlarge-lists.icann.org https://atlarge-lists.icann.org/mailman/listinfo/alac
At-Large Online: http://www.atlarge.icann.org ALAC Working Wiki: https://community.icann.org/display/atlarge/At-Large+Advisory+Committee+(ALA...)