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

[Eric Brunner-Williams]

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