<html>
<head>
<meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<p>
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
</p>
<p>Thank you Greg.</p>
<p>I would like to second one more point that is expressed so
clearly by Greg: that the new language is trying to change post
factum the reality, which is: we didn't reach consensus on the
suitability of Ruggie. This is clearly expressed in the FoI (and
we are still recommending Ruggie!), and this can not be changed
unilaterally. Moreover, for many of us this was an important fact
to express in the FoI to eliminate any risks of misinterpretation.
Changing this will water down this important part of the FoI,
create contradictions in what we propose and might bring back all
the concerns we expressed about the risks.</p>
<p>The proposed language cannot be discussed without bringing back
discussion about Ruggie, risks, etc in full.</p>
<p>The current FoI language already mentions Ruggie and suggests to
use them if appropriate. The FoI leaves it to SO/ACs to further
apply the Core value in accordance with their processes. This
stance leaves those submitting the dissenting opinion - as it is
only GAC members - to bring more Ruggie during the GAC application
of the core value, if there is a strong belief that such
application is necessary.</p>
<p>We do not have the absence of any reference to Ruggie in the
current FoI text. I do not see how Ruggie principles are
discriminated in the current language compare to what is proposed.
I don't see clearly how the proposed text is going to reinforce
what is <b>already</b> being in the FoI about Ruggie. However, I
clearly see how a "little bit more Ruggie" will break the current
balance.</p>
<p>If we are going to change the text, we need to add all the
qualifying clauses as proposed by Greg. I would fully support
this. <br>
</p>
<p>Warm regards,</p>
<p>Tanya </p>
<br>
<div class="moz-cite-prefix">On 03/10/17 17:05, Greg Shatan wrote:<br>
</div>
<blockquote
cite="mid:CA+aOHURTghLQYDJJB_CcUNRZ9bHK2BNM_wUaEku-CzCB3Q-eYA@mail.gmail.com"
type="cite">
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
<div dir="ltr">
<div class="gmail_default"
style="font-family:verdana,sans-serif">Like Tatiana, I share
the concerns that Anne and Matthew expressed. It also seems
necessary to clarify that the proposed new language would
change the <b>FoI</b> itself, advocating the use of Ruggie to
interpret the Bylaw. The Considerations, which would not be
changed under this proposal, stand in direct conflict to that
stance:</div>
<div class="gmail_default"
style="font-family:verdana,sans-serif"><br>
</div>
<blockquote style="margin:0px 0px 0px
40px;border:none;padding:0px">
<div class="gmail_default">
<div class="gmail_default"><font face="verdana, sans-serif">With
regards to the UN Guiding Principles for Business and
Human Rights, <b>no consensus was reached as to their
suitability for interpreting the Core Value</b>.
However with regard to the implementation of the Core
Value <b>certain aspects of the UN Guiding Principles
for Business and Human Rights could be considered</b>
as a useful guide in the process of applying the Human
Rights Core Value. There are <b>certain Guiding
Principles that may not be suitable for ICANN</b> and
others that might be applicable, depending on the
circumstances. However, it is beyond the scope of this
document to provide a detailed analysis of the Guiding
Principles and their application, or not, in particular
situations. </font><span
style="font-family:verdana,sans-serif">(emphasis added)</span></div>
</div>
</blockquote>
<blockquote style="margin:0px 0px 0px
40px;border:none;padding:0px">
<div class="gmail_default">
<div class="gmail_default"><font face="verdana, sans-serif"><br>
</font></div>
</div>
</blockquote>
<font face="verdana, sans-serif">
<div class="gmail_default"
style="font-family:verdana,sans-serif;display:inline">The
Considerations document even expressly recognizes the
likelihood of conflicts between Ruggie and the ICANN
Bylaws:</div>
<br>
</font>
<blockquote style="margin:0px 0px 0px
40px;border:none;padding:0px">
<div class="gmail_default">
<div class="gmail_default"><font face="verdana, sans-serif"> </font></div>
</div>
</blockquote>
<blockquote style="margin:0px 0px 0px
40px;border:none;padding:0px">
<div class="gmail_default">
<div class="gmail_default"><font face="verdana, sans-serif">In
any case, a conflict between any Guiding Principle and
an ICANN Bylaw provision or Article of Incorporation
must be resolved in favor of the Bylaw or Article. The
use of the Guiding Principles as potential guidance has
to be carefully considered by each SO and AC as well as
ICANN the organization. </font></div>
</div>
</blockquote>
<div class="gmail_default">
<div class="gmail_default"
style="font-family:verdana,sans-serif"><br>
</div>
</div>
<div class="gmail_default"
style="font-family:verdana,sans-serif">For purposes of clarity
(which is the purpose of the FoI), any reference to the UNGP
in the Bylaws should be appropriately qualified to align it
with the Considerations document and to avoid conflict with
the HR Bylaw itself. The follow caveat would provide the
necessary aid to using Ruggie to interpret the Bylaw:</div>
<div class="gmail_default"
style="font-family:verdana,sans-serif"><br>
</div>
<blockquote style="margin:0px 0px 0px
40px;border:none;padding:0px">
<div class="gmail_default"
style="font-family:verdana,sans-serif">
<div class="gmail_default"
style="font-family:arial,sans-serif;font-size:12.8px"><b><i><font
face="verdana, sans-serif">Any consideration of the
UNGP in interpreting the Bylaw must be expressly
limited by </font></i><i style="font-size:12.8px"><font
face="verdana, sans-serif">(a) the fact that there
is "no consensus" on the UNGP's "suitability for
interpreting the Core Value", </font></i><i
style="font-size:12.8px"><font face="verdana,
sans-serif">(b) the Bylaw's limitation to
"applicable law," (c) the Bylaw's injunction that it
cannot be used to "obligate ICANN to enforce its
human rights obligations or the other human rights
obligations of other parties, against other parties,
(d) guidance that only "certain aspects" of the UNGP
"might be applicable" while others "may not be
suitable for ICANN", (e) the recognition that there
are conflicts between the UNGP and the Bylaw, and
that "a conflict between any Guiding Principle and
an ICANN Bylaw provision or Article of Incorporation
must be resolved in favor of the Bylaw or Article,"
and (f) the understanding that the UNGP only applies
to ICANN, if at all, in the context of ICANN the
organization's activities as a "business" and not in
its sui generis mission "t</font><span
style="font-family:verdana,sans-serif">o ensure the
stable and secure operation of the Internet's unique
identifier systems" and to adopt policies, enter
into contracts and allocate DNS resources in
connection with that mission. </span></i></b></div>
</div>
<div class="gmail_default"
style="font-family:verdana,sans-serif">
<div class="gmail_default"
style="font-family:arial,sans-serif;font-size:12.8px"><font
face="verdana, sans-serif"> (Quoted language from the
ICANN Bylaws and the "Considerations" accompanying this
Framework of Interpretation.)</font></div>
</div>
</blockquote>
<div class="gmail_default"
style="font-family:verdana,sans-serif"><br>
</div>
<div class="gmail_default"
style="font-family:verdana,sans-serif">This would avoid
ambiguity and conflict between the Bylaw, the FoI, the
document being suggested to interpret the Bylaw (i.e., the
UNGP), and the underlying considerations taken into account in
creating the FoI.</div>
<div class="gmail_default"
style="font-family:verdana,sans-serif"><br>
</div>
<div class="gmail_default"
style="font-family:verdana,sans-serif">It occurs to me that if
we adopted the proposed language in the FOI, we would need to
insert language in the "Considerations" to reflect the
proposal's limiting language, e.g.:</div>
<div class="gmail_default"
style="font-family:verdana,sans-serif"><br>
</div>
<blockquote style="margin:0 0 0 40px;border:none;padding:0px">
<div class="gmail_default"
style="font-family:verdana,sans-serif"><b
style="font-family:"Times New
Roman",serif;font-size:16px;text-align:justify"><i><span
style="font-size:11pt;font-family:Arial,sans-serif;color:red"
lang="EN-US">The UNGP are relevant for business
organizations, and should be applied in that context.
To the extent that ICANN the Organization is a
business, it should consider, as a business, certain
aspects of the UNGP as a useful guide when applying
the Human Rights Core Value.</span></i></b></div>
<div class="gmail_default"
style="font-family:verdana,sans-serif"><b
style="font-family:"Times New
Roman",serif;font-size:16px;text-align:justify"><i><span
style="font-size:11pt;font-family:Arial,sans-serif;color:red"
lang="EN-US"><br>
</span></i></b></div>
</blockquote>
<font face="Arial, sans-serif" color="#000000">
<div class="gmail_default"
style="font-family:verdana,sans-serif;display:inline"><i
style="font-size:14.6667px;font-weight:bold"></i>This
raises other concerns. The Human Rights Bylaw is intended
as a "floor" and not a "ceiling." ICANN the Organization
and the Community can always choose to do more than the
Bylaw dictates (within ICANN's remit, of course). The more
we use language of limitation, the more we leave the
impression that ICANN (the Organization, the Community and
the "ecosystem") cannot voluntarily go beyond the strictures
of the Bylaw. That would be counterproductive.</div>
<br>
</font>
<div><font face="Arial, sans-serif" color="#000000">
<div class="gmail_default"
style="font-family:verdana,sans-serif;display:inline"><br>
</div>
</font></div>
<div><font face="Arial, sans-serif" color="#000000">
<div class="gmail_default"
style="font-family:verdana,sans-serif;display:inline">The
HR subgroup in WS2 was tasked with creating the FoI and
taking certain "considerations" into account. It was not
within our remit to create a roadmap for the voluntary
adoption of Human Rights principles, whether culled from
Ruggie or otherwise. I understand that some might want to
use the power of the Bylaw to force voluntary compliance
(that's an oxymoron....), or to turn voluntary compliance
into Bylaws-mandated compliance. I don't support that.
But neither do I want this effort to limit or appear to
limit, in any way, the ability of ICANN (however defined)
and its various structures to debate, consider and adopt,
in ways that they find best, methods to respect Human
Rights.</div>
</font></div>
<div><font face="Arial, sans-serif" color="#000000">
<div class="gmail_default"
style="font-family:verdana,sans-serif;display:inline"><br>
</div>
</font></div>
<div><font face="Arial, sans-serif" color="#000000">
<div class="gmail_default"
style="font-family:verdana,sans-serif;display:inline">Greg</div>
</font></div>
</div>
<div class="gmail_extra"><br>
<div class="gmail_quote">On Tue, Oct 3, 2017 at 7:47 AM, Matthew
Shears <span dir="ltr"><<a moz-do-not-send="true"
href="mailto:matthew@intpolicy.com" target="_blank">matthew@intpolicy.com</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<div text="#000000" bgcolor="#FFFFFF">
<p>As Anne, I would like to know both the procedure and
justification for "new language being proposed at the
plenary level with no prior consideration of that
language at the subgroup"?<br>
</p>
I also do not understand why we are characterizing the
positions as "Zero Ruggie" or " All Ruggie". As Anne
notes, "David McCauley is quite right that not all Ruggie
principles make sense for ICANN since it is not a typical
"business" and its mission is limited, especially as to
not interfering with content. Much of what is contained
in Ruggie Principles seeks to reach "all business
relationships" and would thus exert influence over
content, i.e. Ruggie would no doubt require putting
provisions in Registry Agreements and Registrar Agreements
that change obligations of these contracted parties to
exert influence over registrants regarding Human Rights
principles. ... In the ICANN environment, following all
Ruggie principles creates too broad a sweep by far."
These points were made in the sub-group discussions and on
the lists on numerous occasions. And the work of the
sub-group is not Zero Ruggie - this is a
mis-characterization.<br>
<br>
I also do not believe that it is appropriate to rewrite
the “Considerations” document is at the plenary level.
The considerations document as it stands - and agreed by
the sub group - should provide all that is needed in terms
of references to Ruggie.<br>
<br>
Matthew
<div>
<div class="h5"><br>
<br>
<div class="m_2260752928253482286moz-cite-prefix">On
02/10/2017 20:54, Aikman-Scalese, Anne wrote:<br>
</div>
<blockquote type="cite">
<div class="m_2260752928253482286WordSection1">
<p class="m_2260752928253482286MsoPlainText">Thomas
et al,</p>
<p class="m_2260752928253482286MsoPlainText">What
I am trying to understand is the procedure
involved with new language being proposed at the
plenary level with no prior consideration of
that language at the subgroup. I had made
specific proposals to include certain Ruggie
language at the subgroup level with specific
reference to incorporating Ruggie Principle 18
into the language that is applicable to ICANN
the organization. (In fact, I have been
advocating reference to Ruggie 18(b) from the
beginning of participating in WS2-Human
Rights.) So if we are considering new language
at the plenary, I want to throw in my own
recommendation that we refer specifically to
Ruggie Principle 18 as a compromise position.</p>
<p class="m_2260752928253482286MsoPlainText"> </p>
<p class="m_2260752928253482286MsoPlainText">I do
not understand this black and white FACE-OFF as
to "Zero Ruggie" or " All Ruggie". David
McCauley is quite right that not all Ruggie
principles make sense for ICANN since it is not
a typical "business" and its mission is limited,
especially as to not interfering with content.
Much of what is contained in Ruggie Principles
seeks to reach "all business relationships" and
would thus exert influence over content, i.e.
Ruggie would no doubt require putting provisions
in Registry Agreements and Registrar Agreements
that change obligations of these contracted
parties to exert influence over registrants
regarding Human Rights principles. While this
may be appropriate for a voluntary Public
Interest Commitment on the part of a registry,
it is certainly not appropriate as a “top-down”
ICANN org policy. In the ICANN environment,
following all Ruggie principles creates too
broad a sweep by far. In addition, there is no
other "business" that has used Ruggie that
follows the multi-stakeholder bottom-up policy
process, a process unique to ICANN. </p>
<p class="m_2260752928253482286MsoPlainText"> </p>
<p class="m_2260752928253482286MsoPlainText">Mark
Carvell got the WS2 drafting team on a call at
one ICANN meeting with someone from the UN (with
experience implementing Ruggie) and I
specifically asked whether she had experience
implementing Ruggie with an organization that
operated on the bottom-up Multi-Stakeholder
Model. Jorge Cancio was also in the room on
this call and asked several questions. Her
response was (and I paraphrase) "No, but ICANN
is a quasi-governmental organization and has a
lot of power to influence Human Rights going
forward". So for anyone who feels that ICANN is
a quasi-governmental organization, they will
push ICANN the organization in this direction
without remembering the applicable law
limitation and the fact that ICANN is NOT A
QUASI-GOVERNMENTAL organization and its policy
development is not the top-down process followed
by other non-profits.</p>
<p class="m_2260752928253482286MsoPlainText"> </p>
<p class="m_2260752928253482286MsoPlainText">Certain
Ruggie Principles may work well within the
limited mission of ICANN, most notably Principle
18, shown below my signature. Others, as
pointed out in a very thoughtful manner by David
McCauley's post to the WS 2 HR list, are
dangerous and would impose limits on content as
well as increased difficulty in enforcing
property rights (including Intellectual Property
rights) which are not consistent with Human
Rights. While I may strongly disagree with
certain views that could be posted at second
level domains, ICANN is not the place to try to
regulate them. And I disagree with the
proposition that there should be an absolute
right to post anonymously on the Internet as
advocated by Article 19. (Although I agree that
monitoring “hate speech” is a very dangerous
road to go down.) It seems to me the highest
principle here is disclosure, in other words,
“Consider the Source”.</p>
<p class="m_2260752928253482286MsoPlainText"> </p>
<p class="m_2260752928253482286MsoPlainText">Regarding
the Human Right to privacy, recently it was
noted that the Russian government may have been
the true force and money behind several Facebook
ads attempting to influence U.S. elections. So
now Facebook is cooperating to try to prevent
that. Why? Because people should know the bias
associated with statements when there is no
"fact check" in place. There is also no "fact
check" on content posted at second level domains
and these are now “unlimited” in many
respects. Shouldn't people know where these
opinions are coming from even if it's not the
Russian government? What if it's Breitbart?
How should these concerns be balanced with the
right to privacy of the individual?
(Organizations can easily use individuals to
post ads and advocate opinions. In addition,
who decides whether an association of
individuals who believe similarly would have no
right to privacy?) Which second level domains
were being used to influence US elections and do
the registrants have a right to privacy for
everything said on those domains as well? Does
it also apply to everything they sell on the
domain to raise money to place their Facebook
ads? T-shirts? Coins? Hats? I would say,
“Consider the Source” in all cases. And be
concerned as to why the source does not want to
disclose itself. Take that into account. Is it
for nefarious purposes or is it for legitimate
fear of unjust consequences – e.g. second level
registrations at .gay?</p>
<p class="m_2260752928253482286MsoPlainText"> </p>
<p class="m_2260752928253482286MsoPlainText">As an
organization, ICANN should not overreact to
Snowden and to unjust laws in "outlier"
governments. Failure to balance privacy rights
with other considerations related to policies
that develop trust and confidence in the
worldwide web will not only result in consumer
harm, it could even throw elections. "Consider
the Source" is the best adage for both opinions
and products offered on the Internet. This
does not mean that the Spanish government should
be able to shut down .cat, in fact it means the
opposite. Governments who stand for free speech
and privacy (and the legal systems established
by those governments) should be protecting and
enforcing those rights. </p>
<p class="m_2260752928253482286MsoPlainText"> </p>
<p class="m_2260752928253482286MsoPlainText">If
the “Considerations” document is now open to
rewriting at the plenary level, then shouldn't
we be considering other alternative proposals
that were rejected by the drafting team? The
most important Ruggie Principle for faithfulness
to the ICANN bottom-up Multi-Stakeholder model
appears below my signature, that is Ruggie
Principle 18. As this discussion is being
developed further in the plenary, please keep in
mind that Ruggie calls for a Grievance Procedure
and that the Core Value itself contemplates both
a Request for Reconsideration and an Independent
Review Panel process in relation to Human Rights
claims.</p>
<p class="m_2260752928253482286MsoPlainText"> </p>
<p class="m_2260752928253482286MsoPlainText">Anne</p>
<p class="m_2260752928253482286MsoPlainText"> </p>
<p class="MsoNormal"> </p>
<table class="m_2260752928253482286MsoNormalTable"
style="border-collapse:collapse" border="0"
cellpadding="0" cellspacing="0">
<tbody>
<tr>
<td style="width:3.5in;padding:0in 5.4pt 0in
5.4pt" valign="top" width="336">
<p class="MsoNormal"><b><span
style="font-size:9.0pt;font-family:"Arial","sans-serif";color:#af272f">Anne
E. Aikman-Scalese</span></b></p>
</td>
</tr>
<tr>
<td style="width:3.5in;padding:0in 5.4pt 0in
5.4pt" valign="top" width="336">
<p class="MsoNormal"><span
style="font-size:9.0pt;font-family:"Arial","sans-serif";color:#323232">Of
Counsel</span></p>
</td>
</tr>
<tr>
<td style="width:3.5in;padding:0in 5.4pt 0in
5.4pt" valign="top" width="336">
<p class="MsoNormal"><span
style="font-size:9.0pt;font-family:"Arial","sans-serif";color:#323232"><a
moz-do-not-send="true"
href="tel:%28520%29%20629-4428"
value="+15206294428" target="_blank">520.629.4428</a>
office</span></p>
</td>
</tr>
<tr>
<td style="width:3.5in;padding:0in 5.4pt 0in
5.4pt" valign="top" width="336"><br>
</td>
</tr>
<tr>
<td style="width:3.5in;padding:0in 5.4pt 0in
5.4pt" valign="top" width="336">
<p class="MsoNormal"><span
style="font-size:9.0pt;font-family:"Arial","sans-serif";color:#323232"><a
moz-do-not-send="true"
href="tel:%28520%29%20879-4725"
value="+15208794725" target="_blank">520.879.4725</a>
fax</span></p>
</td>
</tr>
<tr>
<td style="width:3.5in;padding:0in 5.4pt 0in
5.4pt" valign="top" width="336">
<p class="MsoNormal"><a
moz-do-not-send="true"
href="mailto:AAikman@lrrc.com"
title="Email User" target="_blank"><span
style="font-size:9.0pt;font-family:"Arial","sans-serif";color:#323232">AAikman@lrrc.com</span></a></p>
</td>
</tr>
<tr>
<td style="width:3.5in;padding:0in 5.4pt 0in
5.4pt" valign="top" width="336">
<p class="MsoNormal"><span
style="font-size:9.0pt;font-family:"Arial","sans-serif";color:#323232">_____________________________</span></p>
</td>
</tr>
<tr>
<td style="width:3.5in;padding:0in 5.4pt 0in
5.4pt" valign="top" width="336">
<p class="MsoNormal"><span
style="font-size:9.0pt;font-family:"Arial","sans-serif""><img
id="m_2260752928253482286Picture_x0020_1"
src="cid:part5.472BD0BD.00509889@mpicc.de"
height="46" border="0" width="115"></span></p>
</td>
</tr>
<tr>
<td style="width:3.5in;padding:0in 5.4pt 0in
5.4pt" valign="top" width="336">
<p class="MsoNormal"><span
style="font-size:9.0pt;font-family:"Arial","sans-serif";color:#323232">Lewis
Roca Rothgerber Christie LLP</span></p>
</td>
</tr>
<tr>
<td style="width:3.5in;padding:0in 5.4pt 0in
5.4pt" valign="top" width="336">
<p class="MsoNormal"><span
style="font-size:9.0pt;font-family:"Arial","sans-serif";color:#323232">One
South Church Avenue, Suite 700</span></p>
</td>
</tr>
<tr>
<td style="width:3.5in;padding:0in 5.4pt 0in
5.4pt" valign="top" width="336">
<p class="MsoNormal"><span
style="font-size:9.0pt;font-family:"Arial","sans-serif";color:#323232">Tucson,
Arizona 85701-1611</span></p>
</td>
</tr>
<tr>
<td style="width:3.5in;padding:0in 5.4pt 0in
5.4pt" valign="top" width="336">
<p class="MsoNormal"><span
style="font-size:12.5pt;font-family:"Arial","sans-serif"">Ruggie
Principle 18. </span></p>
<p class="MsoNormal"><span
style="font-size:12.5pt;font-family:"Arial","sans-serif"">In
order to gauge human rights risks,
business enterprises should identify </span></p>
<p class="MsoNormal"><span
style="font-size:12.5pt;font-family:"Arial","sans-serif"">and
assess any actual or potential adverse
human rights impacts with </span></p>
<p class="MsoNormal"><span
style="font-size:12.5pt;font-family:"Arial","sans-serif"">which
they may be involved either through
their own activities or as a </span></p>
<p class="MsoNormal"><span
style="font-size:12.5pt;font-family:"Arial","sans-serif"">result
of their business relationships. This
process should: </span></p>
<p class="MsoNormal"><span
style="font-size:12.5pt;font-family:"Arial","sans-serif"">(a)
</span></p>
<p class="MsoNormal"><span
style="font-size:12.5pt;font-family:"Arial","sans-serif"">Draw
on internal and/or independent
external human rights </span></p>
<p class="MsoNormal"><span
style="font-size:12.5pt;font-family:"Arial","sans-serif"">expertise;</span></p>
<p class="MsoNormal"><span
style="font-size:12.5pt;font-family:"Arial","sans-serif"">(b)
</span></p>
<p class="MsoNormal"><span
style="font-size:12.5pt;font-family:"Arial","sans-serif"">Involve
meaningful consultation with
potentially affected groups </span></p>
<p class="MsoNormal"><span
style="font-size:12.5pt;font-family:"Arial","sans-serif"">and
other relevant stakeholders, as
appropriate to the size of the </span></p>
<p class="MsoNormal"><span
style="font-size:12.5pt;font-family:"Arial","sans-serif"">business
enterprise and the nature and context
of the operation.</span></p>
<p class="MsoNormal"><span
style="color:#1f497d"> </span></p>
</td>
</tr>
<tr>
<td style="width:3.5in;padding:0in 5.4pt 0in
5.4pt" valign="top" width="336"><br>
</td>
</tr>
</tbody>
</table>
<p class="MsoNormal"> </p>
<p class="m_2260752928253482286MsoPlainText"> </p>
<p class="m_2260752928253482286MsoPlainText">Hi,</p>
<p class="m_2260752928253482286MsoPlainText"> </p>
<p class="m_2260752928253482286MsoPlainText">On
29-Sep-17 19:59, Aikman-Scalese, Anne wrote:</p>
<p class="m_2260752928253482286MsoPlainText">>
So what was everyone on the plenary CCWG- ACCT
call yesterday </p>
<p class="m_2260752928253482286MsoPlainText">>
referring to when they objected to the
"compromise text" that was submitted to the CCWG
list without having gone through the usual
procedures in the subgroup?</p>
<p class="m_2260752928253482286MsoPlainText"> </p>
<p class="m_2260752928253482286MsoPlainText">It
seems to me that once an issue is described as
having no consensus in a subgroup and there is a
declaration that none is reachable, the next
step is to take the question to the plenary for
plenary discussion.</p>
<p class="m_2260752928253482286MsoPlainText">Seems
to me this is especially the case when a
minority view is attached to a proposed
recommendation.</p>
<p class="m_2260752928253482286MsoPlainText"> </p>
<p class="m_2260752928253482286MsoPlainText">This
is not the first time a knotty issue has been
brought to the plenary or the first time a
subgroup was given the opportunity to reconsider
a subgroup decision that was not accepted at the
plenary level.</p>
<p class="m_2260752928253482286MsoPlainText"> </p>
<p class="m_2260752928253482286MsoPlainText">avri</p>
<p class="m_2260752928253482286MsoPlainText"> </p>
<p class="m_2260752928253482286MsoPlainText">______________________________<wbr>_________________</p>
<p class="m_2260752928253482286MsoPlainText">Ws2-hr
mailing list</p>
<p class="m_2260752928253482286MsoPlainText"><a
moz-do-not-send="true"
class="m_2260752928253482286moz-txt-link-abbreviated"
href="mailto:Ws2-hr@icann.org" target="_blank">Ws2-hr@icann.org</a></p>
<p class="m_2260752928253482286MsoPlainText"><a
moz-do-not-send="true"
class="m_2260752928253482286moz-txt-link-freetext"
href="https://mm.icann.org/mailman/listinfo/ws2-hr" target="_blank">https://mm.icann.org/mailman/<wbr>listinfo/ws2-hr</a></p>
<p class="m_2260752928253482286MsoPlainText"> </p>
</div>
<br>
<hr> <font face="Arial" color="Gray" size="1"><br>
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. <br>
</font> <br>
<fieldset
class="m_2260752928253482286mimeAttachmentHeader"></fieldset>
<br>
<pre>______________________________<wbr>_________________
Ws2-hr mailing list
<a moz-do-not-send="true" class="m_2260752928253482286moz-txt-link-abbreviated" href="mailto:Ws2-hr@icann.org" target="_blank">Ws2-hr@icann.org</a>
<a moz-do-not-send="true" class="m_2260752928253482286moz-txt-link-freetext" href="https://mm.icann.org/mailman/listinfo/ws2-hr" target="_blank">https://mm.icann.org/mailman/<wbr>listinfo/ws2-hr</a>
</pre>
</blockquote>
</div></div><span class="HOEnZb"><font color="#888888"><pre class="m_2260752928253482286moz-signature" cols="72">--
Matthew Shears
<a moz-do-not-send="true" class="m_2260752928253482286moz-txt-link-abbreviated" href="mailto:matthew@intpolicy.com" target="_blank">matthew@intpolicy.com</a>
<a moz-do-not-send="true" href="tel:+44%207712%20472987" value="+447712472987" target="_blank">+447712472987</a>
<a moz-do-not-send="true" class="m_2260752928253482286moz-txt-link-freetext">Skype:mshears</a></pre>
</font></span></div>
______________________________<wbr>_________________
Accountability-Cross-Community mailing list
<a moz-do-not-send="true" href="mailto:Accountability-Cross-Community@icann.org">Accountability-Cross-<wbr>Community@icann.org</a>
<a moz-do-not-send="true" href="https://mm.icann.org/mailman/listinfo/accountability-cross-community" rel="noreferrer" target="_blank">https://mm.icann.org/mailman/<wbr>listinfo/accountability-cross-<wbr>community</a>
</blockquote></div>
</div>
<fieldset class="mimeAttachmentHeader"></fieldset>
<pre wrap="">_______________________________________________
Ws2-hr mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Ws2-hr@icann.org">Ws2-hr@icann.org</a>
<a class="moz-txt-link-freetext" href="https://mm.icann.org/mailman/listinfo/ws2-hr">https://mm.icann.org/mailman/listinfo/ws2-hr</a>
</pre>
</blockquote>
</body></html>