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

Eric Brunner-Williams ebw at abenaki.wabanaki.net
Sun Nov 1 00:30:28 UTC 2015


Paul,

I think you are correct to be concerned, though I would prefer to ask 
how a more typical claim is analyzed by the courts. The quote below is 
from Name.Space v ICANN, from this year. The section is III. Sherman Act 
§ 1, para 5:
> ICANN was not required to replicate the 2000 Application Round in 
> 2012, or even to create new TLDs. The application rules served to 
> ensure that those who obtained new TLDs would be financially stable. 
> This is a perfectly logical decision, and one that ICANN, through its 
> contract with the DOC, had full authority to make.

The last line in that para is the kicker -- absent that contract with 
the DoC, where does ICANN's authority arise from?

Eric



On 10/31/15 4:41 PM, Paul Twomey wrote:
>
>
> Why this may be important, is that judges have previously relied on 
> the IANA contract with the US Department of Commerce to outline the 
> authority under which the rules ICANN has put forward should be 
> honoured  (See 
> http://www.leagle.com/decision/In%20FDCO%2020150105808/STERN%20v.%20THE%20ISLAMIC%20REPUBLIC%20OF%20IRAN) 
> [ NB I do NOT want to start any discussion about any country.  The 
> case is relevant only for the Judge's rationale of authority]
>
> Without the IANA contract, judges will continue to look for 
> rationale's about ICANN's authority in making rules about the DNS on 
> which they can rely.
>
> That is why I am concerned that we do not weaken this.   I am not 
> talking here about hard black letter/constitutional line of authority 
> - the type about which Nigel is asking.   I am talking about having in 
> place proclamations of expertise and 'real world' authority which 
> allows judges to say "I am going to agree with ICANN's view of the DNS 
> world".
>
> I would note that there are over 200  decisions of US appellate courts 
> which implicitly refer to ICANN is a way similar to the one I have 
> mentioned above. (see: 
> http://www.leagle.com/leaglesearch.html?allwords%3D%26exactphrase%3DICANN%26anyword%3D%26withoutword%3D%26qsearchsubmit%3D1)
>
> Best
>
> Paul
>
> On 11/1/15 9:28 AM, 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/e48992af/attachment.html>


More information about the Accountability-Cross-Community mailing list