| A | B | C | D | E | F | G | H | I | J | K | L | M | N | O | P | Q | R | S | T | U | V | W | X | Y | Z | AA | |
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
1 | Topic 30: GAC Consensus Advice and GAC Early Warning Description of Difference: Substantive differences include the following: -- Created this separate section on GAC Early Warning and GAC Consensus Advice, apart from Objections. - In recognition of the GAC's role under the ICANN Bylaws, the recommendations were made consistent with the GAC’s role. The WG expressed its preference for certain outcomes (e.g., providing GAC Consensus Advice on TLD types ahead of program launch), but acknowledged that it is unable to impose such requirements on the GAC. - The WG solidified its proposal to remove the language in the AGB that creates a "strong presumption for the ICANN Board that the application should not be approved," which the WG believes is consistent with the GAC’s role under the ICANN Bylaws and encourages mutually beneficial outcomes rather than creating a presumption of rejected applications. - Clarified that GAC Early Warnings must also include rationale for the warning, which should also promote mutually beneficial outcomes. - Converted potential guidance in the Initial Report to a recommendation: RVCs should be allowed as a mechanism to address or mitigate concerns in GAC Early Warning or GAC Consensus Advice. | ||||||||||||||||||||||||||
2 | # | Contributor | Comment | Notes | Leadership Comments | Completion Status | |||||||||||||||||||||
3 | Support Output(s) as written | ||||||||||||||||||||||||||
4 | 1 | Internet Governance Project | GAC overreach needs to be resisted. | GAC overreach | No WG action noted. | ||||||||||||||||||||||
5 | The following contributors did not provide additional comments: Anthony Lee (Individual); Thomas Barrett (Individual); ZHOU, LiGuo (Individual); GoDaddy Registry; gTLDs Registries Stakeholder Group (RySG); Brand Registry Group, Inc; GeoTLD Group; Business Constituency (BC); INTA; GMO Brights Consulting Inc.; Global Brand Owner and Consumer Protection Coalition (GBOC); Internet Governance Project; ALAC | ||||||||||||||||||||||||||
6 | Not ideal but willing to support Output(s) as written | ||||||||||||||||||||||||||
7 | 1 | Intellectual Property Constituency (IPC) and PETILLION Law Firm | The IPC supports Recommendation 30.3. but encourages the Working Group to make explicit that the requisite rationale for GAC Advice must specify the national or international law upon which it is based if such Advice is based in national or international law. The IPC commends the Working Group’s reference to and reliance upon Section 12.2(a)(i) of the ICANN Bylaws and its forbearance from developing ad hoc rules or procedures the interpretation or application of which may conflict or create confusion with the ICANN Bylaws. The IPC encourages the WG, however, to strengthen and clarify its recommendation, “To the extent that the rationale for GAC Consensus Advice is based on public policy considerations, well- founded merits-based public policy reasons must be articulated.” Transparency and predictability will be significantly improved by clarifying this recommendation to note explicitly that expressions of public policy concerns must be supported by relevant data, facts or other evidence, with specific reference to relevant national or international law whenever possible. The IPC considers that this clarification should also be added to Recommendation 30.6 dealing with Early Warning (“Government(s) issuing Early Warning(s) must include a written explanation describing why the Early Warning was submitted and how the applicant may address the GAC member’s concerns.”). The IPC strongly supports Recommendation 30.4, and affirms the Working Group’s acknowledgement that the language in Section 3.1 of the 2012 Applicant Guidebook (stating that GAC Consensus Advice “will create a strong presumption for the ICANN Board that the application should not be approved”) is not reflected in the current version of the ICANN Bylaws. The IPC agrees that the relevant provisions of the Bylaws should be applied in such cases, and that the Applicant Guidebook should not attempt to override or modify those provisions. Consistent with the IPC’s comments on the Initial Report, Overarching Issues; WT 1-4) found here and here the IPC maintains that Registry Voluntary Commitments (RVCs) will enable government concerns to be clearly identified and collaboratively addressed without the need of any presumption of rejection of an application, and that the Board should have flexibility to bring affected governments and applicants together to collaboratively resolve outstanding government concerns not initially addressed by an RVC. Finally, the IPC agrees that Recommendation 30.7, specifying an ability to amend applications (including the addition or modification of RVCs) to address GAC Early Warnings and GAC Consensus Advice, is necessary to give full force and effect to the other recommendations, affirmation and implementation guidance under this Topic 30. | GAC Advice/Early Warning should be based on data/facts/law | No WG action noted. | ||||||||||||||||||||||
8 | The following contributors did not provide additional comments: NORID AS; NCSG; ARTICLE 19 | ||||||||||||||||||||||||||
9 | No opinion | ||||||||||||||||||||||||||
10 | The following contributors did not provide additional comments: Ramtin (Individual); Clement Genty (Individual); Wei Wang (Individual); Yi Zhang (Individual); Xiaodong Lee (Individual); Kun Liu (Individual); Internet Architecture Board; Afnic; dotBERLIN GmbH & Co. KG; Hamburg Top-Level-Domain GmbH; WIPO; Dotzon GmbH; ccNSO Council | ||||||||||||||||||||||||||
11 | Do not support certain aspects or all of the Output(s) | ||||||||||||||||||||||||||
12 | 1 | NCSG | We believe that getting rid of "strong presumption" and including a voting threshold are a good idea. However the Board needs not motivate its rejection any longer as far as we understand, it only needs to provide "reasons" (compare that with "well-founded merits-based public policy reasons" that must be included in a GAC Advice contemplating rejection of an application on the basis of public policy grounds). So this appears to be a reversal from the 2012 AGB? We would rather have a high bar for everyone, both the Board and the GAC, but we can live with it as it stands now. | Have a high bar for both Board and GAC | Noted | No WG action noted. | |||||||||||||||||||||
13 | 2 | Swiss Government OFCOM | We are of the opinion that GAC Early Warning and GAC Advice are useful instruments to identify applications that raise public policy concerns and should be an integral part of any future rounds. We support increasing transparency and fairness of these, including giving applicants an opportunity for direct dialogue with the GAC. However, we do not consider that the PDP should make recommendations on GAC activities which are carried out in accordance with the ICANN Bylaws and the GAC’s internal procedures. On this basis, we do not support: • PDP WG recommendations limiting the scope of GAC advice, in particular, we do not support PDP WG recommendation 30.3 requiring that if GAC advice is “based on public policy considerations, well-founded merits-based public reasons must be articulated” and consider that no additional requirements on what is established in the Bylaws regarding GAC Advice can nor should be established through policy recommendations. • The PDP WG recommended limitation (Implementation Guidance 30.2) regarding the timing of GAC Consensus Advice on future categories of TLDs and particular applications oriented to discentivizing any such Advice being submitted after the finalization and publication of the next Applicant Guidebook. Regarding Recommendation 30.4, we consider that the Bylaws changes from 2016 did not introduce any modification to the section on GAC Advice which would require a change of the language included in Section 3.1 of the 2012 Applicant Guidebook which states that GAC Consensus Advice “will create a strong presumption for the ICANN Board that the application should not be approved”. This language was part of a delicate compromise during the 2012 round preparations and should therefore be maintained. The possibility of maintaining a dialogue with the concerned applicant is not hampered by this language, considering that recommendation 30.7 of the WG establishes ways and means to conduct such a dialogue even in the case of GAC Consensus Advice objecting to an application. Regarding Recommendation 30.6, we do not object to the PDP WG notion that a GAC Early Warning should be explained, however we wish to note that applications may not always be remedied in the opinion of the Government issuing the GAC Early Warning. Therefore, we propose updated language to Recommendation 30.6 noting “how the applicant may potentially address the GAC member’s concerns to the extent feasible”. | Concerns about removal of "strong presumption" Reiterates GAC concerns listed under "new information" | Noted | ACTION ITEM: Take the discussion to the list on the three options with respect to Recommendation 30.3 and GAC Consensus Advice. Options: 1) don’t change the language of the recommendation; 2) clarify the recommendation as suggested by IPC; 3) revise the recommendation to use the language it as in 12.3 of the Bylaws. | |||||||||||||||||||||
14 | 3 | GAC-France | France regrets that the WG recommends removing the provision that GAC Consensus Advice “will create a strong presumption for the ICANN Board that the application should not be approved.” Despite our calls contained in our answer to this spring’s consultation, we have received no explanation from the WG (including in the Rationale for Recommendation 30.4) as to why the language on this issue within the Application Guidebook (AGB) should reflect language that is present in the Bylaws. As long as the AGB provision does not contradict the Bylaws, we see no issue here. At least, France sees no more issue on this point than on Recommendation 30.2 of the Draft Final Report, which also suggests that the ICANN Board adopt a given attitude, concerning GAC Consensus Advice on gTLD categories issued after the launch of the next Round. In our analysis, such Recommendation does not correspond to Bylaw language either and could attract, in the WG’s logic, the same kind of criticism as the “strong presumption” provision. France adds that it has no objection to Recommendation 30.2 per se: the remark above is only made in relation with Recommendation 30.4, in terms of consistency between the content of the AGB and the Bylaws. | Concerns about removal of "strong presumption" | Noted | No WG action noted. | |||||||||||||||||||||
15 | 4 | InfoNetworks LLC | While I appreciated the attempt of the SubPro Group to provide business predictability for commercial applicants, trying to limit the GAC's ability to exercise its public interest obligations set forth in the ICANN bylaws is problematic. This is similar to the SubPro's attempts to limit the ICANN Board's attempt to exercise their fiduciary duty as detailed above. It is important for the ICANN community to understand that the ICANN Board's primary mission is to preserve the security and stability of a unified Internet. While this may result in a situation where the commercial interests of a prospective applicant is negatively impacted as a result the GAC exercising its public interest safeguard, the community must understand that the greater good must prevail over the commercial interests of an individual applicant. | Oppose limiting GAC's ability to exercise its public interest obligations. | Discuss (are we doing that?? ensure intent is matched to text) Just note. | No WG action noted. | |||||||||||||||||||||
16 | New information or interests that the Working Group has not considered | ||||||||||||||||||||||||||
17 | 1 | ARTICLE 19 | We welcome the affirmations and recommendations as written, especially as they call for GAC advice to have “clearly articulated rationale, including national or international law or policy basis.” We also welcome Recommendation 30.4 that calls for revision of Section 3.1 of the 2012 Applicant Guidebook, stating that GAC Consensus Advice “will create a strong presumption for the ICANN Board that the application should not be approved.” We also welcome Recommendation 30.7, which would allow for Registry Voluntary Commitments (RVCs, formerly Voluntary PICs), to address GAC Early Warnings and/or GAC Consensus Advice. This would prevent preemptive restriction on freedom of expression as a result of GAC Early Warnings and/or GAC Consensus Advice. This is the case as the application of GAC Advice and Early Warnings in the 2012 round was interpreted to be very restrictive. We would also recommend that the language in Recommendation 30.7 be further revised to provide for a clear appeals mechanism to allow for applicants to appeal GAC Early Warnings and/or GAC Consensus Advice. We also welcome these recommendations as they are in line with Recommendation 33 of the Competition, Consumer Choice & Trust (CCT) Recommendations and international best practices on freedom of expression. | Appeals mechanism for GAC Early Warning/Advice. | >> to WG for brief discussion?? Nothing to do here. Note: Appeals of a Board Action due to GAC Advice does not exist. Most likely for Accountability Mechanisms to address (JJN) | No WG action noted. | |||||||||||||||||||||
18 | 2 | Registars Stakeholder Group (RrSG) | The RrSG is concerned that some of the PICs that were added as a result of GAC Advice ultimately became more of a burden for registrars than the registries. This is a way to obtain more regulation of registrars without having to amend the Registrar Accreditation Agreement (e.g. without the participation of the two parties to the RAA- the registrars and ICANN). Any PICs that result from GAC advice should be requirements on registries and not registrars (who should not be subject to the requirements of such PICs). Additionally, any requirements for registrars through Registry-Registrar Agreements must be provided sufficiently in advance of TLD launch to ensure that registrars have ample time to implement the requirements. | PICs from GAC Advice should apply to registries not registrars; requirements for registrars should be in advance of TLD launch. | Note We brought this up before, but note to the WG in connection with Base Registry Agreement. | No WG action noted. | |||||||||||||||||||||
19 | 3 | ICANN Board | The Board is committed to working closely with the GAC to encourage the issuing of advice prior to the finalization of the Applicant Guidebook (AGB), with the goal of reducing, if not eliminating, the need for wide-ranging GAC advice. | Encourage advice prior to finalizing AGB | Noted | No WG action noted. | |||||||||||||||||||||
20 | 4 | GAC | The GAC reiterates that GAC Early Warnings and GAC Advice are useful instruments to identify applications that raise public policy concerns and should be an integral part of any future rounds. The GAC remains open to increasing transparency and fairness of these, including giving applicants an opportunity for direct dialogue with the GAC. In this sense, the GAC sees value in the recommendations regarding specified time periods for early warnings, direct dialogue between the early warning issuing government and the applicant, and the opportunity for the applicant to amend its applications based on those consultations. The GAC believes that early warnings are a useful mechanism for beginning a discussion with an applicant on particular issues, questions and potential sensitivities by one or more governments, where an application may potentially infringe national laws or raise sensitivities. Constructive dialogue through this process can help applicants better understand the concerns of governments and help governments better understand the planned operation of proposed gTLDs. GAC Early Warnings may help the applicant to know how it can mitigate concerns and find a mutually acceptable solution. The GAC hence considers an early warning mechanism an essential element of any future round. However, the GAC does not consider that the PDP should make recommendations on GAC activities which are carried out in accordance with the ICANN Bylaws and the GAC’s internal procedures. In this regard, the GAC does not support: ● PDP WG recommendations limiting the scope of GAC advice. In particular, the GAC does not support PDP WG recommendation 30.3 requiring that if GAC advice is “based on public policy considerations, well-founded merits-based public reasons must be articulated”, and considers that no additional requirements on what is established in the Bylaws regarding GAC Advice can nor should be established through policy recommendations. In this sense, current Bylaws (Section 12.3) already prescribe that the GAC, as any advisory committee, needs to provide a rationale, a requirement which the GAC has been abiding by consistently since the Bylaws change in 2016. The rationale provided by the GAC is based on its role under the Bylaws to “consider and provide advice on the activities of ICANN as they relate to governments, particularly matters where there may be an interaction between ICANN’s policies and various laws and international agreements or where they may affect public policy issues”, without any need to add any further requirements through policy. ● The PDP WG recommended limitation (Implementation Guidance 30.2) regarding the timing of GAC Consensus Advice on future categories of TLDs and particular applications, oriented to discentivizing any such Advice being submitted after the finalization and publication of the next Applicant Guidebook. Regarding Recommendation 30.4, some GAC Members continue to consider that the Bylaws changes from 2016 did not introduce any modification to the section on GAC Advice which would require a change of the language included in Section 3.1 of the 2012 Applicant Guidebook which states that GAC Consensus Advice “will create a strong presumption for the ICANN Board that the application should not be approved”. In the opinion of said GAC Members this language was part of a delicate compromise during the 2012 round preparations and should therefore be maintained. Finally, said GAC Members consider that the possibility of maintaining a dialogue with the concerned applicant is not hampered by this language, considering that recommendation 30.7 of the PDP WG establishes ways and means to conduct such a dialogue even in the case of GAC Consensus Advice objecting to an application. Regarding Recommendation 30.6, the GAC agrees with the PDP WG notion that a GAC Early Warning should be explained and that in order to ensure constructive dialogue at an early stage of the procedure and mitigate these concerns it is important for Government(s) issuing Early Warning(s) or the GAC in its advice to provide a written explanation/rationale. However the GAC wishes to note that applications may not always be able to be remedied in the opinion of the Government(s) issuing a GAC Early Warning. Therefore, the GAC proposes updated language to Recommendation 30.6 as follows: “[...] how the applicant may potentially address the GAC member’s concerns to the extent feasible”. Regarding recommendation 30.7, the GAC agrees that an application should be able to proceed if the concerns raised in the GAC Early Warnings and/or GAC Advice have been suitably addressed. In case a mutually acceptable solution cannot be found the provisions from Section 3.1 of the 2012 Applicant Guidebook should apply. | WG shouldn't make recommendations on limiting GAC activities under Bylaws; amend Recommendation 30.6 to allow applicants to address issues raised in GAC Early Warning. | But we certainly discussed = ?? noted or to WG discuss??? Should we amend the language also submitted by Swiss Govt on "possible" mechanisms to address GAC Advice. | ACTION ITEM: Take the discussion to the list on the three options with respect to Recommendation 30.3 and GAC Consensus Advice. Options: 1) don’t change the language of the recommendation; 2) clarify the recommendation as suggested by IPC; 3) revise the recommendation to use the language it as in 12.3 of the Bylaws. | Key points reiterated in Swiss Govt comment above | ||||||||||||||||||||
21 | 5 | ICANN org | Recommendation 30.7: Recommendation 30.7 states that “Applicants must be allowed to change their applications, including the addition or modification of Registry Voluntary Commitments (RVCs, formerly voluntary PICs), to address GAC Early Warnings and/or GAC Consensus Advice.” ICANN org notes that there is a related comment from the ICANN Board with regards to the RVCs. Please refer to the ICANN Board’s comment for the Recommendation 9.1. Furthermore, as the GAC submitted “non-consensus advice” in the previous round, ICANN org also requests clarification as to whether amendments would be permitted in response to “non-consensus advice.” To achieve predictability for the gTLD applicants, ICANN org suggests that there should be a clear process with expected deadlines to change an application in response to GAC Early Warnings and/or GAC Consensus Advice. Overall: There are mentions of both “GAC Advice” and “GAC Consensus Advice” throughout the draft Final Report. It would be helpful if the PDP WG provides its understanding of the distinction between the two. | Clarification on whether amendments permitted in response to "non-consensus advice"; need clear process and deadlines to change an application. | Fix in the Document then Fix terminology to be consistent. Clarity on Deadlines? | ACTION ITEM: Clarify with Leadership the terminology to use be consistent re: “GAC Advice” and “GAC Consensus Advice”. ACTION ITEM: Send the question to the WG list: “is the WG recommending particular actions in the event that the GAC issued non-consensus advice?” | |||||||||||||||||||||
22 | |||||||||||||||||||||||||||
23 | |||||||||||||||||||||||||||
24 | |||||||||||||||||||||||||||
25 | |||||||||||||||||||||||||||
26 | |||||||||||||||||||||||||||
27 | |||||||||||||||||||||||||||
28 | |||||||||||||||||||||||||||
29 | |||||||||||||||||||||||||||
30 | |||||||||||||||||||||||||||
31 | |||||||||||||||||||||||||||
32 | |||||||||||||||||||||||||||
33 | |||||||||||||||||||||||||||
34 | |||||||||||||||||||||||||||
35 | |||||||||||||||||||||||||||
36 | |||||||||||||||||||||||||||
37 | |||||||||||||||||||||||||||
38 | |||||||||||||||||||||||||||
39 | |||||||||||||||||||||||||||
40 | |||||||||||||||||||||||||||
41 | |||||||||||||||||||||||||||
42 | |||||||||||||||||||||||||||
43 | |||||||||||||||||||||||||||
44 | |||||||||||||||||||||||||||
45 | |||||||||||||||||||||||||||
46 | |||||||||||||||||||||||||||
47 | |||||||||||||||||||||||||||
48 | |||||||||||||||||||||||||||
49 | |||||||||||||||||||||||||||
50 | |||||||||||||||||||||||||||
51 | |||||||||||||||||||||||||||
52 | |||||||||||||||||||||||||||
53 | |||||||||||||||||||||||||||
54 | |||||||||||||||||||||||||||
55 | |||||||||||||||||||||||||||
56 | |||||||||||||||||||||||||||
57 | |||||||||||||||||||||||||||
58 | |||||||||||||||||||||||||||
59 | |||||||||||||||||||||||||||
60 | |||||||||||||||||||||||||||
61 | |||||||||||||||||||||||||||
62 | |||||||||||||||||||||||||||
63 | |||||||||||||||||||||||||||
64 | |||||||||||||||||||||||||||
65 | |||||||||||||||||||||||||||
66 | |||||||||||||||||||||||||||
67 | |||||||||||||||||||||||||||
68 | |||||||||||||||||||||||||||
69 | |||||||||||||||||||||||||||
70 | |||||||||||||||||||||||||||
71 | |||||||||||||||||||||||||||
72 | |||||||||||||||||||||||||||
73 | |||||||||||||||||||||||||||
74 | |||||||||||||||||||||||||||
75 | |||||||||||||||||||||||||||
76 | |||||||||||||||||||||||||||
77 | |||||||||||||||||||||||||||
78 | |||||||||||||||||||||||||||
79 | |||||||||||||||||||||||||||
80 | |||||||||||||||||||||||||||
81 | |||||||||||||||||||||||||||
82 | |||||||||||||||||||||||||||
83 | |||||||||||||||||||||||||||
84 | |||||||||||||||||||||||||||
85 | |||||||||||||||||||||||||||
86 | |||||||||||||||||||||||||||
87 | |||||||||||||||||||||||||||
88 | |||||||||||||||||||||||||||
89 | |||||||||||||||||||||||||||
90 | |||||||||||||||||||||||||||
91 | |||||||||||||||||||||||||||
92 | |||||||||||||||||||||||||||
93 | |||||||||||||||||||||||||||
94 | |||||||||||||||||||||||||||
95 | |||||||||||||||||||||||||||
96 | |||||||||||||||||||||||||||
97 | |||||||||||||||||||||||||||
98 | |||||||||||||||||||||||||||
99 | |||||||||||||||||||||||||||
100 | |||||||||||||||||||||||||||