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

[Burr, Becky]

Would be great to hear from someone at IAB regarding the proposed change
to ³core Internet registries²

J. Beckwith Burr
Deputy General Counsel & Chief Privacy Officer





On 10/31/15, 8:52 AM, "Malcolm Hutty" <malcolm at linx.net> 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.
>-- 
>            Malcolm Hutty | tel: +44 20 7645 3523
>   Head of Public Affairs | Read the LINX Public Affairs blog
> London Internet Exchange |
>https://urldefense.proofpoint.com/v2/url?u=http-3A__publicaffairs.linx.net
>_&d=CwIF-g&c=MOptNlVtIETeDALC_lULrw&r=62cJFOifzm6X_GRlaq8Mo8TjDmrxdYahOP8W
>DDkMr4k&m=jT_nQ1EhVIl4advUcqbMy1s_aK--9Svo487NWn8CZ98&s=MrXWcVrhUtBGHtpkfo
>ISiiXmUxpRsJt_lr3doZW2JX0&e=
>
>                 London Internet Exchange Ltd
>       Monument Place, 24 Monument Street, London EC3R 8AJ
>
>         Company Registered in England No. 3137929
>       Trinity Court, Trinity Street, Peterborough PE1 1DA
>
>