<html>
<body>
At 01:55 PM 11/30/2015, Burr, Becky wrote:<br>
<blockquote type=cite class=cite cite="">First, we discussed this on
several calls (3 or 4), including the last. <br>
Second, on a more substantive note, it is completely absurd to suggest
that grandfathering the <i>language</i> of existing contracts permits
ICANN to enforce any contract term in any way it likes and to claim the
protection of the picket fence forever going forward.&nbsp; Simply put,
the drafters are instructed to ensure that the provisions of existing
contracts are enforceable by their terms.&nbsp; As I said on this very
topic recently: <br>
<blockquote type=cite class=cite cite=""><font face="Calibri">Beyond
that, the language of 3.18 in question imposes obligations on
<i>registrars</i> – maintain ann abuse point of contact, investigate
allegations regarding illegal activities, take appropriate action, so I
don’t think that amounts to regulating registrants.&nbsp; I also agree
that there are situations in which illegal activity could impact the
stability and security of the Internet’s unique identifiers (e.g.,
particularly involving malicious DNS exploits, etc.), so the provision
seems to me to be appropriate in furtherance of ICANN’s Mission.&nbsp;
<br>
</font><br>
<font face="Calibri">The problem, of course, is that not all illegal
activity threatens the stability and security of the DNS; behavior that
is illegal in some jurisdictions is not illegal in all
jurisdictions;&nbsp; and the legality/illegality of a particular activity
is generally a determination left to sovereigns or courts.&nbsp; So, what
constitutes an â€ś appropriate response” is going to vary from case to
case. <i> Theoretically, ICANN could choose to enforce the requirement in
a manner that exceeded the scope of its authority, e.g., it could begin
to say that registrars who do not suspend registrations in response to
allegations that an underlying site is defamatory are in
breach</i>.&nbsp; But I think 3.18 itself is a legitimate contract
provision that ICANN should be able to
enforce.</font></blockquote><b></b></blockquote><br>
But that's the problem, right there.&nbsp; You say that if ICANN
&quot;exceeds the scope of its authority&quot; if it &quot;begins to say
that registrars who do not suspend registrations in response to
allegations that an underlying site is defamatory are in
breach.&quot;<br><br>
But why is it so obvious that this exceeds the scope of its
authority?&nbsp; You will say:&nbsp; because we have said elsewhere that
ICANN shall not regulate content, and this regulates content.<br><br>
But it is not far-fetched for someone to suggest that the
&quot;grandfathering&quot; language modifies that, and was included
precisely to make it clear that enforcing the provisions of existing
agreements is WITHIN ICANN's authority.&nbsp; Under existing agreements,
Registrars are already obligated to provide &quot;consequences ...
including suspension of domain name registrations&quot; for
&quot;activities contrary to applicable law.&quot;&nbsp; Defamation is an
&quot;activity contrary to applicable law.&quot;&nbsp; Suspending
registrations in response to allegations that an underlying site is
defamatory is thus within the scope of (existing) agreements.&nbsp; If
those agreements are grandfathered in, it looks to me like we're saying
that when ICANN acts as it is authorized to do within the existing
agreements, it is acting within the scope of its authority. <br><br>
David<br><br>
<br><br>
<br><br>
<blockquote type=cite class=cite cite=""><b>J. Beckwith Burr <br>
Neustar, Inc. </b>/<b> </b>Deputy General Counsel &amp; Chief Privacy
Officer<br>
1775 Pennsylvania Avenue NW, Washington D.C. 20006<br>
<b>Office: </b>+1.202.533.2932&nbsp; <b>Mobile: </b>+1.202.352.6367
<b>/</b> <a href="http://www.neustar.biz"><b>neustar.biz</a><br>
</b><br>
From: David Post
&lt;<a href="mailto:david.g.post@gmail.com">david.g.post@gmail.com</a>
&gt;<br>
Date: Monday, November 30, 2015 at 1:32 PM<br>
To: Accountability Community
&lt;<a href="mailto:accountability-cross-community@icann.org">
accountability-cross-community@icann.org</a>&gt;<br>
Cc: &quot;NCSG-DISCUSS-LISTSERV.SYR.EDU&quot;
&lt;<a href="mailto:NCSG-DISCUSS@LISTSERV.SYR.EDU">
NCSG-DISCUSS@LISTSERV.SYR.EDU</a>&gt;, Thomas Rickert
&lt;<a href="mailto:thomas@rickert.net">thomas@rickert.net</a>&gt;,
Accountability Community
&lt;<a href="mailto:accountability-cross-community@icann.org">
accountability-cross-community@icann.org</a>&gt;<br>
Subject: Re: [CCWG-ACCT] Minority statements inclusion in report<br><br>
<br>
The current Proposal (Annex 5 para 21) states in a
&quot;Note&quot;:&nbsp; &quot;For the avoidance of uncertainty, the
language of existing registry agreements and registrar accreditation
agreements should be grandfathered.&quot;<br><br>
I don't believe any of the previous circulated drafts contained this
language, and in my opinion it represents a very serious, and very
substantial, step backwards in this process.&nbsp; <br><br>
To begin with, it is not clear what &quot;grandfathering&quot; these
agreements mean.&nbsp; One possible implication is that everything within
the existing agreements is within ICANN's Mission - or to put it
differently, that the language of the Mission Statement should be
interpreted in a manner such that all provisions of the existing
agreements are inside the &quot;picket fence&quot; of ICANN's enumerated
powers. The opposite implication is possible, too - that there are
elements of the existing agreements that are NOT within the Mission, but
which are nonetheless being &quot;grandfathered&quot; in so that they
will not be invalidated in the future (notwithstanding their
inconsistency with the Mission).<br><br>
I believe that the former interpretation may be the one that is intended
- and I strongly disagree with that, and strongly dissent. The existing
agreements contain a number of provisions that are outside the scope of
ICANN's powers as we have defined it in the Mission Statement.&nbsp; One
most prominent example:&nbsp; In Specification 1 of the new gTLD Registry
Agreement, Registry operators agree to a set of mandatory &quot;public
interest commitments&quot; - PICs - and to adhere to &quot;any remedies
ICANN imposes (which may include any reasonable remedy, including for the
avoidance of doubt, the termination of the Registry Agreement pursuant to
Section 4.3(e) of the Agreement) following a determination by any PICDRP
panel and to be bound by any such determination.&quot;<br><br>
Among the mandatory PICs, the Registry operator must &quot;include a
provision in its Registry-Registrar Agreement that requires Registrars to
include in their Registration Agreements a provision prohibiting
Registered Name Holders from ... engaging in activity contrary to
applicable law, and providing (consistent with applicable law and any
related procedures) consequences for such activities including suspension
of the domain name.&quot;<br><br>
Prohibiting domain name holders from &quot;engaging in activity contrary
to applicable law&quot; is NOT within ICANN's scope as defined in the
Mission Statement.&nbsp; It is neither a matter &quot;for which uniform
or coordinated resolution is reasonably necessary to facilitate the
openness, interoperability, resilience, security and/or stability of the
DNS,&quot; nor was it &quot;developed through a bottom-up,
consensus-based multi-stakeholder process and designed to ensure the
stable and secure operation of the Internet’s unique names
systems.&quot;<br><br>
<i>ICANN should not have the power to revoke, or to impose on others the
requirement that they revoke, anyone's continued use of a domain name
because they have &quot;engaged in activity contrary to applicable
law.&quot;&nbsp; </i>Such a provision would appear to allow ICANN to do
what is, elsewhere, flatly prohibited: to impose regulations on
content.&nbsp; Activity contrary to applicable law includes activity that
(a) violates consumer protection law, (b) infringes copyright, (c)
violates anti-fraud laws, (d) infringes trademarks, (e) violates relevant
banking or securities laws, etc. etc. etc.&nbsp; At best, this provision
is flatly inconsistent with the prohibition against regulating
content.&nbsp; At worst, it can be interpreted to provide an
&quot;exception&quot; to that prohibition - an exception that will
swallow up the prohibition in its entirety.&nbsp; <br><br>
David<i> <br><br>
</i>At 10:53 AM 11/30/2015, Mueller, Milton L wrote:<br>
<blockquote type=cite class=cite cite="">FWIW, Robin’s dissent nt is
fully in line with the official comments submitted by the Noncommercial
Stakeholders Group during the last public comment period. <br>
--MM<br>
&nbsp;<br>
<b>From:</b>
<a href="mailto:accountability-cross-community-bounces@icann.org">
accountability-cross-community-bounces@icann.org</a> [
<a href="mailto:accountability-cross-community-bounces@icann.org" eudora="autourl">
mailto:accountability-cross-community-bounces@icann.org</a>] <b>On Behalf
Of </b>Robin Gross<br>
<b>Sent:</b> Sunday, November 29, 2015 6:41 PM<br>
<b>To:</b> Thomas Rickert<br>
<b>Cc:</b>
<a href="mailto:accountability-cross-community@icann.org">
accountability-cross-community@icann.org</a> Community<br>
<b>Subject:</b> Re: [CCWG-ACCT] Minority statements inclusion in
report<br>
&nbsp;<br>
Thanks, Thomas.&nbsp; See below.<br>
&nbsp;<br>
<b>Dissenting Opinion of Member Robin Gross (GNSO-NSCG)<br>
</b>&nbsp;<br>
The CCWG-Accountability make a number of helpful recommendations to
improve organizational accountability at ICANN, however one aspect of the
plan is deeply flawed: changing the role of ICANN's Governmental Advisory
Committee (GAC) from purely an Ă˘€śadvisory” role to a Ă˘€
“decision making” role over fundamental matterers at ICANN,
including its governance.&nbsp; Consequently the proposal marginalizes
the role of Supporting Organizations (SO’s) compared to today’s
ICANN goveNN governance structure.&nbsp; The degree of governmental
empowerment over ICANN resulting from the proposal’s cs community
mechanism is dangerous to the success of the proposal’s political
acceptance as well as to its ultultimate impact on a free and open
Internet.<br>
&nbsp;<br>
The creation of a community mechanism to hold ICANN accountable on key
issues made a critical error by departing from the existing power balance
between SO’s and nd AC’s as determined by relative board
appointments.ts.&nbsp; Instead, the proposed community mechanism elevates
the AC’s relative to the SO’s compared wpared with today’s
balance on ICANN's board of directors,rs, which does not currently
provide a decision making role to GAC, and which retains the primacy of
the Supporting Organizations on key decisions, particularly those within
the SO’s mandate.&nbsp;&nbsp; The devaluing of tf the Supporting
Organizations in ICANN’s key decisiosions was a common theme in both
previous public comment periods, however the recommendations not only
failed to address this widespread concern, but went even further in
devaluing SO’s in the community mechanism in the 3r 3rd report.&nbsp;
The community mechanism failed to take into account the appropriate roles
and responsibilities of the various SO’s and AC’s, and the dangers
angers inherent in changing those roles with a Ă˘€śone sizeze fits
all” approach to critical decision makingg.&nbsp; <br>
&nbsp;<br>
Additionally, I object to the proposed departure from ICANN’s typical
30-day publublic comment period on the 3rd report for
CCWG-Accountability.&nbsp; The 3rd report’s public comment only
allallows for 9 days of public comment after the language translations
are scheduled to be published, which is far too short of a public comment
period for a report of this significance and with so many important
changes since previous drafts.<br>
&nbsp;<br>
Robin Gross<br>
&nbsp; 
<dl>
<dd>On Nov 29, 2015, at 1:29 PM, Thomas Rickert
&lt;<a href="mailto:thomas@rickert.net">thomas@rickert.net</a>&gt; wrote: 
<dd>&nbsp; 
<dd>Dear Robin, 
<dd>as discussed during the last CCWG call, minority statements will be
included in the report as appendices if and when they are received. 
<dd>&nbsp; 
<dd>Best, 
<dd>Thomas 
<dd>&nbsp; 
<dd>--- 
<dd>
<a href="https://urldefense.proofpoint.com/v2/url?u=http-3A__rickert.net_&amp;d=CwMFAw&amp;c=MOptNlVtIETeDALC_lULrw&amp;r=62cJFOifzm6X_GRlaq8Mo8TjDmrxdYahOP8WDDkMr4k&amp;m=Qv0jYqBGBpDcX5hfJBnWctfriZdKXCzPTTlEhjSanvQ&amp;s=9_5YAupJwVm6qd9FYkcvB50XsN6XMpB3eFmtm-kYBKI&amp;e=">
rickert.net</a>
<dd>&nbsp; 
<dd>Am 29.11.2015 um 21:37 schrieb Robin Gross
&lt;<a href="mailto:robin@ipjustice.org">robin@ipjustice.org</a>&gt;: 
<dl>
<dd>Dear Co-Chairs, 
<dd>I have still not received a response to this request.&nbsp; What is
the process for submitting minority statements?&nbsp; Please advise. 
<dd>Thanks, 
<dd>Robin<br>
<br>
<br><br>

