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.