[Ws2-hr] When should ICANN uphold human rights?
Dr. Tatiana Tropina
t.tropina at mpicc.de
Tue Sep 6 18:01:36 UTC 2016
Greg,
I think the whole discussion on the "content regulation" (whether we
define it or not here) reflects the concerns about "enforcement" and
"protection".
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.
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.
Best,
Tanya
On 06/09/16 19:51, Greg Shatan wrote:
> 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.
>
> Tying this discussion to "content regulation" also gets us into other
> sticky wickets.
>
> Is restricting the TLDs that can be applied for "content regulation"?
> I would submit that it's not.
>
> 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.
>
> 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."
>
> 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.
>
> Is it within the remit of this group to further define "content
> regulation"? I really don't think so.
>
> 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.
>
> 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.
>
> Greg
>
>
>
> On Tue, Sep 6, 2016 at 1:31 PM, Dr. Tatiana Tropina
> <t.tropina at mpicc.de <mailto:t.tropina at mpicc.de>> wrote:
>
> Dear Anne,
>
> A very short response with my 2c - my first thought is that the
> issue of
> "(dot)buychildporn" and alike would be the issue of (applicable)
> criminal law rather than human rights issue.
>
> Warm regards
>
> Tanya
>
>
> On 06/09/16 19:21, Aikman-Scalese, Anne 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 <tel:520.629.4428> office
> > 520.879.4725 <tel:520.879.4725> fax
> > AAikman at lrrc.com <mailto:AAikman at lrrc.com>
> > _______________________________
> >
> > Lewis Roca Rothgerber Christie LLP
> > One South Church Avenue, Suite 700
> > Tucson, Arizona 85701-1611
> > lrrc.com <http://lrrc.com>
> > -----Original Message-----
> > From: ws2-hr-bounces at icann.org <mailto:ws2-hr-bounces at icann.org>
> [mailto: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 <mailto: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
> <mailto: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
> <mailto:Jorge.Cancio at bakom.admin.ch>> wrote:
> >> Good question
> >>
> >> Jorge
> >>
> >>
> >>
> >> Von: ws2-hr-bounces at icann.org <mailto:ws2-hr-bounces at icann.org>
> [mailto: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
> <mailto:gregshatanipc at gmail.com>>; 'Nigel Roberts'
> >> <nigel at channelisles.net <mailto:nigel at channelisles.net>>
> >> Cc: ws2-hr at icann.org <mailto: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
> <mailto:paul.rosenzweig at redbranchconsulting.com>
> >>
> >> O: +1 (202) 547-0660 <tel:%2B1%20%28202%29%20547-0660>
> >>
> >> M: +1 (202) 329-9650 <tel:%2B1%20%28202%29%20329-9650>
> >>
> >> VOIP: +1 (202) 738-1739 <tel:%2B1%20%28202%29%20738-1739>
> >>
> >> www.redbranchconsulting.com <http://www.redbranchconsulting.com>
> >>
> >> My PGP Key:
> http://redbranchconsulting.com/who-we-are/public-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> [mailto: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
> <mailto:nigel at channelisles.net>>
> >> Cc: ws2-hr at icann.org <mailto: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 <mailto: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>
> >>
> >> <mailto: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>
> >>
> >> <mailto: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>
> <mailto: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>
> >> <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 <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 <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 <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 <mailto:Ws2-hr at icann.org>
> > https://mm.icann.org/mailman/listinfo/ws2-hr
> <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 <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 <mailto:Ws2-hr at icann.org>
> https://mm.icann.org/mailman/listinfo/ws2-hr
> <https://mm.icann.org/mailman/listinfo/ws2-hr>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/ws2-hr/attachments/20160906/1a0eca12/attachment-0001.html>
More information about the Ws2-hr
mailing list