<html>
<head>
<meta content="text/html; charset=utf-8" http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<p>One of my points that I didn't manage to express clearly was that
"protection" and "enforcement" include much broader range of
issues than a content regulation. Of course, getting stuck with
discussing content regulation only will lead us nowhere, indeed.
In the general scheme of things, a good framework which will draw
a clear line between respect and other two shall of course "save"
us from all the enforcement and protection issues, including
content regulation. <br>
</p>
<p>I don't know if this is what you mean - that the debate shall be
taken out from the rabbit hole to the level of making a clear
distinction between respect, protection and enforcement, and this
will solve the particular debates on content regulation or
whatever enforcement? I can understand this approach actually. <br>
</p>
<p>Best</p>
<p>Tanya <br>
</p>
<br>
<div class="moz-cite-prefix">On 06/09/16 20:05, Greg Shatan wrote:<br>
</div>
<blockquote
cite="mid:CA+aOHUSfFX5-FGtw5qjmTZg9x0Meq1qWM+NEfo_nRVhRP2Akvg@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">Tatiana,</div>
<div class="gmail_default"
style="font-family:verdana,sans-serif"><br>
</div>
<div class="gmail_default"
style="font-family:verdana,sans-serif">I see your point. But
I suggest that we would be better off using a less loaded
example than "content regulation," because that will fog the
issue we really want to deal with, which is what are
"protection" and "enforcement" of human rights, versus what is
"respect" for human rights. </div>
<div class="gmail_default"
style="font-family:verdana,sans-serif"><br>
</div>
<div class="gmail_default"
style="font-family:verdana,sans-serif">Greg</div>
</div>
<div class="gmail_extra"><br>
<div class="gmail_quote">On Tue, Sep 6, 2016 at 2:01 PM, Dr.
Tatiana Tropina <span dir="ltr"><<a moz-do-not-send="true"
href="mailto:t.tropina@mpicc.de" target="_blank">t.tropina@mpicc.de</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<div bgcolor="#FFFFFF" text="#000000">
<p>Greg,</p>
<p>I think the whole discussion on the "content
regulation" (whether we define it or not here) reflects
the concerns about "enforcement" and "protection".</p>
<p>While we can abandon the use of the term "content
regulation" for the sake of avoiding the maze of rabbit
holes, the enforcement and protection issues will be on
the table anyway, and they will refer to the TLD issues
as well. <br>
</p>
<p>Fortunately, we have restrictions in the mission re
content regulation and in the HR bylaw re enforcement
and protection. I think that is enough to save ICANN
from the content regulation (whatever it means!). But we
have to figure out where is the silver line between
"respect" and the no-go Human Rights watchdog actions. I
think the expression "content regulation" is used here
as it reflect the concerns that ICANN will step into
this area of enforcement.</p>
<p>Best,</p>
<p>Tanya <br>
</p>
<div>
<div class="h5">
<div>On 06/09/16 19:51, Greg Shatan wrote:<br>
</div>
<blockquote type="cite">
<div dir="ltr">
<div class="gmail_default"
style="font-family:verdana,sans-serif">Anne, It
would be helpful to go back to the current AGB
and see how such domains would currently be
treated. ICANN (including the GNSO PDP process)
may already have dealt with that.</div>
<div class="gmail_default"
style="font-family:verdana,sans-serif"><br>
</div>
<div class="gmail_default"
style="font-family:verdana,sans-serif">Tying
this discussion to "content regulation" also
gets us into other sticky wickets.</div>
<div class="gmail_default"
style="font-family:verdana,sans-serif"><br>
</div>
<div class="gmail_default"
style="font-family:verdana,sans-serif">Is
restricting the TLDs that can be applied for
"content regulation"? I would submit that it's
not.</div>
<div class="gmail_default"
style="font-family:verdana,sans-serif"><br>
</div>
<div class="gmail_default"
style="font-family:verdana,sans-serif">Is
restricting the TLDs that can be applied for a
violation of the right to "free expression"?
I'm skeptical about that as well, and even if it
is, the right to free expression is neither
boundless or immune to being balanced with other
rights, including but not limited to human
rights.</div>
<div class="gmail_default"
style="font-family:verdana,sans-serif"><br>
</div>
<div class="gmail_default"
style="font-family:verdana,sans-serif">Is
"content regulation" a loaded term in the ICANN
context? It is now, based on the new bylaws.
Just as ICANNnauts have used "policy" and
"implementation" distinctions to to rule things
in and out of scope, branding something as
"content regulation" puts it in a box that at
the least disfavors doing that thing, whatever
it is. More succinctly, if "content regulation"
is something that ICANN doesn't do, then people
will take things that they don't want ICANN to
do and call them "content regulation."</div>
<div class="gmail_default"
style="font-family:verdana,sans-serif"><br>
</div>
<div class="gmail_default"
style="font-family:verdana,sans-serif">Do we
have a common understanding of what "content
regulation" means in the ICANN context, or even
what "regulation" means in the ICANN context?
Or even "content"? And the corollary, what
isn't "content regulation"? I really doubt it.</div>
<div class="gmail_default"
style="font-family:verdana,sans-serif"><br>
</div>
<div class="gmail_default"
style="font-family:verdana,sans-serif">Is it
within the remit of this group to further define
"content regulation"? I really don't think so.</div>
<div class="gmail_default"
style="font-family:verdana,sans-serif"><br>
</div>
<div class="gmail_default"
style="font-family:verdana,sans-serif">We may be
better off looking at creating a Framework of
Interpretation (and that is our remit, broadly
speaking) that does not require a definition and
common understanding of "content regulation" in
order to guide future reference to and
implementation of the Bylaw.</div>
<div class="gmail_default"
style="font-family:verdana,sans-serif"><br>
</div>
<div class="gmail_default"
style="font-family:verdana,sans-serif">If we
follow the "content regulation" path, we are
likely to end up not only down a rabbit hole,
but in an entire network of rabbit holes.</div>
<div class="gmail_default"
style="font-family:verdana,sans-serif"><br>
</div>
<div class="gmail_default"
style="font-family:verdana,sans-serif">Greg</div>
<div class="gmail_default"
style="font-family:verdana,sans-serif"><br>
</div>
<div class="gmail_default"
style="font-family:verdana,sans-serif"><br>
</div>
</div>
<div class="gmail_extra"><br>
<div class="gmail_quote">On Tue, Sep 6, 2016 at
1:31 PM, Dr. Tatiana Tropina <span dir="ltr"><<a
moz-do-not-send="true"
href="mailto:t.tropina@mpicc.de"
target="_blank">t.tropina@mpicc.de</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0
0 0 .8ex;border-left:1px #ccc
solid;padding-left:1ex">Dear Anne,<br>
<br>
A very short response with my 2c - my first
thought is that the issue of<br>
"(dot)buychildporn" and alike would be the
issue of (applicable)<br>
criminal law rather than human rights issue.<br>
<br>
Warm regards<br>
<br>
Tanya<br>
<div>
<div><br>
<br>
On 06/09/16 19:21, Aikman-Scalese, Anne
wrote:<br>
> Regarding "address human rights
impacts with which they are involved", I
am quite stuck on the issue of "content
regulation" when ICANN awards a TLD
contract. For example, a registry
operator applies in the next round for
"(dot)buychildporn". I personally think
there is a human rights issue here in
which ICANN is directly involved within
the scope of its mission and operations.<br>
><br>
> What about a TLD application for
(dot)legalizeslavery. ICANN is very
directly involved in the award of TLDs.
It signs contracts and determines when
those contracts are renewed or revoked.
Very difficult indeed to see how anyone
could say that ICANN would not be
obligated, by this definition of "respect"
to review potential adverse human rights
impact of a TLD application.<br>
><br>
> No advisory or policy recommending
body in the ICANN Community currently has
responsibility to review Human Rights
impact in the applications for new TLDs.
There is no mechanism for doing so and
arguably the implications for free speech
are quite broad if we start saying that
certain proposed purposes for certain TLDs
(as shown in the application relevant
application) have adverse human rights
impacts. Will we now place this
responsibility on the GAC as a public
policy matter? What if GNSO disagrees and
prefers to uphold freedom of expression
even if the expression is ugly and has an
adverse impact on Human Rights?<br>
><br>
> So it appears we may not be able to
deal with this within the community
without establishing a Human Rights
Objection process - but again what about
the free speech aspects of this? Is a
Human Rights Objection process in and of
itself a content regulation provision?<br>
><br>
> Anne<br>
><br>
> Anne E. Aikman-Scalese<br>
> Of Counsel<br>
> <a moz-do-not-send="true"
href="tel:520.629.4428"
value="+15206294428" target="_blank">520.629.4428</a>
office<br>
> <a moz-do-not-send="true"
href="tel:520.879.4725"
value="+15208794725" target="_blank">520.879.4725</a>
fax<br>
> <a moz-do-not-send="true"
href="mailto:AAikman@lrrc.com"
target="_blank">AAikman@lrrc.com</a><br>
> ______________________________<wbr>_<br>
><br>
> Lewis Roca Rothgerber Christie LLP<br>
> One South Church Avenue, Suite 700<br>
> Tucson, Arizona 85701-1611<br>
> <a moz-do-not-send="true"
href="http://lrrc.com" rel="noreferrer"
target="_blank">lrrc.com</a><br>
> -----Original Message-----<br>
> From: <a moz-do-not-send="true"
href="mailto:ws2-hr-bounces@icann.org"
target="_blank">ws2-hr-bounces@icann.org</a>
[mailto:<a moz-do-not-send="true"
href="mailto:ws2-hr-bounces@icann.org"
target="_blank">ws2-hr-bounces@icann.o<wbr>rg</a>]
On Behalf Of Bastiaan Goslings<br>
> Sent: Tuesday, September 06, 2016
9:40 AM<br>
> To: Greg Shatan<br>
> Cc: <a moz-do-not-send="true"
href="mailto:ws2-hr@icann.org"
target="_blank">ws2-hr@icann.org</a><br>
> Subject: Re: [Ws2-hr] When should
ICANN uphold human rights?<br>
><br>
> Whilst I (think I) see where you are
heading, Greg - and I tend to agree,
although I’m not sure what ’seeking to
prevent or mitigate’ exactly means in
terms of exerting pressure on third
parties - the ‘resurfacing those comments’
could be helpful as I am slightly lost
here.<br>
><br>
> The way I read Ruggie’s definition of
‘respect’ is what is stated in principle
#11:<br>
><br>
> 'Business enterprises should respect
human rights. This means that they should
avoid infringing on the human rights of
others and should address adverse human
rights impacts with which they are
involved.’<br>
><br>
> It’s the ’this means’ part.<br>
><br>
> (‘Part (b)’ in principle 13 refers to
part of a ‘responsibility’ that follows,
i.e. the requirement as described in this
‘part (b)’)<br>
><br>
> Simply put, following my
interpretation of Ruggie’s ‘respect’
definition, ICANN should avoid infringing
on the human rights of others. And it does
not have to address adverse human rights
impacts with which it is not involved.<br>
><br>
> Does that make sense? ;-)<br>
><br>
> -Bastiaan<br>
><br>
><br>
><br>
><br>
>> On 06 Sep 2016, at 17:43, Greg
Shatan <<a moz-do-not-send="true"
href="mailto:gregshatanipc@gmail.com"
target="_blank">gregshatanipc@gmail.com</a>>
wrote:<br>
>><br>
>> Paul,<br>
>><br>
>> My prior email in this thread
touches on why we would not want to adopt
(at least not in full) part (b) of the
Ruggie Principles' definition of
"respect". Paul Twomey has also commented
on this issue at length during WS1; if we
could resurface those comments it would be
very helpful. The commentary around the
draft documents in Google Docs also
touches on this issue.<br>
>><br>
>> Greg<br>
>><br>
>> On Tue, Sep 6, 2016 at 11:36 AM,
<<a moz-do-not-send="true"
href="mailto:Jorge.Cancio@bakom.admin.ch"
target="_blank">Jorge.Cancio@bakom.admin.ch</a>>
wrote:<br>
>> Good question<br>
>><br>
>> Jorge<br>
>><br>
>><br>
>><br>
>> Von: <a moz-do-not-send="true"
href="mailto:ws2-hr-bounces@icann.org"
target="_blank">ws2-hr-bounces@icann.org</a>
[mailto:<a moz-do-not-send="true"
href="mailto:ws2-hr-bounces@icann.org"
target="_blank">ws2-hr-bounces@icann.o<wbr>rg</a>]
Im<br>
>> Auftrag von Paul Rosenzweig<br>
>> Gesendet: Dienstag, 6. September
2016 17:35<br>
>> An: 'Greg Shatan' <<a
moz-do-not-send="true"
href="mailto:gregshatanipc@gmail.com"
target="_blank">gregshatanipc@gmail.com</a>>;
'Nigel Roberts'<br>
>> <<a moz-do-not-send="true"
href="mailto:nigel@channelisles.net"
target="_blank">nigel@channelisles.net</a>><br>
>> Cc: <a moz-do-not-send="true"
href="mailto:ws2-hr@icann.org"
target="_blank">ws2-hr@icann.org</a><br>
>> Betreff: Re: [Ws2-hr] When should
ICANN uphold human rights?<br>
>><br>
>><br>
>><br>
>> Can someone better versed in this
articulate for me why we would NOT want to
use the Ruggie definition. I agree that
the CCWG did not intend us to necessarily
adopt that definition; but they also did
not necessarily intend to exclude it. For
the reasons Greg has articulated, it seems
to me that it would be wise to follow
accepted practice UNLESS there is a good
reason not to. Hence my question: Is
there something wrong with the way
“respect” is used by the Ruggie principles
that I am missing?<br>
>><br>
>><br>
>><br>
>> P<br>
>><br>
>><br>
>><br>
>> Paul Rosenzweig<br>
>><br>
>> <a moz-do-not-send="true"
href="mailto:paul.rosenzweig@redbranchconsulting.com"
target="_blank">paul.rosenzweig@redbranchconsu<wbr>lting.com</a><br>
>><br>
>> O: <a moz-do-not-send="true"
href="tel:%2B1%20%28202%29%20547-0660"
value="+12025470660" target="_blank">+1
(202) 547-0660</a><br>
>><br>
>> M: <a moz-do-not-send="true"
href="tel:%2B1%20%28202%29%20329-9650"
value="+12023299650" target="_blank">+1
(202) 329-9650</a><br>
>><br>
>> VOIP: <a moz-do-not-send="true"
href="tel:%2B1%20%28202%29%20738-1739"
value="+12027381739" target="_blank">+1
(202) 738-1739</a><br>
>><br>
>> <a moz-do-not-send="true"
href="http://www.redbranchconsulting.com"
rel="noreferrer" target="_blank">www.redbranchconsulting.com</a><br>
>><br>
>> My PGP Key: <a
moz-do-not-send="true"
href="http://redbranchconsulting.com/who-we-are/public-pgp-key/"
rel="noreferrer" target="_blank">http://redbranchconsulting.com<wbr>/who-we-are/public-pgp-key/</a><br>
>><br>
>><br>
>><br>
>> From: <a moz-do-not-send="true"
href="mailto:ws2-hr-bounces@icann.org"
target="_blank">ws2-hr-bounces@icann.org</a>
[mailto:<a moz-do-not-send="true"
href="mailto:ws2-hr-bounces@icann.org"
target="_blank">ws2-hr-bounces@icann.o<wbr>rg</a>]
On<br>
>> Behalf Of Greg Shatan<br>
>> Sent: Tuesday, September 6, 2016
10:58 AM<br>
>> To: Nigel Roberts <<a
moz-do-not-send="true"
href="mailto:nigel@channelisles.net"
target="_blank">nigel@channelisles.net</a>><br>
>> Cc: <a moz-do-not-send="true"
href="mailto:ws2-hr@icann.org"
target="_blank">ws2-hr@icann.org</a><br>
>> Subject: Re: [Ws2-hr] When should
ICANN uphold human rights?<br>
>><br>
>><br>
>><br>
>> I have a good deal of sympathy
with Nigel's position. But that leaves us
with a significant issue:<br>
>><br>
>><br>
>><br>
>> 1. The Bylaw uses the verb
"respect."<br>
>><br>
>> 2. "Respect" has (at least
arguably) a settled meaning in the field
of corporations and human rights, from the
Ruggie Principles.<br>
>><br>
>> 3. It was not the intention of
the CCWG to adopt the Ruggie Principles'
definition of "respect."<br>
>><br>
>> 4. It's up to this group,
initially, to consider what we mean by
"respect" in the context of ICANN and
human rights (and our recommendations will
then go back to the CCWG and out for
public comment, etc.).<br>
>><br>
>> 5. If we do not recommend that
the Ruggie Principles' definition of
"respect" be adopted in its entirety, we
will either:<br>
>><br>
>> a. End up with a definition
of "respect" that varies from the<br>
>> Ruggie Principles, or<br>
>><br>
>> b. Need to recommend an
amendment of the Bylaws to change the word
"respect" to a word or phrase that is not
a "term of art" in the application of
human rights, and we will need to
recommend an appropriate word or phrase
for that purpose.<br>
>><br>
>> 6. Picking up on Nigel's last
point, we will need to understand and
explain "respect/protect/enforce" and
explain that our recommendation for what
ICANN should do does not fall into any of
those three defined terms as they are used
in the Ruggie Principles. Frankly, we
need to do this sooner rather than later,
as it is really an essential part of our
task, and this discussion highlights how
careful we need to be in choosing certain
words in our discussion as well as our
recommendations.<br>
>><br>
>><br>
>><br>
>> Greg<br>
>><br>
>><br>
>><br>
>> On Tue, Sep 6, 2016 at 3:28 AM,
Nigel Roberts <<a
moz-do-not-send="true"
href="mailto:nigel@channelisles.net"
target="_blank">nigel@channelisles.net</a>>
wrote:<br>
>><br>
>> Actually, I will strongly caution
against using terms-of-art with divergent
or 'roll-your-own' definitions.<br>
>><br>
>> It may be tempting for ICANN to
create our own variant definiton of terms
like 'respect for', but this is likely to
cause confusion, and even potential
conflict with government actors (among
others) to whom human rights law, and
principles directly apply.<br>
>><br>
>> I submit what we need to do is
understand fully and explain the meaning
of such terms-of-art and put them in the
context of ICANN's voluntary adoption of a
common, albeit basic, commitment to
fundamental rights standard.<br>
>><br>
>> Re-definition, is not the way
forward, I suggest.<br>
>><br>
>><br>
>><br>
>><br>
>><br>
>> On 06/09/16 03:12, Greg Shatan
wrote:<br>
>><br>
>> A few quick comments on the
thread above.<br>
>><br>
>> It is important that we be
precise with our verbs. The Ruggie<br>
>> Principles use three verbs, each
with different meanings and with<br>
>> application to different actors:
"respect," "protect" and "enforce."<br>
>> I'm not suggesting we should
adopt the Ruggie Principles' meanings<br>
>> for all of these words, but they
could be useful as a starting point.<br>
>> As a matter of fact, I don't
think we can or should adopt the Ruggie<br>
>> Principles' definition of
"respect" in the ICANN context. But we<br>
>> should be careful about how we
use these words, and how we use other
verbs.<br>
>><br>
>> As was already noted, "uphold" is
a whole new verb, with no standard<br>
>> meaning in the human rights
context that I'm aware of. "Enforce" was<br>
>> also used in this thread, but in
a very different context than in the<br>
>> Ruggie Principles, where
"enforcement" applies only to the
activities<br>
>> of states. We need to determine
what we mean by each verb we use, and<br>
>> especially by "respect" since it
appears in the Bylaw.<br>
>><br>
>> I believe that Niels quoted from
the Ruggie Principles definition of<br>
>> respect earlier in this thread
when he referred to the draft FoI<br>
>> document. I believe Paul Twomey
in particular has pointed out the<br>
>> significant issues that could
arise if ICANN were to adopt part (b) of<br>
>> this definition:<br>
>><br>
>> (b) Seek to prevent or mitigate
adverse human rights impacts that are<br>
>> directly linked to their
operations, products or services by their<br>
>> business relationships, even if
they have not contributed to those
impacts.<br>
>><br>
>> As I understand this, it requires
a party to exert pressure, through<br>
>> business relationships, on third
parties. I don't think it's at all<br>
>> settled that ICANN's
relationships with applicants, registries
and<br>
>> registrars are "business
relationships," even where these parties
have<br>
>> contracts with ICANN. But if
some or all of these are "business<br>
>> relationships," this could easily
be read to require ICANN to impose<br>
>> restrictions on registries and
registrars, and on applicants, that<br>
>> would be extremely broad-ranging
and may we be antithetical to ICANN's
mission.<br>
>><br>
>> I generally agree with John
Curran regarding application concerns in<br>
>> the implementation phase. Once
the ICANN policy process has resulted<br>
>> in recommendations which are
adopted, the primary focus in<br>
>> implementation needs to be
faithfully carrying out the policy<br>
>> recommendations. It's fair to
assume that human rights have been taken<br>
>> into account in the policy
development process, along with and<br>
>> balanced against other rights and
concerns, and that what results from<br>
>> the multistakeholder process
should be given effect in implementation.<br>
>><br>
>> Greg<br>
>><br>
>> On Mon, Sep 5, 2016 at 9:11 PM,
John Curran <<a moz-do-not-send="true"
href="mailto:jcurran@istaff.org"
target="_blank">jcurran@istaff.org</a><br>
>><br>
>> <mailto:<a
moz-do-not-send="true"
href="mailto:jcurran@istaff.org"
target="_blank">jcurran@istaff.org</a>>>
wrote:<br>
>><br>
>> On Sep 5, 2016, at 6:38 PM,
Niels ten Oever<br>
>> <<a moz-do-not-send="true"
href="mailto:lists@nielstenoever.net"
target="_blank">lists@nielstenoever.net</a><br>
>><br>
>> <mailto:<a
moz-do-not-send="true"
href="mailto:lists@nielstenoever.net"
target="_blank">lists@nielstenoever.n<wbr>et</a>>>
wrote:<br>
>><br>
>> ...<br>
>> b) Seek to prevent or
mitigate adverse human rights impacts that
are<br>
>> directly linked to their
operations, products or services by their<br>
>> business relationships, even
if they have not contributed to those<br>
>> impacts.<br>
>><br>
>><br>
>> Interesting predicament. If
one imagines the potential for an<br>
>> update to one of<br>
>> the IANA registries that in
turn poses an impact to human rights –<br>
>> i.e. following<br>
>> the specific guidance from
the appropriate community that is<br>
>> contracting with<br>
>> ICANN/PTI for IANA services
would result in an HR impact, then the<br>
>> above<br>
>> proposed responsibility (to
prevent or mitigate...) would suggest<br>
>> that ICANN<br>
>> should to do otherwise.<br>
>><br>
>> Note that the event of
ICANN/PTI acting contrary to the clear<br>
>> direction of one of<br>
>> the respective communities
(names, numbers, protocols) with regard<br>
>> to IANA<br>
>> registry updates could easily
precipitate a crisis that results in<br>
>> the end of ICANN,<br>
>> and thus should probably be
avoided...<br>
>><br>
>> ICANN (including PTI) needs
to place the highest priority upon<br>
>> fidelity to the<br>
>> outcomes of the
multi-stakeholder process, since its
existence is<br>
>> predicated<br>
>> (particularly in a post-NTIA
contract environment) upon the<br>
>> presupposition<br>
>> of the validity of that
process. This is also the reason why I<br>
>> noted that there<br>
>> is a significant difference
between application of HR principles<br>
>> within the multi-<br>
>> stakeholder policy
development process when compared to later
on<br>
>> during the<br>
>> policy implementation phases.<br>
>><br>
>> /John<br>
>><br>
>> Disclaimer: my views alone.
Feel free to use, share, or discard as<br>
>> desired.<br>
>><br>
>><br>
>><br>
>><br>
>> _____________________________<wbr>__________________<br>
>> Ws2-hr mailing list<br>
>><br>
>> <a moz-do-not-send="true"
href="mailto:Ws2-hr@icann.org"
target="_blank">Ws2-hr@icann.org</a>
<mailto:<a moz-do-not-send="true"
href="mailto:Ws2-hr@icann.org"
target="_blank">Ws2-hr@icann.org</a>><br>
>> <a moz-do-not-send="true"
href="https://mm.icann.org/mailman/listinfo/ws2-hr"
rel="noreferrer" target="_blank">https://mm.icann.org/mailman/<wbr>listinfo/ws2-hr</a><br>
>> <<a moz-do-not-send="true"
href="https://mm.icann.org/mailman/listinfo/ws2-hr" rel="noreferrer"
target="_blank">https://mm.icann.org/<wbr>mailman/listinfo/ws2-hr</a>><br>
>><br>
>><br>
>><br>
>><br>
>> ______________________________<wbr>_________________<br>
>> Ws2-hr mailing list<br>
>> <a moz-do-not-send="true"
href="mailto:Ws2-hr@icann.org"
target="_blank">Ws2-hr@icann.org</a><br>
>> <a moz-do-not-send="true"
href="https://mm.icann.org/mailman/listinfo/ws2-hr"
rel="noreferrer" target="_blank">https://mm.icann.org/mailman/l<wbr>istinfo/ws2-hr</a><br>
>><br>
>> ______________________________<wbr>_________________<br>
>> Ws2-hr mailing list<br>
>> <a moz-do-not-send="true"
href="mailto:Ws2-hr@icann.org"
target="_blank">Ws2-hr@icann.org</a><br>
>> <a moz-do-not-send="true"
href="https://mm.icann.org/mailman/listinfo/ws2-hr"
rel="noreferrer" target="_blank">https://mm.icann.org/mailman/l<wbr>istinfo/ws2-hr</a><br>
>><br>
>><br>
>><br>
>><br>
>> ______________________________<wbr>_________________<br>
>> Ws2-hr mailing list<br>
>> <a moz-do-not-send="true"
href="mailto:Ws2-hr@icann.org"
target="_blank">Ws2-hr@icann.org</a><br>
>> <a moz-do-not-send="true"
href="https://mm.icann.org/mailman/listinfo/ws2-hr"
rel="noreferrer" target="_blank">https://mm.icann.org/mailman/l<wbr>istinfo/ws2-hr</a><br>
> ______________________________<wbr>_________________<br>
> Ws2-hr mailing list<br>
> <a moz-do-not-send="true"
href="mailto:Ws2-hr@icann.org"
target="_blank">Ws2-hr@icann.org</a><br>
> <a moz-do-not-send="true"
href="https://mm.icann.org/mailman/listinfo/ws2-hr"
rel="noreferrer" target="_blank">https://mm.icann.org/mailman/l<wbr>istinfo/ws2-hr</a><br>
><br>
> ______________________________<wbr>__<br>
><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>
> ______________________________<wbr>_________________<br>
> Ws2-hr mailing list<br>
> <a moz-do-not-send="true"
href="mailto:Ws2-hr@icann.org"
target="_blank">Ws2-hr@icann.org</a><br>
> <a moz-do-not-send="true"
href="https://mm.icann.org/mailman/listinfo/ws2-hr"
rel="noreferrer" target="_blank">https://mm.icann.org/mailman/l<wbr>istinfo/ws2-hr</a><br>
<br>
______________________________<wbr>_________________<br>
Ws2-hr mailing list<br>
<a moz-do-not-send="true"
href="mailto:Ws2-hr@icann.org"
target="_blank">Ws2-hr@icann.org</a><br>
<a moz-do-not-send="true"
href="https://mm.icann.org/mailman/listinfo/ws2-hr"
rel="noreferrer" target="_blank">https://mm.icann.org/mailman/l<wbr>istinfo/ws2-hr</a><br>
</div>
</div>
</blockquote>
</div>
<br>
</div>
</blockquote>
<br>
</div>
</div>
</div>
</blockquote>
</div>
<br>
</div>
</blockquote>
<br>
</body>
</html>