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

[Cheryl Langdon-Orr]

I think Paul raises an important point re the term "supports", so would
also be interested in other words to strengthen the intent whilst
respecting the concern of IAB
On 1 Nov 2015 07:32, "Paul Twomey" <paul.twomey at argopacific.com> 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/accountability-cross-community/attachments/20151101/749cbf7e/attachment.html>