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

[Dr Eberhard W Lisse]

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 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
>>
>>
>>
> 
> _______________________________________________
> Accountability-Cross-Community mailing list
> Accountability-Cross-Community at icann.org
> https://mm.icann.org/mailman/listinfo/accountability-cross-community

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4218 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://mm.icann.org/pipermail/accountability-cross-community/attachments/20151030/5779d15b/smime.p7s>