[Ws2-hr] [CCWG-ACCT] clarification re Human Right Subgroup work and FOI - Human Rights with "Considerations"

[Greg Shatan]

Like Tatiana, I share the concerns that Anne and Matthew expressed.  It
also seems necessary to clarify that the proposed new language would change
the *FoI* itself, advocating the use of Ruggie to interpret the Bylaw.  The
Considerations, which would not be changed under this proposal, stand in
direct conflict to that stance:

With regards to the UN Guiding Principles for Business and Human Rights, *no
consensus was reached as to their suitability for interpreting the Core
Value*. However with regard to the implementation of the Core Value *certain
aspects of the UN Guiding Principles for Business and Human Rights could be
considered* as a useful guide in the process of applying the Human Rights
Core Value. There are *certain Guiding Principles that may not be suitable
for ICANN* and others that might be applicable, depending on the
circumstances. However, it is beyond the scope of this document to provide
a detailed analysis of the Guiding Principles and their application, or
not, in particular situations. (emphasis added)


​The Considerations document even expressly recognizes the likelihood of
conflicts between Ruggie and the ICANN Bylaws:​



In any case, a conflict between any Guiding Principle and an ICANN Bylaw
provision or Article of Incorporation must be resolved in favor of the
Bylaw or Article. The use of the Guiding Principles as potential guidance
has to be carefully considered by each SO and AC as well as ICANN the
organization.


For purposes of clarity (which is the purpose of the FoI), any reference to
the UNGP in the Bylaws should be appropriately qualified to align it with
the Considerations document and to avoid conflict with the HR Bylaw
itself.  The follow caveat would provide the necessary aid to using Ruggie
to interpret the Bylaw:

*Any consideration of the UNGP in interpreting the Bylaw must be expressly
limited by (a) the fact that there is "no consensus" on the UNGP's
"suitability for interpreting the Core Value", (b) the Bylaw's limitation
to "applicable law," (c) the Bylaw's injunction that it cannot be used to
"obligate ICANN to enforce its human rights obligations or the other human
rights obligations of other parties, against other parties, (d) guidance
that only "certain aspects" of the UNGP "might be applicable" while others
"may not be suitable for ICANN", (e) the recognition that there are
conflicts between the UNGP and the Bylaw, and that "a conflict between any
Guiding Principle and an ICANN Bylaw provision or Article of Incorporation
must be resolved in favor of the Bylaw or Article," and (f) the
understanding that the UNGP only applies to ICANN, if at all, in the
context of ICANN the organization's activities as a "business" and not in
its sui generis mission "to ensure the stable and secure operation of the
Internet's unique identifier systems" and to adopt policies, enter into
contracts and allocate DNS resources in connection with that mission. *
   (Quoted language from the ICANN Bylaws and the "Considerations"
accompanying this Framework of Interpretation.)


This would avoid ambiguity and conflict between the Bylaw, the FoI, the
document being suggested to interpret the Bylaw (i.e., the UNGP), and the
underlying considerations taken into account in creating the FoI.

It occurs to me that if we adopted the proposed language in the FOI, we
would need to insert language in the "Considerations" to reflect the
proposal's limiting language, e.g.:

*The UNGP are relevant for business organizations, and should be applied in
that context. To the extent that ICANN the Organization is a business, it
should consider, as a business, certain aspects of the UNGP as a useful
guide when applying the Human Rights Core Value.*

*​*This raises other concerns.  The Human Rights Bylaw is intended as a
"floor" and not a "ceiling."  ICANN the Organization and the Community can
always choose to do more than the Bylaw dictates (within ICANN's remit, of
course).  The more we use language of limitation, the more we leave the
impression that ICANN (the Organization, the Community and the "ecosystem")
cannot voluntarily go beyond the strictures of the Bylaw.  That would be
counterproductive.


The HR subgroup in WS2 was tasked with creating the FoI and taking certain
"considerations" into account.  It was not within our remit to create a
roadmap for the voluntary adoption of Human Rights principles, whether
culled from Ruggie or otherwise.  I understand that some might want to use
the power of the Bylaw to force voluntary compliance (that's an
oxymoron....), or to turn voluntary compliance into Bylaws-mandated
compliance.  I don't support that.  But neither do I want this effort to
limit or appear to limit, in any way, the ability of ICANN (however
defined) and its various structures to debate, consider and adopt, in ways
that they find best, methods to respect Human Rights.

Greg

On Tue, Oct 3, 2017 at 7:47 AM, Matthew Shears <matthew at intpolicy.com>
wrote:

