[Gnso-newgtld-wg] Revisions to sections on GAC Advice - Current Status?

Justine Chew justine.chew at gmail.com
Sat May 2 06:10:04 UTC 2020


Paul,

Thank you for noting my rejection to your original proposed text on
Recommendation xx  in the googledoc.

Along with others in this thread, I cannot accept your proposed amended
text of "... *which should result in a strong presumption against the Board
adopting such late GAC Consensus Advice*.] " either.


All,

Anne has pointed out what I wanted to say in addition, but I will raise one
further rationale for my rejection.

Given the current Bylaws, Recommendation xx (rationale 3) seeks to remove
from the AGB "a strong presumption" in favour of GAC Advice and I quote, as
proposed,

*"Section 3.1 of the 2012 Applicant Guidebook states that GAC 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 for applicants, ICANN org, and the GAC to mitigate
concerns and reach a mutually acceptable solution as described in the
relevant Bylaws language, which could allow an application to proceed.*"


Since we are noting that such a strong presumption in favour of GAC Advice
does not have a basis in the current version of the Bylaws, I cannot in the
same breath accept your (amended) proposal which provides for another
strong presumption to arise, albeit against GAC Advice this time. The same
would apply whether the GAC Advice pertains to applications for categories,
groups or classes of applications or string types *or for a particular
string,* IMO - recalling that "any new gTLD application or string" was the
subject of the WG's questions on the role of GAC Advice in the Initial
Report.

Thus, I would like to address the proposed recommendation in question in
totality, for completeness sake.

To this end, I support Anne's proposed compromise language to be applied
towards the original recommendation *in full*, which I now suggest should
be condensed to read as,

"*Recommendation xx: To the extent that the GAC provides GAC Consensus
Advice (as defined in the ICANN Bylaws) in the future on categories of
TLDs, the GAC should provide this Advice prior to the finalization of the
next Applicant Guidebook. **In the event that GAC Consensus Advice is
issued after the application period has begun and whether the GAC Consensus
Advice applies to categories, groups or classes of applications or string
types, or to a particular string, the ICANN Board should take into account
the circumstances resulting in such timing and the possible detrimental
effect of such timing in determining whether to accept or override such GAC
Consensus Advice as provided in the Bylaws." *



Justine


On Sat, 2 May 2020 at 04:44, Aikman-Scalese, Anne <AAikman at lrrc.com> wrote:

