[CCWG-ACCT] proposed language for Mission statement on contract enforcement

Christopher Wilkinson lists at christopherwilkinson.eu
Tue Nov 3 06:37:39 UTC 2015


Well, they are entitled to their opinion, but historically, they are mistaken.

That was the basis on which the EU bought into the ICANN concept in the first place.
Also there is clear precedent that ICANN has acted as a 'regulator' of the DNS market. e.g. structural separation, price cap, conditions of Registrar competition, etc.

CW

On 03 Nov 2015, at 07:18, Greg Shatan <gregshatanipc at gmail.com> wrote:

> I don't disagree with you Christopher.
> 
> But some people would like to avoid considering ICANN a regulator or self-regulator more broadly, which I think it can be classified as.
> 
> On Tue, Nov 3, 2015 at 1:14 AM, Christopher Wilkinson <lists at christopherwilkinson.eu> wrote:
> Greg:
> 
> We are discussing in the context of self-regulation by the industry and its users. Thus most of the economic and moral constraints of regulation fall to ICANN. Including anti-trust/competition policy.
> Unless the entity and its appurtenances (e.g. SD etc.) can be seen to abide by that principle, it will loose credibility and acceptance beyond the narrow confines of the SO/AC 'community' as presently defined.
> 
> Article 4 of the Articles of Incorporation takes precedence over the Bylaws. Whois policy conflict with the Articles of Incorporation.
> 
> Regards
> 
> Christopher
> 
> On 03 Nov 2015, at 05:14, Greg Shatan <gregshatanipc at gmail.com> wrote:
> 
>> Christopher,
>>  
>> My point is that "regulation" is the unilateral establishment of rules imposed by a regulator  -- and thus mutually exclusive of matters that are agreed to in contracts between parties.
>> 
>> You raise an interesting point though.  Do you think that Whois policy would violate a Bylaw that says that "ICANN shall not regulate services that use the Internet's unique identifiers"?  (Assuming that consensus policy is not per se exempt from being deemed "regulation...")
>> 
>> Greg
>> 
>> On Mon, Nov 2, 2015 at 12:33 PM, Christopher Wilkinson <lists at christopherwilkinson.eu> wrote:
>> Well, Greg, whether or not compliance and enforcement constitute 'regulation' depends on what is in the contract. 
>> 
>> For instance, the WHOIS requirements definitely constitute regulation (inappropriate in my view), but the alternative would also constitute regulation ('better regulation' in my view.)
>> 
>> Regards
>> 
>> CW
>> 
>> 
>> On 02 Nov 2015, at 18:14, James Gannon <james at cyberinvasion.net> wrote:
>> 
>>> This wouldn’t solve the concerns that many of us have Greg about the potential misuse of ICANNs compliance role to enforce content regulation, something that the CEO and staff are now fully in agreement with the parts of the community that have been expressing this risk for years with, as we discussed in Dublin. This merely adds the problem back into the text.
>>> 
>>> -jg
>>> 
>>> From: <accountability-cross-community-bounces at icann.org> on behalf of Greg Shatan <gregshatanipc at gmail.com>
>>> Date: Monday 2 November 2015 at 5:11 p.m.
>>> To: Dr Eberhard W Lisse <el at lisse.na>
>>> Cc: Lisse Eberhard <directors at omadhina.net>, "accountability-cross-community at icann.org" <accountability-cross-community at icann.org>
>>> Subject: Re: [CCWG-ACCT] proposed language for Mission statement on contract enforcement
>>> 
>>> Becky and all,
>>> 
>>> I think the language proposed (in blue) meets some, but not all of the concerns expressed in Dublin.  Specifically, it does, as you state, state the stage for "a new mechanism whereby registries and registrars are permitted to sign RAs and RAAs subject to a public reservation that they intend to challenge one or more specified provisions of such agreements on the grounds that the provision(s) would exceed the scope of ICANN’s Mission."
>>> 
>>> In order to meet the remaining concerns expressed in Dublin, I would propose the following further addition (in red)
>>> 
>>> ICANN shall have no power to act other than in accordance with, and as reasonably appropriate to achieve its Mission. Without in any way limiting the foregoing absolute prohibition, ICANN shall not regulate services that use the Internet's unique identifiers, or the content that such services carry or provide.  ICANN and contracted parties entering into, complying with and enforcing agreements does not constitute regulation.  In service of its Mission, ICANN shall have the ability to enforce agreements with contracted parties, subject to established means of community input on those agreements and reasonable checks and balances on its ability to impose obligations exceeding ICANN’s Mission on registries and registrars.
>>> 
>>> 
>>> I think this should meet the remaining concerns expressed in Dublin, but look forward to further comments.
>>> 
>>> Greg
>>> 
>>> On Fri, Oct 30, 2015 at 2:45 PM, Dr Eberhard W Lisse <el at lisse.na> wrote:
>>> Nigel,
>>> 
>>> don't worry he'll loose interest in the WG again soon. As usual.
>>> 
>>> el
>>> 
>>> On 2015-10-30 19:31 , Eric Brunner-Williams wrote:
>>> > Nigel,
>>> >
>>> > If your "strong argument that 'addressing the wildcard problem' was
>>> > corporate overreach" comes down to "because I said so", then I'm
>>> > satisfied that I've gotten all the information available.
>>> >
>>> > So, yes, marvelously happy now, thanks!
>>> >
>>> > Eric
>>> >
>>> >
>>> > On 10/30/15 11:27 AM, Nigel Roberts wrote:
>>> >> Articulation?
>>> >>
>>> >> "I submit that for ICANN to regulate the behaviour of DNS resolvers is
>>> >> overreaching its limited mission"
>>> >>
>>> >> Happy now?
>>> >>
>>> >>
>>> >>
>>> >> On 10/30/2015 06:21 PM, Eric Brunner-Williams wrote:
>>> >>> Nigel,
>>> >>>
>>> >>> Um, you alluded to "a strong argument that ..."
>>> >>>
>>> >>> I asked for an articulation of that "strong argument that ..."
>>> >>>
>>> >>> Your own resolver and your own network aren't quite what I expected.
>>> >>>
>>> >>> Eric
>>> >>>
>>> >>> On 10/30/15 11:07 AM, Nigel Roberts wrote:
>>> >>>> You can't guarantee uniqueness if I run my own resolver.
>>> >>>>
>>> >>>> I could make MICROSOFT.COM resolve to SEX.COM on my network if I chose
>>> >>>> so to do (obviously I don't).
>>> >>>>
>>> >>>>
>>> >>>>
>>> >>>> On 10/30/2015 05:32 PM, Eric Brunner-Williams wrote:
>>> >>>>> Nigel,
>>> >>>>>
>>> >>>>> I'm unaware of that argument. Could you point to an articulation of
>>> >>>>> it?
>>> >>>>>
>>> >>>>> You do appreciate that if resolver return values -- that is,
>>> >>>>> associations between names and addresses -- are ... unpredictable,
>>> >>>>> then
>>> >>>>> "technical co-ordination" may reasonably include allocations, of names
>>> >>>>> and addresses, with uniqueness guaranteed, but not the means of
>>> >>>>> association of names and addresses.
>>> >>>>>
>>> >>>>> Eric
>>> >>>>>
>>> >>>>> On 10/30/15 9:35 AM, Nigel Roberts wrote:
>>> >>>>>> Eric
>>> >>>>>>
>>> >>>>>> There's a strong argument that "addressing the wildcard problem" was
>>> >>>>>> corporate overreach.
>>> >>>>>>
>>> >>>>>> I know some will disagree, but it's nothing to do with the technical
>>> >>>>>> co-ordination of internet identifies, and everything to do with
>>> >>>>>> economic regulation.
>>> >>>>>>
>>> >>>>>>
>>> >>>>>>
>>> >>>>>> On 30/10/15 16:31, Eric Brunner-Williams wrote:
>>> >>>>>>> Becky,
>>> >>>>>>>
>>> >>>>>>> "shall not regulate services that use the Internet's unique
>>> >>>>>>> identifiers"
>>> >>>>>>> -- had this language been in place a decade ago how could the
>>> >>>>>>> corporation have addressed the wildcard problem? Who would be the
>>> >>>>>>> regulator(s) of monitized synthetic returns? These are things that
>>> >>>>>>> actually broke the net, and an appeal to Vixie's patch seems ...
>>> >>>>>>> well
>>> >>>>>>> ... to court risk of repetition.
>>> >>>>>>>
>>> >>>>>>> Where do we go in the future when VGRS initiates another disruptive
>>> >>>>>>> service unforeseen in contract? When the Egyptian government next
>>> >>>>>>> withdraws all prefixes can we keep the last authoritative
>>> >>>>>>> nameserver for
>>> >>>>>>> Egypt running after its data expires?
>>> >>>>>>>
>>> >>>>>>> Also, assuming for the moment that ICANN currently exercises
>>> >>>>>>> delegated
>>> >>>>>>> rule making authority, if ICANN explicitly abandons this authority,
>>> >>>>>>> does
>>> >>>>>>> that authority revert to the delegating agency?
>>> >>>>>>>
>>> >>>>>>> If I may, to regulate, or not regulate, stub-, recursive- and
>>> >>>>>>> authoritative-resolvers and their resolutions via port 53 of
>>> >>>>>>> delegated
>>> >>>>>>> name spaces to allocated address spaces, is more on-point, and
>>> >>>>>>> vastly
>>> >>>>>>> narrower, than "services that use ..."
>>> >>>>>>>
>>> >>>>>>> Eric
>>> >>>>>>>
>>> >>>>>>> On 10/30/15 6:19 AM, Burr, Becky wrote:
>>> >>>>>>>>
>>> >>>>>>>> In Dublin we discussed, both in our working meetings and over two
>>> >>>>>>>> brown bag lunches, an approach to addressing concerns about the
>>> >>>>>>>> Mission Statement prohibition on regulation of services that use
>>> >>>>>>>> the
>>> >>>>>>>> Internet’s unique identifiers, or the content that such services
>>> >>>>>>>> carry
>>> >>>>>>>> or provide.  The following language (in blue) is proposed to
>>> >>>>>>>> address
>>> >>>>>>>> this concern:
>>> >>>>>>>>
>>> >>>>>>>> ICANN shall have no power to act other than in accordance with,
>>> >>>>>>>> and as
>>> >>>>>>>> reasonably appropriate to achieve its Mission. Without in any way
>>> >>>>>>>> limiting the foregoing absolute prohibition, ICANN shall not
>>> >>>>>>>> regulate
>>> >>>>>>>> services that use the Internet's unique identifiers, or the content
>>> >>>>>>>> that such services carry or provide.  In service of its Mission,
>>> >>>>>>>> ICANN
>>> >>>>>>>> shall have the ability to enforce agreements with contracted
>>> >>>>>>>> parties,
>>> >>>>>>>> subject to established means of community input on those agreements
>>> >>>>>>>> and reasonable checks and balances on its ability to impose
>>> >>>>>>>> obligations exceeding ICANN’s Mission on registries and registrars.
>>> >>>>>>>>
>>> >>>>>>>> What we discussed (over the lunches) as a reasonable check and
>>> >>>>>>>> balance
>>> >>>>>>>>  (in addition to existing mechanisms such as public comment,
>>> >>>>>>>> etc.) is
>>> >>>>>>>> a new mechanism whereby registries and registrars are permitted to
>>> >>>>>>>> sign RAs and RAAs subject to a public reservation that they
>>> >>>>>>>> intend to
>>> >>>>>>>> challenge one or more specified provisions of such agreements on
>>> >>>>>>>> the
>>> >>>>>>>> grounds that the provision(s) would exceed the scope of ICANN’s
>>> >>>>>>>> Mission.   This mechanism will need to be developed.
>>> >>>>>>>>
>>> >>>>>>>>
>>> >>>>>>>>
>>> >>>>>>>>
>>> >>>>>>>> J. Beckwith Burr
>>> >>>>>>>> Deputy General Counsel & Chief Privacy Officer
>>> >>>>>>>>
>>> >>>>>>>>
>>> >>>>>>>>
>>> >>>>>>>> _______________________________________________
>>> >>>>>>>> Accountability-Cross-Community mailing list
>>> >>>>>>>> Accountability-Cross-Community at icann.org
>>> >>>>>>>> https://mm.icann.org/mailman/listinfo/accountability-cross-community
>>> >>>>>>>>
>>> >>>>>>>
>>> >>>>>>>
>>> >>>>>>>
>>> >>>>>>> _______________________________________________
>>> >>>>>>> Accountability-Cross-Community mailing list
>>> >>>>>>> Accountability-Cross-Community at icann.org
>>> >>>>>>> https://mm.icann.org/mailman/listinfo/accountability-cross-community
>>> >>>>>>>
>>> >>>>>> _______________________________________________
>>> >>>>>> Accountability-Cross-Community mailing list
>>> >>>>>> Accountability-Cross-Community at icann.org
>>> >>>>>> https://mm.icann.org/mailman/listinfo/accountability-cross-community
>>> >>>>>>
>>> >>>>>>
>>> >>>>>>
>>> >>>>>
>>> >>>>> _______________________________________________
>>> >>>>> Accountability-Cross-Community mailing list
>>> >>>>> Accountability-Cross-Community at icann.org
>>> >>>>> https://mm.icann.org/mailman/listinfo/accountability-cross-community
>>> >>>>>
>>> >>>> _______________________________________________
>>> >>>> Accountability-Cross-Community mailing list
>>> >>>> Accountability-Cross-Community at icann.org
>>> >>>> https://mm.icann.org/mailman/listinfo/accountability-cross-community
>>> >>>>
>>> >>>>
>>> >>>>
>>> >>>
>>> >>> _______________________________________________
>>> >>> Accountability-Cross-Community mailing list
>>> >>> Accountability-Cross-Community at icann.org
>>> >>> https://mm.icann.org/mailman/listinfo/accountability-cross-community
>>> >>>
>>> >> _______________________________________________
>>> >> Accountability-Cross-Community mailing list
>>> >> Accountability-Cross-Community at icann.org
>>> >> https://mm.icann.org/mailman/listinfo/accountability-cross-community
>>> >>
>>> >>
>>> >>
>>> >
>>> > _______________________________________________
>>> > Accountability-Cross-Community mailing list
>>> > Accountability-Cross-Community at icann.org
>>> > https://mm.icann.org/mailman/listinfo/accountability-cross-community
>>> 
>>> 
>>> _______________________________________________
>>> Accountability-Cross-Community mailing list
>>> Accountability-Cross-Community at icann.org
>>> https://mm.icann.org/mailman/listinfo/accountability-cross-community
>>> 
>>> 
>>> _______________________________________________
>>> 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/accountability-cross-community/attachments/20151103/250a1d98/attachment.html>


More information about the Accountability-Cross-Community mailing list