[CCWG-ACCT] Attempt to summarize discussion regarding Mission and Contract

[Silver, Bradley]

Malcolm, even if ICANN's ability to enforce agreements with contracted parties is enshrined in the language below, how would we address an argument that the prohibition against regulation precludes such contracts having a downstream effect on non-contracted parties (and content)?  As Becky alludes, the URDP and WHOIS requirements are examples of those downstream effects.   

-----Original Message-----
From: accountability-cross-community-bounces at icann.org [mailto:accountability-cross-community-bounces at icann.org] On Behalf Of Malcolm Hutty
Sent: Wednesday, November 11, 2015 10:26 AM
To: Burr, Becky; Robin Gross
Cc: ACCT-Staff; Accountability Community
Subject: Re: [CCWG-ACCT] Attempt to summarize discussion regarding Mission and Contract



On 11/11/2015 14:47, Burr, Becky wrote:
> Could I get you to expand on one point Robin, Paul and others?  To the 
> extent ICANN obligates registrars to make registrants agree to submit 
> to a UDRP, is that regulation of parties not in privity of contract 
> with ICANN?  What about the requirement that registrants provide 
> accurate WHOIS Information.

Perhaps I can take that.

The proposal that we frame this as a prohibition on "regulation of parties not in privity of contract with ICANN" is a proposal from BC and USCIB. It is one form of wording that aims at the same basic intent as the original wording.

For myself, I think this alternative wording is intended to resolve one fear (that an excessively broad interpretation of "regulate" might result in ICANN being unable to form contracts of any sort), but it introduces problems of its own. If the BC's wording were used, I think UDRP and WHOIS requirements would be in jeopardy. I wouldn't want to do that, not do I see any public comment that suggests this is anybody's aim, least of all BC. That's why, when we sought a compromise that would address that concern, we did not adopt the BC wording, but instead added the following:

"ICANN shall have the ability to negotiate, enter into and enforce agreements with contracted parties in service of its Mission."

I think this is a good faith effort to accomodate the point that BC and USCIB raised, without reneging on the basic attempt to prevent the downstream content regulation, a principle that BC, USCIB have been clear that they also support. In other words, if we keep the Second Draft Report text and adopt the above sentence in addition, I believe we can in good conscience say that we have accommodated BOTH those that supported the original language AND the BC/USCIB input. Such reconciliation is surely what we should be aiming at, is it not?

So the answer to your question is that if we go with the Second Draft Report language (with or without the additional sentence), I don't think there is any problem with continuing UDRP or WHOIS. If we adopted the BC text as an alternative solution, I think that would make the UDRP ultra vires (which is surely accidental on BC's part).

> What about the new gTLD
> applicant guidebook prohibition on Strings at the top level that 
> advocate behavior that violateS globally accepted human rights 
> standards?

> These examples are things that ICANN does right now. Are they ultra 
> vires under the regulatory prohibition? If not, why not?


Again, we need to distinguish between the BC text and the Second Draft Report text.

I think that BC text would create a conflict here too.

The Second Draft Report text (with or without the additional sentence quoted above) would not conflict with those rules. The reason is that the text does not restrain ICANN in its choices as to which top-level domains to approve or decline to approve in any way.

The text only restricts ICANN from seeking to regulate the services (such as web servers) that use the DNS. Declining to approve the delegation of a controversial string could not credibly be said to be an example of regulating the services (such as web servers) that use the DNS. Any attempt to mount such a claim in an IRP challenge would be doomed to failure. Indeed, assuming the IRP adopts procedures for the swift dismissal of claims with no reasonable prospect of success, as we recommend elsewhere in our report, such an ill-founded claim would be dismissed rapidly.

That said, Alan Greenberg has said he doesn't consider this point to be as unequivocally clear as I claim. Alan and I are entirely in agreement that this clause should not restrain ICANN's unlimited discretion as to which strings to approve as new gTLDs, but Alan thinks there is room for confusion on whether our text successfully achieves that. I would be happy to add a drafting note to our lawyers that the final text must not bring this into question.