> Hi Paul,
>
> I have two issues with the recommended change to the language:
>
>
>
> 1. It does not adequately warn applicants who are not already part of the
> ICANN system that the ByLaws accord a certain status to GAC Consensus
> Advice, i.e. it takes 11 directors to override it.   In this regard, we
> need to let potential applicants know how that advice might affect their
> chances of proceeding.
>
>
>
> 2. Your proposed language still looks like an attempted change in the
> standard that is applicable (via the ByLaws) to GAC Consensus Advice  As
> you know, that was all reviewed and decided upon in all the work that was
> done in Accountability Workstream 2 .  (We don’t want to propose language
> or standards that the Board is going to reject or that would require a
> Fundamental ByLaws Amendment in order for them to accept.  As you know,
> there are lots of triggers related to Empowered Community procedures for
> proposed amendments to the ByLaws.)
>
>
>
> So I want to suggest a compromise as follows.
>
>
>
> *In the event that GAC Consensus Advice is issued after the application
> period has begun and the GAC Consensus Advice applies to categories, groups
> or classes of applications or string types, the ICANN Board should take
> into account the circumstances resulting in such timing and the possible
> detrimental effect of such timing in determining whether to accept or
> override such GAC Consensus Advice as provided in the ByLaws.*
>
>
>
> Anne
>
>
>
> *From:* McGrady, Paul D. <PMcGrady at taftlaw.com>
> *Sent:* Friday, May 1, 2020 4:57 AM
> *To:* Greg Shatan <gregshatanipc at gmail.com>; Aikman-Scalese, Anne <
> AAikman at lrrc.com>; Jeff Neuman <jeff.neuman at comlaude.com>; Cheryl
> Langdon-Orr (cheryl at hovtek.com.au) <cheryl at hovtek.com.au>;
> gnso-newgtld-wg at icann.org
> *Subject:* RE: Revisions to sections on GAC Advice - Current Status?
>
>
>
> *[EXTERNAL]*
> ------------------------------
>
> Hi All,
>
>
>
> I have not been able to connect with Greg on this as hoped.  Even so, I
> submit the following change which I believes deals with concerns some have
> raised that we cannot tie the ICANN Board’s hands but at the same time want
> to create a sense of urgency-leading-to-predictability in relationship to
> when the GAC gives advice:
>
>
>
>  [ In the event that GAC Consensus Advice is issued after the application
> period has begun and the GAC Consensus Advice applies to categories, groups
> or classes of applications or string types, the ICANN Board should take
> into account the circumstances resulting in such timing and the detrimental
> effect of such timing when considering such GAC Consensus Advice *which
> should result in a strong presumption against the Board adopting such late
> GAC Consensus Advice*.]
>
>
>
> I hope this balance is acceptable to the WG.  This is an area of failure
> for the community in the last round and I think it would be really
> unfortunate if we set ourselves up for failure again by not addressing it
> in the new AGB.
>
>
>
> Jeff/Cheryl, will one of you please confirm receipt and that this will be
> on our agenda for discussion in the appropriate WG call?  Thanks!
>
>
>
> Best,
>
> Paul
>
>
>
>
>
>
>
> To receive regular COVID-19 updates from Taft, subscribe here
> <https://www.taftlaw.com/general/subscribe>. For additional resources,
> visit Taft's COVID-19 Resource Toolkit
> <https://www.taftlaw.com/general/coronavirus-covid-19-resource-toolkit>.
>
> This message may contain information that is attorney-client privileged,
> attorney work product or otherwise confidential. If you are not an intended
> recipient, use and disclosure of this message are prohibited. If you
> received this transmission in error, please notify the sender by reply
> e-mail and delete the message and any attachments.
>
> *From:* Greg Shatan <gregshatanipc at gmail.com>
> *Sent:* Tuesday, April 28, 2020 4:37 PM
> *To:* Aikman-Scalese, Anne <AAikman at lrrc.com>
> *Cc:* Jeff Neuman <jeff.neuman at comlaude.com>; Cheryl Langdon-Orr (
> cheryl at hovtek.com.au) <cheryl at hovtek.com.au>; gnso-newgtld-wg at icann.org;
> McGrady, Paul D. <PMcGrady at taftlaw.com>
> *Subject:* Re: Revisions to sections on GAC Advice - Current Status?
>
>
>
> Sorry to have missed last night's witching hour call and sorry this is not
> done.  You can blame me, not Paul.  i will look at the last bit of language
> in play this evening and hammer something out with Paul.
>
>
>
> On Tue, Apr 28, 2020 at 5:03 PM Aikman-Scalese, Anne <AAikman at lrrc.com>
> wrote:
>
> Jeff and Cheryl (and Paul McGrady),
>
> Jeff, you said that if there were any proposed changes to the GAC Advice
> language, we should get those in by May 1.
>
>
>
> However, the last time the WG looked at this, Paul had inserted a number
> of redline changes into the document.  So which version are you expecting
> us to use when you ask for proposals to be made no later than May 1?  And
> are these alternate proposals supposed to come in the form of redlines to
> the WG document in the same manner that Paul used?
>
>
>
> I had understood that Paul was doing some redrafting of his numerous
> edits.  Or was there another small group that was supposed to be convened
> on this point?
>
>
>
> I don’t see any way we can cancel the discussion on the language covering
> GAC Advice, even though you suggested at the top of the last call that we
> might.
>
>
>
> Thank you,
>
> Anne
>
>
>
>
>
> *Anne E. Aikman-Scalese*
>
> Of Counsel
>
> 520.629.4428 office
>
> 520.879.4725 fax
>
> AAikman at lrrc.com
>
> _____________________________
>
> Lewis Roca Rothgerber Christie LLP
>
> One South Church Avenue, Suite 2000
>
> Tucson, Arizona 85701-1611
>
> lrrc.com
>
> Because what matters
>
> to you, matters to us.™
>
>
>
>
> ------------------------------
>
>
> This message and any attachments are intended only for the use of the
> individual or entity to which they are addressed. If the reader of this
> message or an attachment is not the intended recipient or the employee or
> agent responsible for delivering the message or attachment to the intended
> recipient you are hereby notified that any dissemination, distribution or
> copying of this message or any attachment is strictly prohibited. If you
> have received this communication in error, please notify us immediately by
> replying to the sender. The information transmitted in this message and any
> attachments may be privileged, is intended only for the personal and
> confidential use of the intended recipients, and is covered by the
> Electronic Communications Privacy Act, 18 U.S.C. §2510-2521.
>
>
>
> ------------------------------
>
> This message and any attachments are intended only for the use of the
> individual or entity to which they are addressed. If the reader of this
> message or an attachment is not the intended recipient or the employee or
> agent responsible for delivering the message or attachment to the intended
> recipient you are hereby notified that any dissemination, distribution or
> copying of this message or any attachment is strictly prohibited. If you
> have received this communication in error, please notify us immediately by
> replying to the sender. The information transmitted in this message and any
> attachments may be privileged, is intended only for the personal and
> confidential use of the intended recipients, and is covered by the
> Electronic Communications Privacy Act, 18 U.S.C. §2510-2521.
> _______________________________________________
> Gnso-newgtld-wg mailing list
> Gnso-newgtld-wg at icann.org
> https://mm.icann.org/mailman/listinfo/gnso-newgtld-wg
> _______________________________________________
> 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 (https://www.icann.org/privacy/policy) and
> the website Terms of Service (https://www.icann.org/privacy/tos). 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/gnso-newgtld-wg/attachments/20200502/0c5ca994/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.gif
Type: image/gif
Size: 70 bytes
Desc: not available
URL: <http://mm.icann.org/pipermail/gnso-newgtld-wg/attachments/20200502/0c5ca994/image001-0001.gif>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image002.png
Type: image/png
Size: 6524 bytes
Desc: not available
URL: <http://mm.icann.org/pipermail/gnso-newgtld-wg/attachments/20200502/0c5ca994/image002-0001.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image003.jpg
Type: image/jpeg
Size: 2461 bytes
Desc: not available
URL: <http://mm.icann.org/pipermail/gnso-newgtld-wg/attachments/20200502/0c5ca994/image003-0001.jpg>


More information about the Gnso-newgtld-wg mailing list