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

[Eric Brunner-Williams]

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
>
>
>