[CCWG-ACCT] Please review regarding IAB comments on Mission Statement

Sun Nov 1 00:38:15 UTC 2015

Stephen,

See 
http://law.lclark.edu/law_reviews/lewis_and_clark_law_review/past_issues/volume_06/, 
in particular the exchange of papers between Joe Sims and Cynthia L. 
Bauerly, writing for Jones Day, and Michael Froomkin, and of course 
Michael's book-length paper on the subject, at 
http://papers.ssrn.com/sol3/papers.cfm?abstract_id=252523

Eric

On 10/31/15 3:28 PM, Stephen Deerhake wrote:
> +1 to Nigel's remarks.
>
> As Nigel asks, can anyone within or outside of ICANN and the ICANN Community
> actually point to the underlying fundamental legal foundation that props all
> this up?
>
> Stephen Deerhake
>
> -----Original Message-----
> From: accountability-cross-community-bounces at icann.org
> [mailto:accountability-cross-community-bounces at icann.org] On Behalf Of Nigel
> Roberts
> Sent: Saturday, October 31, 2015 5:38 PM
> To: accountability-cross-community at icann.org
> Subject: Re: [CCWG-ACCT] Please review regarding IAB comments on Mission
> Statement
>
> Paul makes some interesting tactical points.
>
> But can you point to ANY legal foundation where ICANN actually IS a "primary
> head of power"???
>
>
>
> On 10/31/2015 08:32 PM, Paul Twomey wrote:
>> Becky
>>
>> I think the points made by Malcolm and the IAB make a lot of sense when
>> viewed from the perspective of the engineering/technical community.
>>
>> But I would observe that the wording will interpreted with most impact
>> on daily work of the ICANN community not by non technical entities, but
>> particularly by the courts in various lands and the ongoing
>> international "politics of technology" processes.   When I look at the
>> proposed wording from that perspective, I worry that shifting to
>> "support" in the Mission statement could result in destabilising
>> uncertainty.   As we have seen in various litigation (to give only one
>> example, litigation about trying to get TLDs recognized as property
>> which the Courts can order moved from one party to another), the ability
>> for the Judge's not to have any doubt as to the primacy of the ICANN
>> (including community) role in determining the general rules/approach in
>> this area has been important.
>>
>> It could be destabilising if we leave the impression in the
>> politico/legal arena that ICANN only plays a supporting role, and that
>> they can go looking for another primary head of power.
>>
>> I admit I am writing this from something of a paranoid view, but then I
>> do have sympathy with Andy Grove's observation that only the paranoid
>> survive.
>>
>> I can also understand why the IAB questions the operational accuracy of
>> the use of the term "coordinates" in the opening sentence of the Mission
>> Statement as it now stands.
>>
>> Is there a way of getting a more robust term than just "support"?
>>
>> Paul
>>
>> Paul Twomey
>>
>> On 10/31/15 11:52 PM, Malcolm Hutty wrote:
>>> Becky,
>>>
>>> Thank you for bringing forward this proposal from the IAB.
>>>
>>> I think we should support the intent here. I do, however, have a concern
>>> about one aspect of the implementation.
>>>
>>> The main overall effect of this proposal, and I believe its intent, is
>>> to limit the statement of ICANN's Mission so that it more closely
>>> reflects what is empirically ICANN's role today.
>>>
>>> Existing text states that ICANN's Mission is to ""coordinate, at the
>>> overall level, the global Internet's system of unique identifiers", and
>>> then goes on to says that "In particular", ICANN does certain things
>>> regarding each of DNS, IP addresses and AS numbers, and protocol
> parameters.
>>> The proposed text states that ICANN's mission is to "support, at the
>>> overall level, core Internet registries".
>>>
>>> The change of verb, from "coordinate" to "support" seems to me to be a
>>> good change: ICANN supports DNS, IP addressing and protocol parameters
>>> in different ways, and the verb "co-ordinate" might wrongly suggest
>>> responsibilities for ICANN that it does not have. For example, ICANN
>>> does not in fact have change control authority over protocol parameters;
>>> that lies with the IETF, and ICANN's role is to publish registries of
>>> those parameters. Changing from "co-ordinate" to "support" more
>>> accurately reflects this.
>>>
>>> On the other hand, the change of object from "the global Internet's
>>> system of unique identifiers" to "core Internet registries" is a
>>> broadening of scope.
>>>
>>> I am not sure what the limits of the scope of "core Internet registries"
>>> is intended to be. Is a broadening of scope beyond the current text
>>> intentional? If so, I would like to know the rationale.
>>>
>>> We need to be aware that future technologies might result in the
>>> creation of new registries yet to be invented. I'm not sure we want
>>> those to be automatically invested in ICANN.
>>>
>>> Speaking as someone from the network operator community, it's not at all
>>> obvious to me that ICANN would necessarily be the obvious repository for
>>> some future registry that was used operationally (that is, one consulted
>>> in "run-time", as with the DNS or the global routing table, as opposed
>>> to one consulted at software design time, as with (most? all?) IETF
>>> protocol parameters). We might instead look to the Regional Internet
>>> Registries, or to some other entity or, as with the routing table, it
>>> might be distributed.
>>>
>>> Even if we did wish to invest ICANN with responsiblity for such a future
>>> registry, the nature of that responsibility might need to be carefully
>>> defined and limited, just has been done with DNS and with IP addresses.
>>> If we exclude such new registries from the scope of ICANN's Mission now,
>>> they could still be taken on later but to do so would require a
>>> Fundamental Bylaws change; such a process would give an opportunity for
>>> careful scrutiny and development of precisely what ICANN's role in
>>> relation to that registry ought to be. On the other hand, if we now
>>> decide that such a future registry is automatically ICANN's
>>> responsibility, then a very different process will determine how ICANN
>>> relates to it, a process that could result in ICANN undertaking a
>>> function for which there is no current analogy, and without requiring
>>> the positive consent of the community.
>>>
>>> In summary, before expanding ICANN's role beyond "the global Internet's
>>> system of unique identifiers", I think we should hear why that is
>>> needed, and carefully consider whether there might be inadvertent
>>> consequences. When we hear the rationale, it might be possible to
>>> accommodate it in other ways.
>>>
>>> If the rationale is nothing more than that the IETF fears that some of
>>> its protocol parameters registries could not be described as "globally
>>> unique identifiers", a more tailored solution is surely available. We
>>> could simply authorise ICANN to publish registries of protocol
>>> parameters when requested to do so by the IETF, or by protocol
>>> development bodies generally. That would be much simpler, and the
>>> opportunity for inadvertent consequences would be greatly reduced.
>>>
>>> Malcolm.
>>
>>
>> _______________________________________________
>> 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 --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/accountability-cross-community/attachments/20151031/7e0f60d2/attachment.html>