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

Nigel Roberts nigel at channelisles.net
Fri Oct 30 18:27:25 UTC 2015


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
>



More information about the Accountability-Cross-Community mailing list