<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
<meta name="Generator" content="Microsoft Word 15 (filtered medium)">
<!--[if !mso]><style>v\:* {behavior:url(#default#VML);}
o\:* {behavior:url(#default#VML);}
w\:* {behavior:url(#default#VML);}
.shape {behavior:url(#default#VML);}
</style><![endif]--><style><!--
/* Font Definitions */
@font-face
        {font-family:"Cambria Math";
        panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
        {font-family:Calibri;
        panose-1:2 15 5 2 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
        {margin:0cm;
        font-size:11.0pt;
        font-family:"Calibri",sans-serif;}
a:link, span.MsoHyperlink
        {mso-style-priority:99;
        color:blue;
        text-decoration:underline;}
span.EmailStyle18
        {mso-style-type:personal-compose;
        font-family:"Times New Roman",serif;}
.MsoChpDefault
        {mso-style-type:export-only;
        font-size:10.0pt;}
@page WordSection1
        {size:612.0pt 792.0pt;
        margin:72.0pt 72.0pt 72.0pt 72.0pt;}
div.WordSection1
        {page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]-->
</head>
<body lang="EN-GB" link="blue" vlink="purple" style="word-wrap:break-word">
<div class="WordSection1">
<div>
<div>
<div>
<p class="MsoNormal"><span style="font-size:10.0pt;font-family:"Arial",sans-serif">Thanks to Jorge for flagging the relevant Bylaws provision dealing with the requirement for a rationale.  With that in mind, I think we should retain the “As stated in the ICANN
 Bylaws” language from 30.3.  <o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:10.0pt;font-family:"Arial",sans-serif"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:10.0pt;font-family:"Arial",sans-serif">I would prefer also to keep the language at the end of that section, ie “</span><span lang="EN-US" style="font-size:10.0pt;font-family:"Arial",sans-serif">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</span><span style="font-size:10.0pt;font-family:"Arial",sans-serif">”, but I can live with its removal if necessary. 
 In practice, an effective rationale provided in accordance with the Bylaws obligations ought to do this in any event – if that rationale did not articulate “</span><span lang="EN-US" style="font-size:10.0pt;font-family:"Arial",sans-serif">well-founded merits-based
 public policy reasons”</span><span lang="EN-US" style="font-size:10.0pt;font-family:"Arial",sans-serif">
</span><span style="font-size:10.0pt;font-family:"Arial",sans-serif">it could be expected both to be less persuasive to the Board and, potentially might even open the Board up to an IRP, were such advice to be followed unquestioningly. 
<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:10.0pt;font-family:"Arial",sans-serif"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:10.0pt;font-family:"Arial",sans-serif">Whilst I do support, and would prefer, the adoption of language reflecting the IPC’s comment, calling for the relevant data, facts, evidence or legal basis to be disclosed, my
 comments above would also apply – a rationale that provides such information will be more persuasive than one which does not. 
<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:10.0pt;font-family:"Arial",sans-serif"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:10.0pt;font-family:"Arial",sans-serif">Thanks<o:p></o:p></span></p>
</div>
</div>
<p class="MsoNormal"><span style="font-family:"Times New Roman",serif"><o:p> </o:p></span></p>
<p class="MsoNormal"><b><span style="font-size:9.0pt;font-family:"Arial",sans-serif;color:black">Susan Payne<o:p></o:p></span></b></p>
<p class="MsoNormal"><span style="font-size:9.0pt;font-family:"Arial",sans-serif;color:black">Head of Legal Policy<b><br>
Com Laude | Valideus</b><o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:9.0pt;font-family:"Arial",sans-serif;color:black">D: +44 20 7421 8255<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:9.0pt;font-family:"Arial",sans-serif;color:black">M: +44 7971 661175<br>
E: <a href="mailto:susan.payne@comlaude.com"><span style="color:#0563C1">susan.payne@comlaude.com</span></a><o:p></o:p></span></p>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<p class="MsoNormal"><span style="font-family:"Times New Roman",serif"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:10.0pt;font-family:"Arial",sans-serif"><o:p> </o:p></span></p>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">Get <a href="https://aka.ms/o0ukef">Outlook for iOS</a><o:p></o:p></p>
</div>
<div class="MsoNormal" align="center" style="text-align:center">
<hr size="2" width="98%" align="center">
</div>
<div id="divRplyFwdMsg">
<p class="MsoNormal"><b><span style="color:black">From:</span></b><span style="color:black"> Gnso-newgtld-wg <gnso-newgtld-wg-bounces@icann.org> on behalf of Jorge.Cancio--- via Gnso-newgtld-wg <gnso-newgtld-wg@icann.org><br>
<b>Sent:</b> Friday, December 4, 2020 7:02:17 PM<br>
<b>To:</b> mail@christopherwilkinson.eu <mail@christopherwilkinson.eu>; jeff@jjnsolutions.com <jeff@jjnsolutions.com>; gnso-newgtld-wg@icann.org <gnso-newgtld-wg@icann.org><br>
<b>Subject:</b> Re: [Gnso-newgtld-wg] 7th Topical E-mail: GAC Advice (Topic 30)</span>
<o:p></o:p></p>
<div>
<p class="MsoNormal"> <o:p></o:p></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal" style="margin-bottom:12.0pt">Dear all<br>
<br>
regarding 30.3 and the obligation to provide a rationale: as the GAC consensus input mentions, this flows from Section 12.3. of the Bylaws applicable to all ACs:<br>
<br>
„Section 12.3. PROCEDURES<br>
<br>
Each Advisory Committee shall determine its own rules of procedure and quorum requirements; provided that each Advisory Committee shall ensure that the advice provided to the Board by such Advisory Committee is communicated in a clear and unambiguous written
 statement, including the rationale for such advice. The Board will respond in a timely manner to formal advice from all Advisory Committees explaining what action it took and the rationale for doing so.“<br>
<br>
<br>
As to 30.4., while it is true that there is no GAC consensus position on retaining the „strong presumption“ language, it is supported by many and the rationale for retaining it is more nuanced as presented.<br>
<br>
Here is the full argumentation from the GAC input:<br>
<br>
„ 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.“<br>
<br>
best<br>
<br>
<br>
Jorge<br>
<br>
(in my national capacity)<br>
<br>
________________________________<br>
<br>
Von: mail@christopherwilkinson.eu CW <mail@christopherwilkinson.eu><br>
Datum: 4. Dezember 2020 um 19:39:57 MEZ<br>
An: Jeff Neuman <jeff@jjnsolutions.com>, gnso-newgtld-wg@icann.org <gnso-newgtld-wg@icann.org><br>
Betreff: Re: [Gnso-newgtld-wg] 7th Topical E-mail: GAC Advice (Topic 30)<br>
<br>
<br>
<br>
Good evening:<br>
<br>
The original text on the Scope of GAC Advice is unnecessarily antagonistic to the GAC and I grant Leadership's wisdom in making the changes, albeit, diplomatically, damage has likely already been done.<br>
<br>
1.  I do not support linking GAC advice or indeed the advice of GAC members explicitly to the Bylaws. (a) the Bylaws are not themselves immutable and (b) it is impossible to foresee all issues that may arise in the context of large and complex Rounds in the
 future.<br>
<br>
2.   I would retain the `strong presumption` language. I do not recall a consensus in the PDP to delete that. Quibbling about it can but become an embarrassment to the Board.<br>
<br>
3.   I would propose to replace 'various laws'   with 'applicable local law' (Articles of Incorporation language).<br>
<br>
Thankyou<br>
<br>
<br>
CW<br>
<br>
El 4 de diciembre de 2020 a las 15:46 Jeff Neuman <jeff@jjnsolutions.com> escribió:<br>
<br>
<br>
All,<br>
<br>
<br>
<br>
This is the Seventh Topical E-mail on outstanding questions being “put to the list.”  This covers GAC Advice (Topic 30)<br>
<br>
<br>
<br>
Remember:  We are down to the wire on this, so unless you have a VERY strong objection to these, we will put these into the document.  If you do have a big issue with the responses to these (all of which were previously discussed and in emails over the past
 1.5 months), please let us know ASAP.  Only comments that provide the rationale for the objection with proposed replacement text to address the specific outstanding questions will now be considered.<br>
<br>
<br>
<br>
Lets not let the perfect be the enemy of the good.<br>
<br>
<br>
<br>
<br>
<br>
ISSUE: Scope of GAC Advice<br>
<br>
<br>
<br>
<br>
<br>
  1.  Current Recommendations<br>
     *   Recommendation 30.3: As stated in the ICANN Bylaws, GAC Consensus Advice must include a clearly articulated rationale. The Working Group recommends that GAC Consensus Advice be limited to the scope set out in the applicable Bylaws provisions and elaborate
 on any “interaction between ICANN's policies and various laws and international agreements or where they may affect public policy issues.” 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.<br>
     *   Recommendation 30.4: Section 3.1 of the 2012 Applicant Guidebook states that GAC Consensus Advice “will create a strong presumption for the ICANN Board that the application should not be approved.” Noting that this language does not have a basis in
 the current version of the ICANN Bylaws, the Working Group recommends omitting this language in future versions of the Applicant Guidebook to bring the Applicant Guidebook in line with the Bylaws language.  The Working Group further notes that the language
 may have the unintended consequence of hampering the ability of the Board to facilitate a solution that mitigates concerns and is mutually acceptable to the applicant and the GAC as described in the relevant Bylaws language. Such a solution could allow an
 application to proceed. In place of the omitted language, the Working Group recommends including in the Applicant Guidebook a reference to applicable Bylaws provisions that describe the voting threshold for the ICANN Board to reject GAC Consensus Advice.<br>
<br>
<br>
<br>
  1.  Comments<br>
<br>
  1.  Re 30.4 -  Some governments (including France and Switzerland) have concerns about the removal of “strong presumption”, but this is not a GAC Consensus statement.<br>
  2.  Re 30.3 – The GAC (and this is supported by a Consensus of GAC) opposes any limitation on the scope of GAC Advice like that found in 30.3<br>
     *   Bylaws State:  “The Governmental Advisory Committee should consider and provide advice on the activities of ICANN as they relate to concerns of 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.”<br>
     *   Our Report states: 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<br>
     *   The Difference: Our WG added the language “well-founded merits-based public policy reasons must be articulated.”<br>
     *   IPC Argues:  We should make this even stronger and add more requirements that there should be data, facts or other evidence provided by GAC as well as reference to relevant national or Internation law wherever possible.<br>
     *   GAC:  Argues that this is not right.  If for 30.4 we are insisting on mirroring the language in the Bylaws, why, they argue, are we not mirroring the Bylaws language for 30.3?<br>
<br>
<br>
<br>
  1.  Leadership Proposal:<br>
<br>
  1.  Leadership believes that the Working Group still supports the notion of defaulting to the Bylaws when talking about GAC Consensus Advice and that we should be consistent.  Therefore, we would recommend keeping 30.4 as is, but changing 30.3 to “As stated
 in the ICANN Bylaws has been the practice of the GAC since at least as early as ICANN56, GAC Consensus Advice must include a clearly articulated rationale. The Working Group recommends that GAC Consensus Advice be limited to the scope set out in the applicable
 Bylaws provisions and elaborate on any “interaction between ICANN's policies and various laws and international agreements or where they may affect public policy issues.” 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.<br>
  2.  Rationale<br>
     *   We recognize that this goes counter to the comments of the IPC, but we believe we should be consistent.  If we are insisting adherence to the Bylaws, then we should take them as a whole, not just the parts that we support.  And the reality is that
 even though it makes logical sense for well-founded merits-based public policies be articulated, this language is not in the Bylaws.<br>
     *   With respect to the first change, we could not find in the ICANN Bylaws where it mandates a clearly articulated rationale, but it has been the practice of the GAC to include one since ICANN56.<br>
<br>
<br>
<br>
<br>
<br>
Please have your comments (If any) by no later than 23:59:59 UTC on Tuesday, December 8, 2020.<br>
<br>
<br>
<br>
Sincerely,<br>
<br>
<br>
<br>
Jeff & Cheryl<br>
<br>
SubPro Co-Chairs<br>
<br>
<br>
<br>
<br>
<br>
[cid:image002.png@01D6CA22.4C0E6940]<br>
<br>
<br>
Jeffrey J. Neuman<br>
<br>
Founder & CEO<br>
<br>
JJN Solutions, LLC<br>
<br>
p: +1.202.549.5079<br>
<br>
E: jeff@jjnsolutions.com<mailto:jeff@jjnsolutions.com><br>
<br>
<a href="http://jjnsolutions.com">http://jjnsolutions.com</a><br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
_______________________________________________<br>
Gnso-newgtld-wg mailing list<br>
Gnso-newgtld-wg@icann.org<br>
<a href="https://mm.icann.org/mailman/listinfo/gnso-newgtld-wg">https://mm.icann.org/mailman/listinfo/gnso-newgtld-wg</a><br>
_______________________________________________<br>
By submitting your personal data, you consent to the processing of your personal data for purposes of subscribing to this mailing list accordance with the ICANN Privacy Policy (<a href="https://www.icann.org/privacy/policy">https://www.icann.org/privacy/policy</a>)
 and the website Terms of Service (<a href="https://www.icann.org/privacy/tos">https://www.icann.org/privacy/tos</a>). You can visit the Mailman link above to change your membership status or configuration, including unsubscribing, setting digest-style delivery
 or disabling delivery altogether (e.g., for a vacation), and so on.<br>
<br>
<o:p></o:p></p>
</div>
</div>
</div>
<hr>
The contents of this email and any attachments are confidential to the intended recipient. They may not be disclosed, used by or copied in any way by anyone other than the intended recipient. If you have received this message in error, please return it to the
 sender (deleting the body of the email and attachments in your reply) and immediately and permanently delete it. Please note that the Com Laude Group does not accept any responsibility for viruses and it is your responsibility to scan or otherwise check this
 email and any attachments. The Com Laude Group does not accept liability for statements which are clearly the sender's own and not made on behalf of the group or one of its member entities. The Com Laude Group includes Nom-IQ Limited t/a Com Laude, a company
 registered in England and Wales with company number 5047655 and registered office at 28-30 Little Russell Street, London, WC1A 2HN England; Valideus Limited, a company registered in England and Wales with company number 06181291 and registered office at 28-30
 Little Russell Street, London, WC1A 2HN England; Demys Limited, a company registered in Scotland with company number SC197176, having its registered office at 15 William Street, South West Lane, Edinburgh, EH3 7LL Scotland; Consonum, Inc. dba Com Laude USA
 and Valideus USA, headquartered at 1751 Pinnacle Drive, Suite 600, McLean, VA 22102, USA; Com Laude (Japan) Corporation, a company registered in Japan having its registered office at Suite 319,1-3-21 Shinkawa, Chuo-ku, Tokyo, 104-0033, Japan. For further information
 see <a href="https://comlaude.com" target="_blank">www.comlaude.com</a>
</body>
</html>