[Ws2-hr] When should ICANN uphold human rights?
Dr. Tatiana Tropina
t.tropina at mpicc.de
Tue Sep 6 18:15:52 UTC 2016
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.
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.
Best
Tanya
On 06/09/16 20:05, Greg Shatan wrote:
> Tatiana,
>
> 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.
>
> Greg
>
> On Tue, Sep 6, 2016 at 2:01 PM, Dr. Tatiana Tropina
> <t.tropina at mpicc.de <mailto:t.tropina at mpicc.de>> wrote:
>
> 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/ef86b616/attachment-0001.html>
More information about the Ws2-hr
mailing list