> As Anne, I would like to know both the procedure and justification for
> "new language being proposed at the plenary level with no prior
> consideration of that language at the subgroup"?
> I also do not understand why we are characterizing the positions as "Zero
> Ruggie" or " All Ruggie".   As Anne notes, "David McCauley is quite right
> that not all Ruggie principles make sense for ICANN since it is not a
> typical "business" and its mission is limited, especially as to not
> interfering with content.  Much of what is contained in Ruggie Principles
> seeks to reach "all business relationships" and would thus exert influence
> over content, i.e. Ruggie would no doubt require putting provisions in
> Registry Agreements and Registrar Agreements that change obligations of
> these contracted parties to exert influence over registrants regarding
> Human Rights principles.  ... In the ICANN environment, following all
> Ruggie principles creates too broad a sweep by far."  These points were
> made in the sub-group discussions and on the lists on numerous occasions.
> And the work of the sub-group is not Zero Ruggie - this is a
> mis-characterization.
>
> I also do not believe that it is appropriate to rewrite the
> “Considerations” document is at the plenary level.   The considerations
> document as it stands - and agreed by the sub group - should provide all
> that is needed in terms of references to Ruggie.
>
> Matthew
>
>
> On 02/10/2017 20:54, Aikman-Scalese, Anne wrote:
>
> Thomas et al,
>
> What I am trying to understand is the procedure involved with new language
> being proposed at the plenary level with no prior consideration of that
> language at the subgroup.  I had made specific proposals to include certain
> Ruggie language at the subgroup level with specific reference to
> incorporating Ruggie Principle 18 into the language that is applicable to
> ICANN the organization.  (In fact, I have been advocating reference to
> Ruggie 18(b) from the beginning of participating in WS2-Human Rights.)  So
> if we are considering new language at the plenary, I want to throw in my
> own recommendation that we refer specifically to Ruggie Principle 18 as a
> compromise position.
>
>
>
> I do not understand this black and white FACE-OFF as to "Zero Ruggie" or "
> All Ruggie".  David McCauley is quite right that not all Ruggie principles
> make sense for ICANN since it is not a typical "business" and its mission
> is limited, especially as to not interfering with content.  Much of what is
> contained in Ruggie Principles seeks to reach "all business relationships"
> and would thus exert influence over content, i.e. Ruggie would no doubt
> require putting provisions in Registry Agreements and Registrar Agreements
> that change obligations of these contracted parties to exert influence over
> registrants regarding Human Rights principles.  While this may be
> appropriate for a voluntary Public Interest Commitment on the part of a
> registry, it is certainly not appropriate as a “top-down” ICANN org
> policy.    In the ICANN environment, following all Ruggie principles
> creates too broad a sweep by far.   In addition, there is no other
> "business" that has used Ruggie that follows the multi-stakeholder
> bottom-up policy process, a process unique to ICANN.
>
>
>
> Mark Carvell got the WS2 drafting team on a call at one ICANN meeting with
> someone from the UN (with experience implementing Ruggie) and I
> specifically asked whether she had experience implementing Ruggie with an
> organization that operated on the bottom-up Multi-Stakeholder Model.
> Jorge Cancio was also in the room on this call and asked several
> questions.  Her response was (and I paraphrase)  "No, but ICANN is a
> quasi-governmental organization and has a lot of power to influence Human
> Rights going forward".  So for anyone who feels that ICANN is a
> quasi-governmental organization, they will push ICANN the organization in
> this direction without remembering the applicable law limitation and the
> fact that ICANN is NOT A QUASI-GOVERNMENTAL organization and its policy
> development is not the top-down process followed by other non-profits.
>
>
>
> Certain Ruggie Principles may work well within the limited mission of
> ICANN, most notably Principle 18, shown below my signature.  Others, as
> pointed out in a very thoughtful manner by David McCauley's post to the WS
> 2 HR list, are dangerous and would impose limits on content as well as
> increased difficulty in enforcing property rights (including Intellectual
> Property rights) which are not consistent with Human Rights.    While I may
> strongly disagree with certain views that could be posted at second level
> domains,  ICANN is not the place to try to regulate them.  And I disagree
> with the proposition that there should be an absolute right to post
> anonymously on the Internet as advocated by Article 19.  (Although I agree
> that monitoring “hate speech” is a very dangerous road to go down.)  It
> seems to me the highest principle here is disclosure, in other words,
> “Consider the Source”.
>
>
>
> Regarding the Human Right to privacy, recently it was noted that the
> Russian government may have been the true force and money behind several
> Facebook ads attempting to influence U.S. elections.  So now Facebook is
> cooperating to try to prevent that.  Why?  Because people should know the
> bias associated with statements when there is no "fact check" in place.
> There is also no "fact check" on content posted at second level domains and
> these are now “unlimited” in many respects.   Shouldn't people know where
> these opinions are coming from even if it's not the Russian government?
> What if it's Breitbart?  How should these concerns be balanced with the
> right to privacy of the individual? (Organizations can easily use
> individuals to post ads and advocate opinions.  In addition, who decides
> whether an association of individuals who believe similarly would have no
> right to privacy?)  Which second level domains were being used to influence
> US elections and do the registrants have a right to privacy for everything
> said on those domains as well?  Does it also apply to everything they sell
> on the domain to raise money to place their Facebook ads?  T-shirts?
> Coins?  Hats?  I would say, “Consider the Source” in all cases.   And be
> concerned as to why the source does not want to disclose itself.  Take that
> into account. Is it for nefarious purposes or is it for legitimate fear of
> unjust consequences – e.g. second level registrations at .gay?
>
>
>
> As an organization,  ICANN should not overreact to Snowden and to unjust
> laws in "outlier" governments.   Failure to balance privacy rights with
> other considerations related to policies that develop trust and confidence
> in the worldwide web will not only result in consumer harm, it could even
> throw elections.   "Consider the  Source" is the best adage for both
> opinions and products offered on the Internet.   This does not mean that
> the Spanish government should be able to shut down .cat, in fact it means
> the opposite.  Governments who stand for free speech and privacy  (and the
> legal systems established by those governments) should be protecting and
> enforcing those rights.
>
>
>
> If the “Considerations” document is now open to rewriting at the plenary
> level, then shouldn't we be considering other alternative proposals that
> were rejected by the drafting team?  The most important Ruggie Principle
> for faithfulness to the ICANN bottom-up  Multi-Stakeholder model appears
> below my signature, that is Ruggie Principle 18.  As this discussion is
> being developed further in the plenary, please keep in mind that Ruggie
> calls for a Grievance Procedure and that the Core Value itself contemplates
> both a Request for Reconsideration and an Independent Review Panel process
> in relation to Human Rights claims.
>
>
>
> Anne
>
>
>
>
>
> *Anne E. Aikman-Scalese*
>
> Of Counsel
>
> 520.629.4428 <(520)%20629-4428> office
>
> 520.879.4725 <(520)%20879-4725> fax
>
> AAikman at lrrc.com
>
> _____________________________
>
> Lewis Roca Rothgerber Christie LLP
>
> One South Church Avenue, Suite 700
>
> Tucson, Arizona 85701-1611
>
> Ruggie Principle 18.
>
> In order to gauge human rights risks, business enterprises should identify
>
> and assess any actual or potential adverse human rights impacts with
>
> which they may be involved either through their own activities or as a
>
> result of their business relationships. This process should:
>
> (a)
>
> Draw on internal and/or independent external human rights
>
> expertise;
>
> (b)
>
> Involve meaningful consultation with potentially affected groups
>
> and other relevant stakeholders, as appropriate to the size of the
>
> business enterprise and the nature and context of the operation.
>
>
>
>
>
>
>
> Hi,
>
>
>
> On 29-Sep-17 19:59, Aikman-Scalese, Anne wrote:
>
> > So what was everyone on the plenary CCWG- ACCT call yesterday
>
> > referring to when they objected to the "compromise text" that was
> submitted to the CCWG list without having gone through the usual procedures
> in the subgroup?
>
>
>
> It seems to me that once an issue is described as having no consensus in a
> subgroup and there is a declaration that none is reachable, the next step
> is to take the question to the plenary for plenary discussion.
>
> Seems to me this is especially the case when a minority view is attached
> to a proposed recommendation.
>
>
>
> This is not the first time a knotty issue has been brought to the plenary
> or the first time a subgroup was given the opportunity to reconsider a
> subgroup decision that was not accepted at the plenary level.
>
>
>
> avri
>
>
>
> _______________________________________________
>
> Ws2-hr mailing list
>
> Ws2-hr at icann.org
>
> 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 listWs2-hr at icann.orghttps://mm.icann.org/mailman/listinfo/ws2-hr
>
>
> --
>
>
> Matthew Shearsmatthew at intpolicy.com+447712472987 <+44%207712%20472987>Skype:mshears
>
>
> _______________________________________________
> Accountability-Cross-Community mailing list
> Accountability-Cross-Community at icann.org
> https://mm.icann.org/mailman/listinfo/accountability-cross-community
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/ws2-hr/attachments/20171003/d5c6debf/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image002.png
Type: image/png
Size: 6518 bytes
Desc: not available
URL: <http://mm.icann.org/pipermail/ws2-hr/attachments/20171003/d5c6debf/image002-0001.png>