In conclusion, as long as we proceed with the text that has been published, scrutinised, commented upon and widely suppored, we need have no fear concerning the points you raise.

Your questions do, however, point up the dangers of unforeseen consequences in making, at this late stage, substantial changes to the text we have previously published.

Kind Regards,

Malcolm.


> Sent from my iPad
> 
>> On Nov 11, 2015, at 8:30 AM, Robin Gross <robin at ipjustice.org>
>> wrote:
>> 
>> I do not agree that there lacks consensus on including the text which 
>> states ICANN won't regulate content.  There IS consensus on that 
>> point, but not full consensus because a small minority disagrees with 
>> that position (IPC).  Some in the BC don't even take this extreme IPC 
>> position.
>> 
>> Many different parts of the community have commented that this is a 
>> crucial component to our proposed accountability plan, so taking it 
>> out at this stage, simply because the IPC won't relent is 
>> unacceptable.  The other parts of the community have to accept that 
>> we don't always get everything we want, and I find it difficult to 
>> understand why the same standard doesn't apply to the IPC - why we 
>> continue to go in circles until the IPC is satisfied.  These extra 
>> bites at the apple must stop.  We need some strength and backbone in 
>> our chairs and rapporteurs to not allow a small minority to impose 
>> this on the rest of the community, simply by refusing to relent until 
>> time runs out.
>> 
>> Deleting this point, which has been repeatedly stated as crucial for 
>> such a wide segment of the community will create much more trouble 
>> for the acceptance of our report than not allowing the IPC to get 
>> everything it wants.
>> 
>> Robin
>> 
>>> On Nov 10, 2015, at 7:19 PM, Malcolm Hutty wrote:
>>> 
>>> 
>>> 
>>>> On 11/11/2015 02:10, Burr, Becky wrote: Malcolm et al:
>>>> 
>>>> I have to agree that the 11 comments appended by Malcolm express 
>>>> strong support for the notion that ICANN should not use its 
>>>> contractual authority to ³regulate services that use the DNS or the 
>>>> regulation of content these services carry or provide² and that 
>>>> ICANN should not attempt to establish obligations on non-contracted 
>>>> parties.² But the very commenters cited (BC, USCIB, etc.)
>>> 
>>> Do you mean to imply that more than those two did?
>>> 
>>>> also request clarification regarding ICANN¹s authority to enforce 
>>>> its contracts.  What are we to make of this?
>>> 
>>> That's misleading. They didn't make a generalised, open-ended 
>>> request for clarification that opens the door to you to construct an 
>>> entirely new principle inconsistent with the main principle.
>>> They had a proposal of their own.
>>> 
>>> BC said:
>>> 
>>> BC strongly support the proposition that ICANN should not attempt to 
>>> establish obligations on non-contracted parties. Paragraph 60 should 
>>> be clarified and we propose that it should read as
>>> follows: "ICANN shall not engage in or use its powers to attempt to 
>>> establish contractual obligations on companies with which it is not 
>>> in privity of contract and shall not attempt to establish 
>>> contractual obligations on contracted parties that are not agreed by 
>>> such parties."
>>> 
>>> Similarly, USCIB said:
>>> 
>>> Indeed, ICANN's entire multi-stakeholder structure is built on a 
>>> self-regulatory system implemented through contractual obligations 
>>> and thus ICANN can only establish contractual obligations on parties 
>>> with which it has privity through a negotiated and mutually 
>>> agreeable contract/amendment with such parties. Therefore, para 60 
>>> should be clarified and we propose that it should read as follows: 
>>> "ICANN shall not engage in or use its powers to attempt to establish 
>>> contractual obligations on companies with which it is not in privity 
>>> of contract and shall not attempt to establish contractual 
>>> obligations on contracted parties that are not agreed by such 
>>> parties."
>>> 
>>> 
>>> This new language is simply not consistent with the proposition that 
>>> ICANN should have any ability to enter into contracts with 
>>> Registries for the purpose of regulating (or controlling, or
>>> any-of-a-number-of-other-verbs) the companies who register domain 
>>> names, their business models or the content those companies carry on 
>>> their web sites. Doing any of those things would entail 
>>> "establishing contractual obligations on companies with which it 
>>> [ICANN] is not in privity of contract", which is precisely what they 
>>> say ICANN must not do.
>>> 
>>> 
>>>> With all due respect Malcolm, I will take a back seat to no one as 
>>>> a consistent and ardent defender of ICANN¹s limited mission.
>>> 
>>> Take care, Becky. You are starting to make it sound as though your 
>>> own self-image as the defender of ICANN's limited mission is getting 
>>> in the way of recognising other input with that same aim, but with 
>>> which you personally disagree.
>>> 
>>>> So I will restate the specific questions for the CCWG:
>>>> 
>>>> 1. Do you agree or disagree with the following statement: "To the 
>>>> extent that registry operators voluntarily assume obligations with 
>>>> respect to registry operations as part of the application process, 
>>>> ICANN should have the authority to enforce those commitments.²
>>> 
>>> The expressed view of these 11 commenters (including, I note, the 
>>> formal submission of the BC) clearly gives their answer to this 
>>> question as "disagree", at least inasmuch as those obligations 
>>> impose further obligations on third parties (registrants) that limit 
>>> what content they may carry or provide on their web sites and 
>>> suchlike services.
>>> 
>>> There is simply no fair reading of these 11 commenters'
>>> submissions that could answer this question as "agree", without 
>>> first adding very substantial qualifications to the generality of 
>>> your proposition.
>>> 
>>>> 2. Do you agree or disagree with the following statement:
>>>> "ICANN shall not regulate services that use the Internet's unique 
>>>> identifiers, or the content that such services carry or provide.²  
>>>> - Wherever you land, please explain what you mean by ³regulate² and 
>>>> ³services."
>>> 
>>> 9 of these 11 have said they agree, and accept the wording - so they 
>>> don't accept your suggestion that the words "regulate" or "services" 
>>> are unclear in the context used in the Draft Report.
>>> 
>>> 2 of these 11 have also said they agree, but propose alternate 
>>> wording to achieve that; you may consider this wording, quoted 
>>> above, as responsive to your question about defining "regulate"
>>> and "services".
>>> 
>>> 
>>>> I would be very interested in responses to these specific an 
>>>> limited questions.
>>> 
>>> -- Malcolm Hutty | tel: +44 20 7645 3523 Head of Public Affairs | 
>>> Read the LINX Public Affairs blog London Internet Exchange | 
>>> http://publicaffairs.linx.net/
>>> 
>>> London Internet Exchange Ltd Monument Place, 24 Monument Street, 
>>> London EC3R 8AJ
>>> 
>>> Company Registered in England No. 3137929 Trinity Court, Trinity 
>>> Street, Peterborough PE1 1DA
>>> 
>>> 
>>> _______________________________________________
>>> Accountability-Cross-Community mailing list 
>>> Accountability-Cross-Community at icann.org
>>> https://mm.icann.org/mailman/listinfo/accountability-cross-community
>>

--
>>> 
Malcolm Hutty | tel: +44 20 7645 3523
   Head of Public Affairs | Read the LINX Public Affairs blog  London Internet Exchange | http://publicaffairs.linx.net/

                 London Internet Exchange Ltd
       Monument Place, 24 Monument Street, London EC3R 8AJ

         Company Registered in England No. 3137929
       Trinity Court, Trinity Street, Peterborough PE1 1DA


_______________________________________________
Accountability-Cross-Community mailing list Accountability-Cross-Community at icann.org
https://mm.icann.org/mailman/listinfo/accountability-cross-community

=================================================================
This message is the property of Time Warner Inc. and is intended only for the use of the
addressee(s) and may be legally privileged and/or confidential. If the reader of this message
is not the intended recipient, or the employee or agent responsible to deliver it to the intended
recipient, he or she is hereby notified that any dissemination, distribution, printing, forwarding,
or any method of copying of this information, and/or the taking of any action in reliance on
the information herein is strictly prohibited except by the intended recipient or those to whom
he or she intentionally distributes this message. If you have received this communication in
error, please immediately notify the sender, and delete the original message and any copies
from your computer or storage system. Thank you.
=================================================================