Please note that all documents referenced in the agenda have been gathered on a Wiki page for convenience and easier access: https://community.icann.org/x/hIsCBw
This agenda was established according to the GNSO Operating Procedures v3.3, updated on 30 January 2018
- An excerpt of the ICANN Bylaws defining the voting thresholds is provided in Appendix 1 at the end of this agenda.
- An excerpt from the Council Operating Procedures defining the absentee voting procedures is provided in Appendix 2 at the end of this agenda.
GNSO Council meeting held at 12:00 UTC
Coordinated Universal Time: 12:00 UTC: https://tinyurl.com/yy5b9v84
05:00 Los Angeles; 08:00 Washington; 13:00 London; 17:00 Islamabad; 21:00 Tokyo; 23:00 Melbourne
GNSO Council Meeting Audio Cast
Listen in browser: http://stream.icann.org:8000/stream01
Listen in application such as iTunes: http://stream.icann.org:8000/stream01.m3u
Councilors should notify the GNSO Secretariat in advance if they will not be able to attend and/or need a dial out call.
Item 1: Administrative Matters (10 mins)
1.1 - Roll Call
1.2 - Updates to Statements of Interest
1.3 - Review / Amend Agenda
1.4 - Note the status of minutes for the previous Council meetings per the GNSO Operating Procedures:
Minutes of the GNSO Council meeting on the 22 August 2019 were posted on the 6 September 2019
Minutes of the GNSO Council meeting on the 19 September 2019 were posted on 10 October 2019
Item 2: Opening Remarks / Review of Projects & Action List (10 minutes)
Item 3: Consent Agenda (5 minutes)
- Approval of the addition to the GNSO Operating Procedures of a proposed process for the selection of Board seat #14 by the Non-Contracted Parties House (per current rules in the Operating Procedures concerning the selection of Board seats by each House)
Item 4: COUNCIL DISCUSSION – Update From the Drafting Team on New Templates and Guidelines for GNSO as a Decision Participant in the Empowered Community (EC) (25 minutes)
Following the adoption by the GNSO Council of the revised GNSO Operating Procedures, as well as the proposed modifications to the ICANN Bylaws which were adopted by the ICANN Board of Directors on 13 May 2018, staff identified additional proposed steps to be taken to ensure preparedness as well as facilitate the ability for the GNSO Council to act in relation to the new roles and responsibilities outlined in the post-transition Bylaws.
The Drafting Team was established to develop guidelines, including any recommendations for changes to GNSO Operating Procedures if applicable, that clarify additional details or steps related to a particular action to be completed by the GNSO that falls within its existing process or procedure. These guidelines are meant to help the GNSO effectively participate as a Decision Participant in the Empowered Community (EC) in accordance with the post-transition ICANN Bylaws.
The Drafting Team has nearly completed its duties and fulfilled its work plan to provide the guidelines and motion templates to the GNSO Council in time for the October meeting. All proposed guidelines have been delivered to the GNSO Council with the exception of two documents relating to joint ccNSO/GNSO actions relating to Special IANA Function Reviews (IFRs).
It has been suggested that the Joint Consultation Guidelines for the ccNSO/GNSO actions related to Special IFRs could be symbolically submitted to both the GNSO and ccNSO Councils in time for their respective November meetings during ICANN66. They could be discussed in the joint meeting of the Councils in Montreal and, if appropriate, jointly agreed in Montreal.
The Drafting Team will provide a briefing to the GNSO Council, to help ensure that the Council is equipped to vote to adopt the updated processes and procedures.
Here, the Drafting Team will provide a briefing to the GNSO Council.
4.1 – Introduction of topic (Council Leadership; Heather Forrest - Drafting Team Chair) Presentation
4.2 – Council discussion
4.3 – Next steps
Item 5: COUNCIL DISCUSSION - Empowered Community Approval Action on Fundamental Bylaws Amendment re IANA Naming Function Review Composition (10 minutes)
On 8 September 2019, the ICANN Board approved an amendment to the Fundamental Bylaws at Article 18, Section 18.7(b) (regarding IANA Naming Function Review Team composition). Pursuant to section 25.2(e) of the ICANN Bylaws, on 13 September 2019 the relevant notice was served to the GNSO, as a member of the Empowered Community.
Per the notice, ICANN’s General Counsel and Secretary John Jeffrey notes that “Within the Fundamental Bylaws Amendment Process, the Empowered Community now requires an Approval Action Community Forum to convene for the purpose of considering the proposed amendments. I confirm my understanding that the EC Administration has already requested that the Approval Action Community Forum convene during ICANN’s 66th public meeting in accordance with Annex D, Section 1.3(c). Pursuant to Annex D, Section 1.3(f), ICANN and any Supporting Organization or Advisory Committee may deliver to the EC Administration its views and questions on the Approval Action in advance of the Approval Action Community Forum. The Empowered Community Approval Action Process is set out in full at Annex D, Section 1 of the | 3 ICANN Bylaws. The timeline for the Empowered Community’s exercise of this Approval Action Process will be tracked, including the associated deadlines, at https://www.icann.org/ec.”
With the Community Action Approval Forum scheduled for Sunday, 3 November 2019, during ICANN66, the GNSO as a member of the Empowered Community should discuss whether it intends to provide any input on the Approval Action.
Here, the Council will discuss whether it needs to share its views or questions on the Approval Action in advance of the Approval Action Community Forum.
5.1 – Introduction of topic (Council Leadership)
5.2 – Council discussion
5.3 – Next steps
Item 6: COUNCIL DISCUSSION - ICANN Board Response to the GNSO Council Letter Regarding the Consultation on Non-Adopted EPDP Phase 1 Parts of Recommendations (purpose 2 and recommendation #12) (15 minutes)
On 15 May, the ICANN Board informed the GNSO Council of the Board’s action in relation to the GNSO’s EPDP Phase 1 policy recommendations. The Board did not adopt two of the recommendations in full, where the Board has identified that portions of those recommendations are not in the best interests of the ICANN Community or ICANN and is initiating the consultation process between the Board and the GNSO Council. This concerns recommendation #1, purpose 2 and recommendation #12, deletion of data in the Organization field. As required under the ICANN Bylaws at Annex A-1,Section 6.b, a Board Statement is attached as Annex A to the letter, articulating the reasons for the Board’s non-adoption of these two items. As per the Bylaw requirements (Annex A-1, Section 6.c), “the Council shall review the Board Statement for discussion with the Board as soon as feasible after the Council's receipt of the Board Statement.” During the Council’s Extraordinary Meeting on 28 May 2019, it reviewed the Board Statement and conducted a lengthy discussion on the best path forward.
On 30 May 2019, Keith Drazek, the GNSO Chair provided an update to the EPDP Team on the expected next steps in relation to the ICANN Board’s action on Phase 1 recommendations and requested that the EPDP Team provide input to identify any questions, comments or concerns in relation to ICANN Board’s action on the EPDP Phase 1 Recommendations. Subsequently, on 9 June 2019, Janis Karklins, Chair of the EPDP, informed the GNSO Chair of the following preliminary input noting that there was not sufficient time to formalize and agree on an EPDP Team response:
“• In relation to purpose 2, there is a general understanding for why the Board decided to not adopt this purpose and the EPDP Team confirms that it considers it firmly within its scope for phase 2 to further review this purpose in the context of the System for Standardized Access / Disclosure (SSAD);
- For recommendation #12, some additional context has been provided that may help explain the thinking behind the EPDP Team’s original recommendation. However, there is no agreement at this stage on whether or not the Board’s non-adoption should be supported.”
During the Council’s June 2019 meeting, it continued to consider the next steps, taking into account a discussion with the ICANN Board at ICANN65. The reasoning and intent of the deletion part of recommendation #12 was explained to the Board, as well as the intent of purpose 2 and it was agreed that a letter should be drafted and sent to the ICANN Board as well as the EPDP Team to provide an update on the current thinking of the GNSO Council and likely next steps. The Council discussed a draft response on its 18 July 2019 meeting, subsequent discussion on the mailing list, and additional dialogue on the 22 August 2019 meeting. On 9 September 2019, the GNSO Council sent its response to the ICANN Board. On 14 October 2019, the ICANN Board provided its response to the GNSO Council’s update.
Here, the Council will discuss the Board’s response and consider next steps.
See also Annex A-1, Section 6. Board Approval Process below for further details.
Section 6. Board Approval Processes
The Board will meet to discuss the EPDP recommendation(s) as soon as feasible, but preferably not later than the second meeting after receipt of the Recommendations Report from the Staff Manager. Board deliberation on the EPDP Recommendations contained within the Recommendations Report shall proceed as follows:
- Any EPDP Recommendations approved by a GNSO Supermajority Vote shall be adopted by the Board unless, by a vote of more than two-thirds (2/3) of the Board, the Board determines that such policy is not in the best interests of the ICANN community or ICANN. If the GNSO Council recommendation was approved by less than a GNSO Supermajority Vote, a majority vote of the Board will be sufficient to determine that such policy is not in the best interests of the ICANN community or ICANN.
- In the event that the Board determines, in accordance with paragraph a above, that the proposed EPDP Recommendations are not in the best interests of the ICANN community or ICANN (the Corporation), the Board shall (i) articulate the reasons for its determination in a report to the Council (the "Board Statement"); and (ii) submit the Board Statement to the Council.
- The Council shall review the Board Statement for discussion with the Board as soon as feasible after the Council's receipt of the Board Statement. The Board shall determine the method (e.g., by teleconference, email, or otherwise) by which the Council and Board will discuss the Board Statement.
At the conclusion of the Council and Board discussions, the Council shall meet to affirm or modify its recommendation, and communicate that conclusion (the "Supplemental Recommendation") to the Board, including an explanation for the then-current recommendation. In the event that the Council is able to reach a GNSO Supermajority Vote on the Supplemental Recommendation, the Board shall adopt the recommendation unless more than two-thirds (2/3) of the Board determines that such guidance is not in the interests of the ICANN community or ICANN. For any Supplemental Recommendation approved by less than a GNSO Supermajority Vote, a majority vote of the Board shall be sufficient to determine that the guidance in the Supplemental Recommendation is not in the best interest of the ICANN community or ICANN.
6.1 – Introduction of topic (Council leadership)
6.2 – Council discussion
6.3 – Next steps
Item 7: COUNCIL UPDATE – IDN Scoping Small Team (10 minutes)
The ICANN Board resolved in 2010 that IDN variant TLDs will not be delegated until relevant work is completed and directed ICANN org to develop a report identifying what needs to be done with the evaluation, possible delegation, allocation and operation of generic top-level domains (gTLDs) containing variant characters IDNs, in order to facilitate the development of workable approaches to the deployment of gTLDs containing variant characters IDNs. Based on analysis, ICANN org and the community identified two gaps to address: 1) that there is no definition of IDN variant TLDs, and; 2) that there is no IDN variant TLD management mechanism.
The Procedure to Develop and Maintain the Label Generation Rules for the Root Zone in Respect of IDNA Labels (RZ-LGR Procedure) has been developed by the community to define the IDN variant TLDs and, following the Board resolution in 2013 which approved the RZ-LGR Procedure, has been implemented to incrementally develop the Root Zone Label Generation Rules to address the first gap.
ICANN org has developed the Recommendations for Managing IDN Variant TLDs (the Variant TLD Recommendations), a collection of six documents finalized after incorporating the public comment feedback and published them as mechanisms for addressing the second gap identified by the community in the implementation of IDN variant TLDs.
On 14 March 2019, the ICANN Board resolved:
The Board approves the Variant TLD Recommendations and requests that the ccNSO and GNSO take into account the Variant TLD Recommendations while developing their respective policies to define and manage the IDN variant TLDs for the current TLDs as well as for future TLD applications.
The Board requests that the ccNSO and GNSO keep each other informed of the progress in developing the relevant details of their policies and procedures to ensure a consistent solution, based on the Variant TLD Recommendations, is developed for IDN variant ccTLDs and IDN variant gTLDs.
Additionally, and separately, the ICANN Board anticipated adopting the IDN Guidelines v. 4.0 as part of its consent agenda for the 3 May 2019 meeting, but the GNSO Council requested that the vote be deferred, due in part to concerns around the process, as well as specific requirements within the guidelines (e.g.,“same entity” requirement on second level registrations, which are in both the guidelines and the Variant TLD Recommendations). The ICANN Board agreed to the deferral, allowing the GNSO Council additional time to consider the matter.
The Council convened a small team of Councilors and other GNSO members to consider the scope of issues (e.g., IDN Guidelines and IDN Variant Management solutions) related to IDNs and accordingly, recommend a mechanism to address those issues (e.g., leverage existing PDPs, convene new PDP/EPDP, other).
Here, the Council will receive an update on the progress from the small team.
7.1 – Introduction of topic (Council Leadership; Edmon Chung - Small Team lead) - IDN Scoping Team Presentation slide deck
7.2 – Update and council discussion
7.3 – Next steps
Item 8: COUNCIL DISCUSSION - PDP 3.0 Small Group Update/Discussion (10 minutes)
The PDP 3.0 Small Team has completed at least eight (8) out of fourteen (14) PDP 3.0 improvements and has delivered two packages to the GNSO Council. Package one, on improvements 1, 2, 3, and 6 was delivered on 13 August 2019. Package two, on improvements 11, 12, 14, and 16 was delivered on 25 September 2019. The Small Team is nearing completion on package three, which includes improvements 5 and 13 and is making substantial progress on package four, which includes improvements 9 and 15.
The PDP 3.0 small group has prepared a work plan that covers items leading up to ICANN66 and continues to work against that work plan. The work plan also touches on the elements necessary after ICANN66 and leading up to the 2020 Strategic Planning Session.
Here, the Council will receive an update on progress made to date and the work plan to complete the PDP 3.0 implementation.
8.1 - Introduction of topic (Rafik Dammak) PDP 3.0 Presentation slide deck
8.2 - Council discussion
8.3 - Next steps
Item 9: COUNCIL DISCUSSION - ICANN Transfer Policy - Gaining Registrar Form of Authorization (15 minutes)
On 11 October 2019, the GNSO Council received a letter from the Registrar Stakeholder Group (RrSG), where it informed the Council of a policy implementation issue stemming from the EPDP Phase 1 Final Report. The EPDP Phase 1 Final Report replicated a requirement in the Temporary Specification, Section 1.1 of Appendix G, which requires the Gaining Registrar to send a Form of Authorization to the Transfer Contact (FOA).
The RrSG states that, “the rationale is that under the GDPR, the Gaining Registrar does not have consent to process this information (i.e., send an email to an individual that is not its customer). Furthermore, registrars find it is technically impossible to send the gaining FOA because many email addresses are unavailable (i.e., return an email with a link to a web form), resulting in failed transfers.” Because of this issue, the RrSG has a number of open cases with ICANN Contractual Compliance and been unable to resolve the issue with ICANN org.
The RrSG is requesting the GNSO Council’s assistance in raising the matter with the ICANN Board. The RrSG provided a draft letter, which asks the ICANN Board to: “ (1) refer this matter to the impending Transfer Policy review (which could be in the form of a new PDP), and (2) instruct ICANN org to defer any Gaining FOA compliance enforcement until the matter is settled in the Transfer Policy review.”
Here, the Council will discuss how it intends to address the request from the RrSG.
9.1 - Introduction of topic (Pam Little)
9.2 - Council discussion
9.3 - Next steps
Item 10: ANY OTHER BUSINESS (5 minutes)
10.2 - Update on the 2020 Strategic Planning Session
10.3 - Question and Answers With The GNSO Council Liaison to the Governmental Advisory Committee (GAC) during the ICANN66 GNSO Working Session
10.4 - IANA Function Review (IFR) Team - Unavailability of a GNSO co-chair
Appendix 1: GNSO Council Voting Thresholds (ICANN Bylaws, Article 11, Section 11.3(i))
Appendix 2: GNSO Council Absentee Voting Procedures (GNSO Operating Procedures, Section 4.4)
References for Coordinated Universal Time of 12:00 UTC
Local time between March and October Summer in the NORTHERN hemisphere
California, USA (PDT) UTC-7 05:00
San José, Costa Rica (CST) UTC-6 01:00
New York/Washington DC, USA (EDT) UTC-4 08:00
Buenos Aires, Argentina (ART) UTC-3 09:00
Rio de Janeiro, Brazil (BRT) UTC-3 09:00
London, United Kingdom (GMT) UTC+1 13:00
Kinshasa, Democratic Republic of Congo (WAT) UTC+1 13:00
Paris, France (CET) UTC+2 14:00
Moscow, Russia (MSK) UTC +3 15:00
Islamabad, Pakistan (PKT) UTC+5 17:00
Singapore (SGT) UTC+8 20:00
Tokyo, Japan (JST) UTC+9 21:00
Melbourne, Australia (AEDT) UTC+11 23:00
DST starts/ends on Sunday 27 of October 2019, 2:00 or 3:00 local time (with exceptions) for EU countries and on Sunday 03 of November 2019 for the US.