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

Nigel Roberts nigel at channelisles.net
Fri Oct 30 18:07:42 UTC 2015


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
>



More information about the Accountability-Cross-Community mailing list