Heidi, Thanks for the reminder. I can't find the earlier draft that I set aside so this is from memory. 1. The set of functions exercised by the IANA ("the IANA function") may be safely separated into those which relate to protocol assignment, those which relate to iso3166 delegations, those which relate to ICANN registry agreements (contracts), and those which relate to zone file management. There is no inherent necessity for the protocol assignment function to be contained in a single common contractual basket. Changes in the support for the IAB, as well as the IESG, and the resources available to ISOC, suggest that separation of the protocol assignment function is overdue. There is limited utility in the 3166 delegation liaison function, or the contracted delegation liaison function, to be contained in a single common contractual basket. These are registry-specific functions, closely related to the respective existing ICANN liaison functions, structured outside of the IANA function. The zone file management function, including key management, could be exercised by the NTIA, or by Verisign, as well as, or better than, by ICANN. 2. The management of assigned numbers has changed substantially from the point in time when the new entity was designated, and v4 allocations have entered a scarcity regime. There is little necessity, and apparently no utility, in the Assigned Numbers function being contained in a single common contractual basket. 3. The operation of a root name server is not in ICANN's set of core competencies, it is a technical, not a contractual, function. Further, there is a policy requirement to diversify the current root name server operators. At present only the I, K, and M root servers are operated outside the jurisdiction of the United States. Transfer of the L root server to a competent operator outside of North America and Europe would be responsive to that operational and policy diversity of authority requirement. Eric