[Internet Policy] The 2-Character Answer to this GAC Advice Should be "No"

[Seun Ojedeji]

Hello,

Just for my proper understanding (not focusing on that article), I will
like to know what section of the bylaw requires that Board MUST not
react/respond to GAC advice that did not achieve GAC consensus?

My understanding of the bylaw was that the Board had the option to act or
not act if consensus wasn't achieved within GAC and when it's a consensus
advice then such option to not act isn't there.

Overall, I don't think it is appropriate to imply Board acted out of scope
of the bylaw in this scenario.

Regards
Sent from my LG G4
Kindly excuse brevity and typos

On May 17, 2017 2:51 PM, "Mueller, Milton L" <milton at gatech.edu> wrote:

> Shiva:
>
>
>
> First mitigation measures approved by ICANN Board on 8th of November 2016,
> were opposed by many ccTLD registries and Governments during the comment
> period
>
>
>
> MM: This does not change the fact that the GAC does not have consensus.
> GAC advice requires all governments to concur, or refuse to block, before
> it can be considered “advice.” Some governments have all kinds of crazy
> ideas, and ccTLDs have a vested _*private*_ interest in making their
> strings as exclusive as possible. But that idea breaks down when the
> two-letter codes are generic English words like “NO” or “IT” – and may be
> in other languages as well.
>
>
>
> raised by GAC members and also, it fails to address the Dublin GAC advice
> - Capacity limitations of Governments, Simple questions is that "How will
> Governments and ccTLD managers will be able to monitor each New gTLD,
> whether they are misusing the Country Codes or not at second level"
>
>
>
> MM: Real misuse (as opposed to imaginary misuse) should be easy to detect.
> If it is actually causing harm, deception, etc. There are all kinds of
> automated scanning processes that can be used to monitor what domains
> exist. This is not a good argument.
>
>
>
> As per my understanding, there is a need to develop mitigation measures
> separately for each category of risk involved with a different kind of
> gTLDs.
>
>
>
> MM: I don’t agree. The GAC needs to understand that any alleged harms
> associated with a second level name in a new TLD will be discovered ex post
> on a case by case basis, based on the actual facts associated with its use.
> We cannot and should not be using general “categories” and ex ante
> exclusionary rules.
>
>
>
> Regards,
>
>
>
> Shiva Upadhyay
>
>
>
> +91 9717992652 <+91%2097179%2092652>
>
>
>
>
>
> On Wednesday, 17 May 2017 11:14 AM, gangadhar <000004f7f8ca2221-dmarc-
> request at LISTSERV.SYR.EDU> wrote:
>
>
>
> I fully agree with the contention of David, Mueller, Corwin and Farzi
>
> Gangadhar Panday
>
> President
>
> Babul Films Soceity nonprofit
>
> www.babul.ngo
>
> Videos and ICT for Eco-awareness
>
>
>
> On Wednesday, 17 May 2017 7:51 AM, David Cake <dave at DAVECAKE.NET> wrote:
>
>
>
> Yes, this is a very odd, contorted GAC position here, where their
> consensus advice is that they do not have consensus, but the board must
> negotiate with the loud angry minority anyway.
>
>
>
> And the GAC clearly does not have consensus, many governments (including
> my own) are not happy with the attempt to create this right with no legal
> or policy basis.
>
>
>
> David
>
>
>
> There are many governments (including mine) who feel the attempt to create
> a right that has no support
>
> On 17 May 2017, at 4:52 am, Alex Gakuru <gakuru at gmail.com> wrote:
>
>
>
> ICANN is a complicated animal
>
>
>
> On 16 May 2017 9:05 pm, "Robin Gross" <robin at ipjustice.org> wrote:
>
> I also agree with Farzi, Phil, and Milton.  GAC is constantly grabbing for
> more power and we need to be aware of that and push back when it happens,
> such as in this case.
>
>
>
> Thanks,
>
> Robin
>
>
>
> On May 16, 2017, at 10:40 AM, Mueller, Milton L <milton at gatech.edu> wrote:
>
>
>
> Completely agree with Farzaneh and Corwin here. This is more than just a
> 2-letter ccTLD issue, it is an issue fundamental to the accountability
> reforms. When we (NCSG) want a policy change or to advance a new policy, we
> are constantly told that we must work hard to get consensus and/or a
> certain number of votes. Unfortunately, the GAC-board relationship has
> always provided a channel through which the legitimate policy development
> process can be bypassed based on private deals and political bargaining
> between ICANN staff/board and a special interest group. This has to stop!
> It’s extremely corrosive of the integrity of ICANN process.
>
>
>
> If GAC has not offered consensus advice, it creates no obligation
> whatsoever to compromise; indeed, it is not even “advice” in the bylaw
> meaning. This is a fact.
>
>
>
> Dr. Milton L Mueller
>
> Professor, School of Public Policy <http://spp.gatech.edu/>
>
> Georgia Institute of Technology
>
> Internet Governance Project
>
> http://internetgovernance.org/
>
>
>
>
>
>
>
> *From:* NCSG-Discuss [mailto:NCSG-DISCUSS at LISTSERV. SYR.EDU
> <NCSG-DISCUSS at LISTSERV.SYR.EDU>] *On Behalf Of* farzaneh badii
> *Sent:* Tuesday, May 16, 2017 11:23 AM
> *To:* NCSG-DISCUSS at LISTSERV.SYR. EDU <NCSG-DISCUSS at listserv.syr.edu>
> *Subject:* Re: Fw: [Internet Policy] The 2-Character Answer to this GAC
> Advice Should be "No"
>
>
>
> Hi Ayden
>
>
>
> I raised the 2-character issue and GAC involvement during our meeting with
> Markus in Copenhagen. The short answer was (my interpretation): we have to
> compromise.   I had previously raised the 2-character issue in a blog post
> and mentioned that  GAC advice was not consensus advice. Why is the Board
> acting upon it? Every time we raise some issue either we are told we don't
> know anything about the process (which I have educated myself on this to
> know) and that we have to compromise. I think arguing "we have to
> compromise" can lead to what Phil says: "Continuing down this dangerous
> path may provide governments with far more leverage over ICANN policy
> decisions"
>
>
>
> Farzaneh
>
>
> Farzaneh
>
>
>
> On Tue, May 16, 2017 at 11:05 AM, Ayden Férdeline <icann at ferdeline.com>
> wrote:
>
> Worth a read.
>
>
>
> - Ayden
>
>
>
>
>
>
>
> -------- Original Message --------
>
> Subject: [Internet Policy] The 2-Character Answer to this GAC Advice
> Should be "No"
>
> Local Time: May 16, 2017 3:43 PM
>
> UTC Time: May 16, 2017 2:43 PM
>
> From: psc at vlaw-dc.com
>
> To: ISOC policy List <internetpolicy at elists.isoc. org
> <internetpolicy at elists.isoc.org>>
>
>
>
>
>
> I have just published a new article regarding current ICANN developments
> between the Board and GAC. It can be found at http://www.circleid.com/
> posts/20170516_the_2_ character_answer_to_this_gac_ advice_should_be_no/
> <http://www.circleid.com/posts/20170516_the_2_character_answer_to_this_gac_advice_should_be_no/>
>
>
>
> Here’s the introduction—
>
> *Overview:* *ICANN’s GAC has reacted to the ICANN Board’s November 2016
> decision to authorize the release of two-character domains at new gTLDs
> with advice to the Board that does not   have true consensus backing from
> GAC members and that relates to procedure, not policy. The Board’s proper
> response should be to just say no,  stick to its decision and advise the
> GAC that it will not consider such advice.*
>
> *Instead, the Board has, against the preliminary advice of the
> policy-making GNSO Council, initiated discussions with aggrieved GAC
> members that may reopen its decision. Continuing down this dangerous path
> may provide governments with far more leverage over ICANN policy decisions
> than was ever envisioned or intended by the long debated and carefully
> crafted new Bylaws language addressing the Board’s responsibility to give
> attention to GAC advice.*
>
>
>
> I hope you find it of interest and welcome any feedback.
>
>
>
> Best regards,
>
> Philip
>
>
>
>
>
> *Philip S. Corwin, Founding Principal*
>
> *Virtualaw LLC*
>
> *1155 F Street, NW*
>
> *Suite 1050*
>
> *Washington, DC 20004*
>
> *202-559-8597/Direct*
>
> *202-559-8750/Fax*
>
> *202-255-6172/Cell*
>
>
>
> *Twitter: @VlawDC*
>
>
>
> *"Luck is the residue of design" -- Branch Rickey*
>
>
>
>
>
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ncsg.is/pipermail/ncsg-discuss/attachments/20170517/7e8fba46/attachment.htm>