[Ws2-hr] When should ICANN uphold human rights?

Tue Sep 6 17:57:37 UTC 2016

Hi Anne,

I think for the examples you are talking about, ICANN does have processes
in place.ICANN vets the registry operators and does a background check.
There is also a policy on  "New gTLD Program Safeguards to Mitigate DNS
Abuse". And probably more measures with regards to criminal acts. In New
gTLD program applicant book also there was a GAC early warning if  a new
gTLD was problematic for example.

Best

Farzaneh

On 6 September 2016 at 19:21, Aikman-Scalese, Anne <AAikman at lrrc.com> wrote:

> 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.
>
> 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.
>
> 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?
>
> 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?
>
> Anne
>
> Anne E. Aikman-Scalese
> Of Counsel
> 520.629.4428 office
> 520.879.4725 fax
> AAikman at lrrc.com
> _______________________________
>
> Lewis Roca Rothgerber Christie LLP
> One South Church Avenue, Suite 700
> Tucson, Arizona 85701-1611
> lrrc.com
> -----Original Message-----
> From: ws2-hr-bounces at icann.org [mailto:ws2-hr-bounces at icann.org] On
> Behalf Of Bastiaan Goslings
> Sent: Tuesday, September 06, 2016 9:40 AM
> To: Greg Shatan
> Cc: ws2-hr at icann.org
> Subject: Re: [Ws2-hr] When should ICANN uphold human rights?
>
> 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.
>
> The way I read Ruggie’s definition of ‘respect’ is what is stated in
> principle #11:
>
> '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.’
>
> It’s the ’this means’ part.
>
> (‘Part (b)’ in principle 13 refers to part of a ‘responsibility’ that
> follows, i.e. the requirement as described in this ‘part (b)’)
>
> 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.
>
> Does that make sense? ;-)
>
>  -Bastiaan
>
>
>
>
> > On 06 Sep 2016, at 17:43, Greg Shatan <gregshatanipc at gmail.com> wrote:
> >
> > Paul,
> >
> > 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.
> >
> > Greg
> >
> > On Tue, Sep 6, 2016 at 11:36 AM, <Jorge.Cancio at bakom.admin.ch> wrote:
> > Good question
> >
> > Jorge
> >
> >
> >
> > Von: ws2-hr-bounces at icann.org [mailto:ws2-hr-bounces at icann.org] Im
> > Auftrag von Paul Rosenzweig
> > Gesendet: Dienstag, 6. September 2016 17:35
> > An: 'Greg Shatan' <gregshatanipc at gmail.com>; 'Nigel Roberts'
> > <nigel at channelisles.net>
> > Cc: ws2-hr at icann.org
> > Betreff: Re: [Ws2-hr] When should ICANN uphold human rights?
> >
> >
> >
> > 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?
> >
> >
> >
> > P
> >
> >
> >
> > Paul Rosenzweig
> >
> > paul.rosenzweig at redbranchconsulting.com
> >
> > O: +1 (202) 547-0660
> >
> > M: +1 (202) 329-9650
> >
> > VOIP: +1 (202) 738-1739
> >
> > www.redbranchconsulting.com
> >
> > My PGP Key: http://redbranchconsulting.com/who-we-are/public-pgp-key/
> >
> >
> >
> > From: ws2-hr-bounces at icann.org [mailto:ws2-hr-bounces at icann.org] On
> > Behalf Of Greg Shatan
> > Sent: Tuesday, September 6, 2016 10:58 AM
> > To: Nigel Roberts <nigel at channelisles.net>
> > Cc: ws2-hr at icann.org
> > Subject: Re: [Ws2-hr] When should ICANN uphold human rights?
> >
> >
> >
> > I have a good deal of sympathy with Nigel's position.  But that leaves
> us with a significant issue:
> >
> >
> >
> > 1.  The Bylaw uses the verb "respect."
> >
> > 2.  "Respect" has (at least arguably) a settled meaning in the field of
> corporations and human rights, from the Ruggie Principles.
> >
> > 3.  It was not the intention of the CCWG to adopt the Ruggie Principles'
> definition of "respect."
> >
> > 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.).
> >
> > 5.  If we do not recommend that the Ruggie Principles' definition of
> "respect" be adopted in its entirety, we will either:
> >
> >      a. End up with a definition of "respect" that varies from the
> > Ruggie Principles, or
> >
> >      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.
> >
> > 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.
> >
> >
> >
> > Greg
> >
> >
> >
> > On Tue, Sep 6, 2016 at 3:28 AM, Nigel Roberts <nigel at channelisles.net>
> wrote:
> >
> > Actually, I will strongly caution against using terms-of-art with
> divergent or 'roll-your-own' definitions.
> >
> > 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.
> >
> > 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.
> >
> > Re-definition, is not the way forward, I suggest.
> >
> >
> >
> >
> >
> > On 06/09/16 03:12, Greg Shatan wrote:
> >
> > A few quick comments on the thread above.
> >
> > It is important that we be precise with our verbs.  The Ruggie
> > Principles use three verbs, each with different meanings and with
> > application to different actors: "respect," "protect" and "enforce."
> >   I'm not suggesting we should adopt the Ruggie Principles' meanings
> > for all of these words, but they could be useful as a starting point.
> > As a matter of fact, I don't think we can or should adopt the Ruggie
> > Principles' definition of "respect" in the ICANN context.  But we
> > should be careful about how we use these words, and how we use other
> verbs.
> >
> > As was already noted, "uphold" is a whole new verb, with no standard
> > meaning in the human rights context that I'm aware of.  "Enforce" was
> > also used in this thread, but in a very different context than in the
> > Ruggie Principles, where "enforcement" applies only to the activities
> > of states.  We need to determine what we mean by each verb we use, and
> > especially by "respect" since it appears in the Bylaw.
> >
> > I believe that Niels quoted from the Ruggie Principles definition of
> > respect earlier in this thread when he referred to the draft FoI
> > document.  I believe Paul Twomey in particular has pointed out the
> > significant issues that could arise if ICANN were to adopt part (b) of
> > this definition:
> >
> > (b) Seek to prevent or mitigate adverse human rights impacts that are
> > directly linked to their operations, products or services by their
> > business relationships, even if they have not contributed to those
> impacts.
> >
> > As I understand this, it requires a party to exert pressure, through
> > business relationships, on third parties.   I don't think it's at all
> > settled that ICANN's relationships with applicants, registries and
> > registrars are "business relationships," even where these parties have
> > contracts with ICANN.  But if some or all of these are "business
> > relationships," this could easily be read to require ICANN to impose
> > restrictions on registries and registrars, and on applicants, that
> > would be extremely broad-ranging and may we be antithetical to ICANN's
> mission.
> >
> > I generally agree with John Curran regarding application concerns in
> > the implementation phase.  Once the ICANN policy process has resulted
> > in recommendations which are adopted, the primary focus in
> > implementation needs to be faithfully carrying out the policy
> > recommendations. It's fair to assume that human rights have been taken
> > into account in the policy development process, along with and
> > balanced against other rights and concerns, and that what results from
> > the multistakeholder process should be given effect in implementation.
> >
> > Greg
> >
> > On Mon, Sep 5, 2016 at 9:11 PM, John Curran <jcurran at istaff.org
> >
> > <mailto:jcurran at istaff.org>> wrote:
> >
> >     On Sep 5, 2016, at 6:38 PM, Niels ten Oever
> > <lists at nielstenoever.net
> >
> >     <mailto:lists at nielstenoever.net>> wrote:
> >
> >     ...
> >     b) Seek to prevent or mitigate adverse human rights impacts that are
> >     directly linked to their operations, products or services by their
> >     business relationships, even if they have not contributed to those
> >     impacts.
> >
> >
> >     Interesting predicament.  If one imagines the potential for an
> >     update to one of
> >     the IANA registries that in turn poses an impact to human rights –
> >     i.e. following
> >     the specific guidance from the appropriate community that is
> >     contracting with
> >     ICANN/PTI for IANA services would result in an HR impact, then the
> >     above
> >     proposed responsibility (to prevent or mitigate...) would suggest
> >     that ICANN
> >     should to do otherwise.
> >
> >     Note that the event of ICANN/PTI acting contrary to the clear
> >     direction of one of
> >     the respective communities (names, numbers, protocols) with regard
> >     to IANA
> >     registry updates could easily precipitate a crisis that results in
> >     the end of ICANN,
> >     and thus should probably be avoided...
> >
> >     ICANN (including PTI) needs to place the highest priority upon
> >     fidelity to the
> >     outcomes of the multi-stakeholder process, since its existence is
> >     predicated
> >     (particularly in a post-NTIA contract environment) upon the
> >     presupposition
> >     of the validity of that process.  This is also the reason why I
> >     noted that there
> >     is a significant difference between application of HR principles
> >     within the multi-
> >     stakeholder policy development process when compared to later on
> >     during the
> >     policy implementation phases.
> >
> >     /John
> >
> >     Disclaimer: my views alone.  Feel free to use, share, or discard as
> >     desired.
> >
> >
> >
> >
> >     _______________________________________________
> >     Ws2-hr mailing list
> >
> >     Ws2-hr at icann.org <mailto:Ws2-hr at icann.org>
> >     https://mm.icann.org/mailman/listinfo/ws2-hr
> >     <https://mm.icann.org/mailman/listinfo/ws2-hr>
> >
> >
> >
> >
> > _______________________________________________
> > Ws2-hr mailing list
> > Ws2-hr at icann.org
> > https://mm.icann.org/mailman/listinfo/ws2-hr
> >
> > _______________________________________________
> > Ws2-hr mailing list
> > Ws2-hr at icann.org
> > https://mm.icann.org/mailman/listinfo/ws2-hr
> >
> >
> >
> >
> > _______________________________________________
> > Ws2-hr mailing list
> > Ws2-hr at icann.org
> > https://mm.icann.org/mailman/listinfo/ws2-hr
>
> _______________________________________________
> Ws2-hr mailing list
> Ws2-hr at icann.org
> https://mm.icann.org/mailman/listinfo/ws2-hr
>
> ________________________________
>
> 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.
> _______________________________________________
> Ws2-hr mailing list
> Ws2-hr at icann.org
> https://mm.icann.org/mailman/listinfo/ws2-hr
>

-- 
Farzaneh
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/ws2-hr/attachments/20160906/31192b1c/attachment-0001.html>