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:
<mailto:jcurran@istaff.org>> 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@istaff.org
On Sep 5, 2016, at 6:38 PM, Niels ten Oever <lists@nielstenoever.netWs2-hr@icann.org <mailto:Ws2-hr@icann.org><mailto:lists@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
https://mm.icann.org/mailman/listinfo/ws2-hr
<https://mm.icann.org/mailman/listinfo/ws2-hr >
_______________________________________________
Ws2-hr mailing list
Ws2-hr@icann.org
https://mm.icann.org/mailman/listinfo/ws2-hr
_______________________________________________
Ws2-hr mailing list
Ws2-hr@icann.org
https://mm.icann.org/mailman/listinfo/ws2-hr