<html>
<head>
<meta content="text/html; charset=utf-8" http-equiv="Content-Type">
</head>
<body 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 class="moz-cite-prefix">On 06/09/16 19:51, Greg Shatan wrote:<br>
</div>
<blockquote
cite="mid:CA+aOHUTLfL0JgBAGR0pi=8gUx4J45DjcJ1MtPqLKQAKJ-3icXw@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">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 class="HOEnZb">
<div class="h5"><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">520.629.4428</a> office<br>
> <a moz-do-not-send="true" href="tel:520.879.4725"
value="+15208794725">520.879.4725</a> fax<br>
> <a moz-do-not-send="true"
href="mailto:AAikman@lrrc.com">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">ws2-hr-bounces@icann.org</a>
[mailto:<a moz-do-not-send="true"
href="mailto:ws2-hr-bounces@icann.org">ws2-hr-bounces@icann.<wbr>org</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">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">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">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">ws2-hr-bounces@icann.org</a>
[mailto:<a moz-do-not-send="true"
href="mailto:ws2-hr-bounces@icann.org">ws2-hr-bounces@icann.<wbr>org</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">gregshatanipc@gmail.com</a>>;
'Nigel Roberts'<br>
>> <<a moz-do-not-send="true"
href="mailto:nigel@channelisles.net">nigel@channelisles.net</a>><br>
>> Cc: <a moz-do-not-send="true"
href="mailto:ws2-hr@icann.org">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">paul.rosenzweig@<wbr>redbranchconsulting.com</a><br>
>><br>
>> O: <a moz-do-not-send="true"
href="tel:%2B1%20%28202%29%20547-0660"
value="+12025470660">+1 (202) 547-0660</a><br>
>><br>
>> M: <a moz-do-not-send="true"
href="tel:%2B1%20%28202%29%20329-9650"
value="+12023299650">+1 (202) 329-9650</a><br>
>><br>
>> VOIP: <a moz-do-not-send="true"
href="tel:%2B1%20%28202%29%20738-1739"
value="+12027381739">+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.<wbr>com/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">ws2-hr-bounces@icann.org</a>
[mailto:<a moz-do-not-send="true"
href="mailto:ws2-hr-bounces@icann.org">ws2-hr-bounces@icann.<wbr>org</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">nigel@channelisles.net</a>><br>
>> Cc: <a moz-do-not-send="true"
href="mailto:ws2-hr@icann.org">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">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">jcurran@istaff.org</a><br>
>><br>
>> <mailto:<a moz-do-not-send="true"
href="mailto:jcurran@istaff.org">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">lists@nielstenoever.net</a><br>
>><br>
>> <mailto:<a moz-do-not-send="true"
href="mailto:lists@nielstenoever.net">lists@nielstenoever.<wbr>net</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">Ws2-hr@icann.org</a>
<mailto:<a moz-do-not-send="true"
href="mailto:Ws2-hr@icann.org">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/mailman/<wbr>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">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>
>><br>
>> ______________________________<wbr>_________________<br>
>> Ws2-hr mailing list<br>
>> <a moz-do-not-send="true"
href="mailto:Ws2-hr@icann.org">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>
>><br>
>><br>
>><br>
>><br>
>> ______________________________<wbr>_________________<br>
>> Ws2-hr mailing list<br>
>> <a moz-do-not-send="true"
href="mailto:Ws2-hr@icann.org">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>
> ______________________________<wbr>_________________<br>
> Ws2-hr mailing list<br>
> <a moz-do-not-send="true"
href="mailto:Ws2-hr@icann.org">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>
><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">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>
<br>
______________________________<wbr>_________________<br>
Ws2-hr mailing list<br>
<a moz-do-not-send="true" href="mailto:Ws2-hr@icann.org">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>
</div>
</div>
</blockquote>
</div>
<br>
</div>
</blockquote>
<br>
</body>
</html>