[Ws2-hr] When should ICANN uphold human rights?
Dr. Tatiana Tropina
t.tropina at mpicc.de
Tue Sep 6 17:00:38 UTC 2016
Agree with Greg,
this discussion is related to the document on what was agreed in the Ws1
(it was recently finalised by the team of volunteers and everyone can
access it). We had quite a heated debate in the WP4, and there was a
general agreement that we can't adopt a definition of "respect" from
Ruggie - partially this is why the bylaw is dormant and we need a
framework of interpretation. The part (b) of the Ruggie definition
raised serious concerns about protection and enforcement. I hope Paul
Twomey can later intervene this discussion and repeat his concerns
again, but we might have a look at the transcripts from WS1, I remember
that on one of the calls he made a clear statement about Ruggie. The
comments in the Google documents on WS1 and FoI refer to this debate.
At the same time, I express my support to the idea that we are better to
follow the same language we used before (and that is in the CCWG report
and the bylaw), meaning that we use the words "respect", "protect" and
"enforce" in order to avoid confusions. However, answering the question
of what respect, protect and enforce mean for ICANN is exactly one of
the tasks of this group.
Warm regards
Tatiana
On 06/09/16 17:43, Greg Shatan 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
> 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/03bc3937/attachment-0001.html>
More information about the Ws2-hr
mailing list