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

Tue Sep 6 15:10:15 UTC 2016

Dear All,

We are now in the middle of nowhere:

We cannot select Enforce  as there is no enforcement mechanism

We can not select protect as we do not want and in fact cannot create a
watchdog.

some people do not want to use respect which is widely understood   to be
more applicable to the case

Any new terms create unnecessary discussion.

Good luck

ARASTEH

2016-09-06 16:58 GMT+02:00 Greg Shatan <gregshatanipc at gmail.com>:

> 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/ws2-hr/attachments/20160906/febc1992/attachment.html>