<dl>
<dd>On Nov 11, 2015, at 5:35 PM, Robin Gross
&lt;<a href="mailto:robin@ipjustice.org">robin@ipjustice.org</a>&gt;
wrote: 
<dd>&nbsp; 
<dd>Dear Co-Chairs, 
<dd>&nbsp; 
<dd>Could you please advise on the proposed schedule and process for
ensuring that minority statements will be included in the report [of the
executive summary]? 
<dd>&nbsp; 
<dd>Thank you, 
<dd>Robin 
<dd>_______________________________________________ 
<dd>Accountability-Cross-Community mailing list
<dd><a href="mailto:Accountability-Cross-Community@icann.org">
Accountability-Cross-Community@icann.org</a><br><br>

<dd>
<a href="https://mm.icann.org/mailman/listinfo/accountability-cross-community" eudora="autourl">
https://mm.icann.org/mailman/listinfo/accountability-cross-community</a>
<br><br>

</dl>
<dd>&nbsp;<br><br>
</dl>
</dl>&nbsp;<br>
_______________________________________________<br>
Accountability-Cross-Community mailing list<br>
<a href="mailto:Accountability-Cross-Community@icann.org">
Accountability-Cross-Community@icann.org</a><br>
<a href="https://mm.icann.org/mailman/listinfo/accountability-cross-community" eudora="autourl">
https://mm.icann.org/mailman/listinfo/accountability-cross-community</a>
</blockquote><br>
*******************************<br>
David G Post - Senior Fellow, Open Technology Institute/New America
Foundation<br>
blog (Volokh Conspiracy)
<a href="http://www.washingtonpost.com/people/david-post" eudora="autourl">
http://www.washingtonpost.com/people/david-post</a><br>
book (Jefferson's Moose)&nbsp;
<a href="http://tinyurl.com/c327w2n%A0%A0%A0%A0" eudora="autourl">
http://tinyurl.com/c327w2n&nbsp;&nbsp;&nbsp; </a> <br>
music
<a href="http://tinyurl.com/davidpostmusic" eudora="autourl">
http://tinyurl.com/davidpostmusic</a> publications etc.&nbsp;
<a href="http://www.davidpost.com      /" eudora="autourl">
http://www.davidpost.com&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </a> <br>
******************************* </blockquote><br>
*******************************<br>
David G Post - Senior Fellow, Open Technology Institute/New America
Foundation<br>
blog (Volokh Conspiracy)
<a href="http://www.washingtonpost.com/people/david-post" eudora="autourl">
http://www.washingtonpost.com/people/david-post<br>
</a>book (Jefferson's Moose)&nbsp;
<a href="http://tinyurl.com/c327w2n%A0%A0%A0%A0%A0%A0%A0" eudora="autourl">
http://tinyurl.com/c327w2n&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </a> <br>
music
<a href="http://tinyurl.com/davidpostmusic%A0" eudora="autourl">
http://tinyurl.com/davidpostmusic </a> publications etc.&nbsp;
<a href="http://www.davidpost.com         /" eudora="autourl">
http://www.davidpost.com&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
</a> <br>
******************************* </body>
</html>