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

Tue Nov 3 06:18:59 UTC 2015

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 <http://microsoft.com/> resolve to
>>> SEX.COM <http://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/254fec74/attachment.html>