<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
Dear Kavouss,<br>
just briefly: I think we <b>are</b> willing to take into account
the board's "concerns". That's what option C is actually meant for.
Adopting a dormant bylaw wasn't out initial idea, but we are trying
our best to find a compromise and to address board's concerns. All
of the board's comments are addressed if this option is adopted.<br>
Or is "addressing the concerns" means just agreeing with the
comments, disregarding the work we've done and moving everything to
the WS2?<br>
I think we all have to be willing to find a compromise, as it was
done in other areas.<br>
Concerning the past discussions: the board members were taking part
in the WP4. The concerns were different, as far as I remember. <br>
Best regards<br>
Tatiana <br>
<br>
<div class="moz-cite-prefix">On 19/01/16 10:40, Kavouss Arasteh
wrote:<br>
</div>
<blockquote
cite="mid:CACNR4-LJ-539SyvpE7qaYSZt1GgF1wCEjoY2ZiZ0fUCU0c5cag@mail.gmail.com"
type="cite">
<meta http-equiv="Content-Type" content="text/html;
charset=windows-1252">
<div dir="ltr">
<div> <font color="#000000" size="3" face="Times New Roman">
</font>
<p style="margin:0cm 0cm 10pt"><font color="#000000" size="3"
face="Calibri">Dear All,</font></p>
<font color="#000000" size="3" face="Times New Roman">
</font>
<p style="margin:0cm 0cm 10pt"><span lang="EN-US"><font
color="#000000" size="3" face="Calibri">I fully
understand the concerns raised by some of our CCWG
colleagues in regard with
the Board's recent comments on three Recs. However, at
WP4, I remember that,
Board's members expressed more or less the same
concerned but those concerns
were not taken into account when the WP4 prepared its
output.</font></span></p>
<font color="#000000" size="3" face="Times New Roman">
</font>
<p style="margin:0cm 0cm 10pt"><span lang="EN-US"><font
color="#000000" size="3" face="Calibri">That output
was discussed at CCWG and there was no reaction from the
CCWG members on the
initial Board's comments.</font></span></p>
<font color="#000000" size="3" face="Times New Roman">
</font>
<p style="margin:0cm 0cm 10pt"><span lang="EN-US"><font
color="#000000" size="3" face="Calibri">The Board
has then raised their points when commenting on CCWG 3rd
proposal and now reiterating
more or less the same concerns</font></span></p>
<font color="#000000" size="3" face="Times New Roman">
</font>
<p style="margin:0cm 0cm 10pt"><span lang="EN-US"><font
color="#000000" size="3" face="Calibri">I am of the
opinion that we need to carefully examine these
comments, if some or all are convening
we should take them into account. Those areas that we
are not convinced, we
need to enter into discussion with the Board's
representative with a view to
find an acceptable solution.</font></span></p>
<font color="#000000" size="3" face="Times New Roman">
</font>
<p style="margin:0cm 0cm 10pt"><span lang="EN-US"><font
color="#000000" size="3" face="Calibri">Should we ignore
their comments, they would submit these comments to NTIA
together with CCWG Final
proposal</font></span></p>
<font color="#000000" size="3" face="Times New Roman">
</font>
<p style="margin:0cm 0cm 10pt"><span lang="EN-US"><font
color="#000000" size="3" face="Calibri">Another
important point is that the Board is the entity that a)
will have to implement
these provisions. Should they identify any difficulties
to implement them ,we
need to examine their difficulties to minimize them that
the provisions in
question could be implementable.</font></span></p>
<font color="#000000" size="3" face="Times New Roman">
</font>
<p style="margin:0cm 0cm 10pt"><span lang="EN-US"><font
color="#000000" size="3" face="Calibri"> </font></span></p>
<font color="#000000" size="3" face="Times New Roman">
</font>
<p style="margin:0cm 0cm 10pt"><span lang="EN-US"><font
color="#000000" size="3" face="Calibri">The other
issue is should some of our output create legal
difficulties for the Board such
as involve them in obligations vis a vis other entities
with which they
contract certain action and<span> </span>the scope of
implementation of those actions by the contracting
parties <span> </span>is<span> </span>beyond
the control of the Board, then what we expect from the
Board to do.</font></span></p>
<font color="#000000" size="3" face="Times New Roman">
</font>
<p style="margin:0cm 0cm 10pt"><span lang="EN-US"><font
face="Calibri"><font size="3"><font color="#000000">CCWG
draft
many provision purely on theoretical ground and may
not have <span> </span>examined the intended or
unintended
consequences of these provisions thus the Board is
legitimately allowed to
comment on these provisions from practical
implementation view points <span> </span><span> </span></font></font></font></span></p>
<p style="margin:0cm 0cm 10pt"><span lang="EN-US"><font
face="Calibri"><font size="3"><font color="#000000"><span>Best
Regards</span></font></font></font></span></p>
<p style="margin:0cm 0cm 10pt"><span lang="EN-US"><font
face="Calibri"><font size="3"><font color="#000000"><span>Kavouss
</span></font></font></font></span></p>
<font color="#000000" size="3" face="Times New Roman">
</font></div>
</div>
<div class="gmail_extra"><br>
<div class="gmail_quote">2016-01-19 10:14 GMT+01:00 Niels ten
Oever <span dir="ltr"><<a moz-do-not-send="true"
href="mailto:lists@nielstenoever.net" target="_blank">lists@nielstenoever.net</a>></span>:<br>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">Dear
Board,<br>
<br>
I fully understand that individual board members do not
speak on behalf<br>
of the full board in the CCWG but on their own behalf, but
it greatly<br>
surprises me that when we reach agreement or even consensus
in the CCWG<br>
respectively WP4 with individual board members, that the
board comments<br>
or emails simply disregard every conversation that has been
had. This<br>
way one can simply not have a serious conversation or
negotiation.<br>
<br>
We had good discussions on this list with Markus and Bruce,
but the<br>
email of the board repeats the same arguments as given in
the comments,<br>
so it seems that all discussion with the board is pointless
and the<br>
board simply wants to push its points, but even worse, is
not willing to<br>
have a discussion based on facts, laws and examples. This is
greatly<br>
worrying me.<br>
<br>
On the list there was a range of discussions concerning
option A and<br>
option C, I think we should continue down the road of
informed and<br>
constructive discussion instead of repeating the same
arguments (which<br>
have already been addressed in bylaw language or by lawyers)
which are<br>
not helping us reach consensus, quite the opposite.<br>
<br>
Constructively yours,<br>
<br>
Niels<br>
<br>
On 01/19/2016 03:15 AM, Theresa Swinehart wrote:<br>
<<snipp><br>
><br>
> /While the Board appreciates that the proposed interim
Bylaw text is<br>
<span>> intended to not place any additional obligations
on ICANN, the language<br>
> could actually be used to greatly expand ICANN’s
human rights<br>
</span>> obligations. Some specific examples of concern
include:/<br>
><br>
> * /Inclusion of a human rights commitment in the
Bylaws would<br>
<span>> immediately allow for IRPs to be brought on
human rights grounds.<br>
> Similarly, there could be lawsuits relying on the
Bylaws language<br>
> filed against ICANN. When the Bylaws commitment
is vaguely stated,<br>
> any interpretation of the Bylaws language will be
against ICANN, and<br>
> have binding impact on the community’s ability to
define a<br>
> framework. Neither the IRP or the Courts will
have any legal reason<br>
> to wait for the community to complete the next
step, and could make<br>
</span>> their own interpretations of the
language.**/<br>
> * /The proposed Bylaws text, with reference to
“applicable law” to<br>
<span>> judge the acts of ICANN and those with
relationships with ICANN,<br>
> leaves open the question of which law should be
applicable. This<br>
> language expands, as opposed to limits, the
potential scope of human<br>
</span>> rights challenges.**/<br>
> * /The language about “any entity having a
relationship with ICANN “<br>
<span>> raises the suggestion that the ICANN Bylaws
have the power to bind<br>
> those with relationships with ICANN in how those
entities respect,<br>
> consider or enforce human rights. ICANN does not
have this power.<br>
> For example, registries and registrars contracted
with ICANN do not<br>
> take on any human rights obligations because they
contract with<br>
> ICANN. This language suggests that because they
have a relationship<br>
> with ICANN, there are human rights concerns that
they could be<br>
</span>> obligated to address.**/<br>
> * /The language suggests that there is already a
framework within<br>
<span>> which ICANN processes complaints, requests or
demands for ICANN to<br>
> enforce human rights issues, which there is not.
Indeed, there still<br>
> appears to be divergence within the community
about what should be<br>
> considered as human rights considerations within
ICANN’s Mission.<br>
> Without a framework, challenges could be raised
around issues that<br>
> are not agreed to be within ICANN’s Mission, such
as access, content<br>
</span>> or education.**/<br>
><br>
> / /<br>
><br>
> /Leaving these types of issues open puts the community,
ICANN<br>
<span>> stakeholders such as contracted parties, and
ICANN itself at risk.<br>
> Courts or binding IRP panels could be used to create
precedent defining<br>
> what human rights are within ICANN’s Mission. These
determinations are<br>
> better left for the ICANN community to sort out,
instead of being<br>
> imposed. Leaving these questions open for others
outside of the ICANN<br>
> community to define is not consistent with enhancing
ICANN’s<br>
> accountability. The Board urges that the full scope
of defined work on<br>
> human rights should include consideration of impacts
across all of<br>
</span>> ICANN’s activities./<br>
><br>
> / /<br>
<span>><br>
> As noted by ICANN’s legal counsel, the concern raised
by the Board is<br>
> not primarily about an increase in the potential
litigation across<br>
</span>> ICANN, but rather about the /impact/ of that
litigation on the ICANN<br>
<span>> community, in the potential to define ICANN’s
human rights obligations<br>
> before the community has the opportunity to complete
that work. The<br>
> proposed limitation of applicable laws does not
provide much comfort, as<br>
> there are no limitations of which laws will be
suggested to be<br>
> applicable to which parties. This is not a trivial
concern. Which<br>
> court and which law will be relied upon to decide if
human rights<br>
> includes a requirement to make all registrant data
public in an attempt<br>
> to protect against abusive content on websites? Or
which court and<br>
> which law will be relied upon to require all
registrant data to be made<br>
> private to recognize privacy interests or the
potential impact to third<br>
> parties with which ICANN does business? It is
examples such as these<br>
> that demonstrate why the ICANN community needs to
weigh in on where<br>
> ICANN’s human rights obligations start and stop,
before a court is<br>
> invited to make those determinations.<br>
><br>
><br>
><br>
</span>> *_Recommendation 7, Scope of IRP:_*<br>
<span>><br>
><br>
><br>
> The Board previously expressed concerns about the IRP
being used for<br>
> substantive appeals from process-specific expert
panels, and notes the<br>
> apparent agreement on the CCWG-Accountability to
remove the expert<br>
> appeals language from the scope of the IRP. Even
with this removal, the<br>
> Board notes that any violation of the ICANN Articles
of Incorporation or<br>
> Bylaws that occurs in conjunction with the
consideration of an expert<br>
> panel can appropriately be the basis of an IRP. The
Board has the<br>
> following additional comments:<br>
><br>
><br>
><br>
</span>> 1. The IRP should not be used to determine what
documents are to be<br>
<span>> released as part of ICANN’s Documentary
Information Disclosure<br>
> Policy (DIDP). If a DIDP response is in violation
of ICANN’s<br>
> Bylaws/AoI, then an IRP can lie on the grounds of
a Bylaws/AoI<br>
> violation. The Board notes that a more
substantive appeal process<br>
> for the DIDP could be developed as part of the
DIDP review in WS2.<br>
> The development of a substantive DIDP appeal
process was not<br>
> previously identified as a WS1 effort.<br>
><br>
><br>
><br>
</span>> 2. The Board supports the CWG-Stewardship
contingency that the IRP is<br>
<span>> made available as part of the accountability
for the performance of<br>
> the naming function work by PTI. The
implementation of this must be<br>
> done carefully so as to not confuse ICANN’s
obligations with PTI’s<br>
> obligations.<br>
><br>
><br>
><br>
</span>> 3. The Board also supports the request from the
IAB that the protocol<br>
<span>> parameters are excluded from the IRP.<br>
><br>
><br>
><br>
</span>> 4. The Board notes that there should be a broad
range of participants<br>
<span>> for the work of the IRP implementation team
(including jurists and<br>
> those versed in international arbitration).<br>
><br>
><br>
><br>
</span>> 5. The Board discourages the use of exemptions
to the already limited<br>
<span>> world of “loser pays” outcomes of IRPs, such
as a proposed exemption<br>
> for non-profit entities, as there should not be
incentive for a<br>
> certain group of complainants to more easily
bring IRPs if they are<br>
> not faced with the potential recourse for
bringing IRPs on suspect<br>
> grounds.<br>
><br>
><br>
><br>
</span>> *_Recommendation 4, Scope of Community IRP:_*<br>
><br>
> *_ _*<br>
<span class="im HOEnZb">><br>
> The Board reiterates its concerns regarding the
inclusion of expert<br>
> panel appeals and substantive DIDP appeals, as stated
in regards to<br>
> Recommendation 7.<br>
><br>
><br>
><br>
> The Board appreciates the community discussion
regarding a carve-out of<br>
> the Community IRP as it relates to PDP outcomes. The
Board notes that,<br>
> particularly with a threshold of 3 SOs or ACs, there
other potential for<br>
> the filing of a Community IRP to pit parts of the
community against<br>
> other parts of the community, such as countering the
Board’s acceptance<br>
> of advice from Advisory Committees. The Board
encourages the<br>
> CCWG-Accountability to see if there are additional
protections that can<br>
> be introduced so that community resources are not
used to challenge<br>
> properly taken actions from another part of the
community.<br>
><br>
><br>
><br>
</span><span class="im HOEnZb">>
_______________________________________________<br>
> Accountability-Cross-Community mailing list<br>
> <a moz-do-not-send="true"
href="mailto:Accountability-Cross-Community@icann.org">Accountability-Cross-Community@icann.org</a><br>
> <a moz-do-not-send="true"
href="https://mm.icann.org/mailman/listinfo/accountability-cross-community"
target="_blank" rel="noreferrer">https://mm.icann.org/mailman/listinfo/accountability-cross-community</a><br>
><br>
<br>
</span><span class="HOEnZb"><font color="#888888">--<br>
Niels ten Oever<br>
Head of Digital<br>
<br>
Article 19<br>
<a moz-do-not-send="true"
href="http://www.article19.org" target="_blank"
rel="noreferrer">www.article19.org</a><br>
<br>
PGP fingerprint 8D9F C567 BEE4 A431 56C4<br>
678B 08B5 A0F2 636D 68E9<br>
</font></span>
<div class="HOEnZb">
<div class="h5">_______________________________________________<br>
Accountability-Cross-Community mailing list<br>
<a moz-do-not-send="true"
href="mailto:Accountability-Cross-Community@icann.org">Accountability-Cross-Community@icann.org</a><br>
<a moz-do-not-send="true"
href="https://mm.icann.org/mailman/listinfo/accountability-cross-community"
target="_blank" rel="noreferrer">https://mm.icann.org/mailman/listinfo/accountability-cross-community</a><br>
</div>
</div>
</blockquote>
</div>
<br>
</div>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
Accountability-Cross-Community mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Accountability-Cross-Community@icann.org">Accountability-Cross-Community@icann.org</a>
<a class="moz-txt-link-freetext" href="https://mm.icann.org/mailman/listinfo/accountability-cross-community">https://mm.icann.org/mailman/listinfo/accountability-cross-community</a>
</pre>
</blockquote>
<br>
</body>
</html>