Ms Fiona M Alexander, Associate Administrator, Office of International Affairs, National Telecommunications and Information Administration, 1401 Constitution Avenue, NW., Room 4701, Washington, DC 20230 United States of America Federal Register/Vol 76, No 38 2011-02-25 2011-03-30 Request for Comments on the IANA Functions Dear Ms Alexander On behalf of the Namibian Network Information Centre (NA-NiC), the manager of the ccTLD .NA, of which I am the principal, I herewith respectfully submit our response to your Notice of Inquiry As per your instructions I have enclosed an ASCII version of our input, and for ease of reference same in PDF (as I do not use either of the proposed commercial word processing packages). In the paragraph SUPPLEMENTARY INFORMATION: you refer to a series of contracts between the Department of Defense‚'s Advanced Research Projects Agency (DARPA) and the University of Southern California (USC), as part of a research project known as the Terranode Network Technology (TNT) from which apparently the US Government purports to derive authority over what is known as the Top Level Domain names, including the country code Top Level Domain (ccTLD) names. I assume you refer to the contract DABT63-09-C-0095 and would like to point out, that its name was Tera-node Network Technology, and assume that it is a spelling error on your part. With regards to the Tera-node Network Technology contract purporting to serve as foundation of the USG's claim to have authority over TLDs registered during Mr Postel's life time in particular, DABT63-09-C-0095 can obviously not serve as foundation of the USG's claim over any TLD having been registered prior to the awarding of this contract. I do not wish to comment at this point in time on whether it can serve as foundation for this claim over TLDs after having been awarded, but do reserve all rights in this regards. The uncertainty of what a TLD and in particular a ccTLD actually is, is most troubling. Not being a lawyer myself, it is however obvious that it is some form of intangible property. As such it must be owned (in the legal sense) by someone. If it were owned by the US Government, I assume that there are procedures and policies in place that regulate alienation of assets of the federal government which thus would apply here. If owned by a second party, the US Government can, of course, not dispose of it, per se, nor can a third party, such as a contractor. The issues of intellectual property having developed by TLD managers also need to be solved as a matter of urgency, prior to any change in the status quo of any TLD. Permit me then to draw your attention to footnote 4: Performance of this function in relation to country code top level domains (ccTLDs) has evolved over time to address specific issues, one of which has been how best to respect the legitimate interests of governments in the management of their respective ccTLD within the current model. As there are few if any documents published with regards to this particular evolution (but also others), thus inhibiting any assessment of performance of the current contractor, the Internet Corporation for Assigned Names and Numbers, I request that you kindly publish and/or forward the pertinent documentation you base the above statement on, as a matter of urgency, to enable us to make additional comments if required, and extend the deadline for responses thereto accordingly. With regards to your specific questions, hereinafter quoted in full: 1. The IANA functions have been viewed historically as a set of interdependent technical functions and accordingly performed together by a single entity. In light of technology changes and market developments, should the IANA functions continue to be treated as interdependent? For example, does the coordination of the assignment of technical protocol parameters need to be done by the same entity that administers certain responsibilities associated with root zone management? Please provide specific information to support why or why not, taking into account security and stability issues. The main reason why the functions commonly called the IANA functions are bundled together is historical, they were performed by a single individual, Mr Postel during his life time, evolving over time. They are however, entirely distinct and separate functions and there is no technical necessity to keep them bundled to be performed by a single entity. In addition, since IP addresses are allocated by the RIRs, and protocols are developed by the IETF, and both have performed admirably over the years, these functions should in fact be separated from root zone management. 2. The performance of the IANA functions often relies upon the policies and procedures developed by a variety of entities within the Internet technical community such as the IETF, the RIRs and ccTLD operators. Should the IANA functions contract include references to these entities, the policies they develop and instructions that the contractor follow the policies? Please provide specific information as to why or why not. If yes, please provide language you believe accurately captures these relationships. Even if one does not follow my argument for separating these functions, it does make sense to bind the contractor to these policies, in particular since the processes of those entities for developing their policies have proven themselves over many years. Especially if regard is had to ccTLD operators, a contractual obligation of the contractor to abide by the principles I outline in my response to the next question, would be very wise. 3. Cognizant of concerns previously raised by some governments and ccTLD operators and the need to ensure the stability of and security of the DNS, are there changes that could be made to how root zone management requests for ccTLDs are processed? Please provide specific information as to why or why not. If yes, please provide specific suggestions. Notwithstanding my objections regarding the authority being asserted over TLDs, in particular those registered prior to the awarding of the Tera-node contract, - the contractor must respect all established rights and legitimate expectations of all incumbent TLD managers; and - the contractor must not act unilaterally under any circumstances unless there is a clear and present danger to the stability of the Internet or there is serious misconduct on the part of the incumbent TLD manager; and - the contractor must abide by fundamental principles such as fairness, equality, predictability, transparency and subsidiarity, in all its dealings with third parties. A useful document in this regard is RFC 1591 and efforts are underway within the ccNSO to establish a framework for interpretation thereof. Though this can not bind those ccTLD operators which are not members of the ccNSO I expect that many will accept such a framework, provided the contractor abides by it as well. 4. Broad performance metrics and reporting are currently required under the contract. Are the current metrics and reporting requirements sufficient? Please provide specific information as to why or why not. If not, what specific changes should be made? As outlined before, predictability of performance is more important than the measuring and reporting of it. As far as requests for .NA are concerned I have had no major issues with responsiveness to requests by the current contractor, however this may be different for other, in particular large TLDs. 5. Can process improvements or performance enhancements be made to the IANA functions contract to better reflect the needs of users of the IANA functions to improve the overall customer experience? Should mechanisms be employed to provide formalized user input and/or feedback, outreach and coordination with the users of the IANA functions? Is additional information related to the performance and administration of the IANA functions needed in the interest of more transparency? Please provide specific information as to why or why not. If yes, please provide specific suggestions. As multiple implementations of registration systems have been developed all over the world, it is not really understandable why the root zone management has not been automated by the incumbent contractor. In particular if regard is had to the enormous budget it has and the extravagances committed by its management. An automated zone register would take care of issues such as formalized user input/feedback, outreach and coordination at the same time. However, with regards to transparency, and I must disclose a potential conflict of interest here, as having been a member of the ccNSO's Delegation Re-Delegation and Deletion Working Group, the report of which has been submitted to you already, and speaks for itself, there is hardly any. 6. Should additional security considerations and/or enhancements be factored into requirements for the performance of the IANA functions? Please provide specific information as to why or why not. If additional security considerations should be included, please provide specific suggestions. Automation of the root zone management process would incorporate additional security by definition, but one wonders why public/private key signatures such as PGP for example, have not been employed already. From the above it also follows that the operator of the IANA function, whichever entity, should implement but not set or develop the policy it operates under. With Kind Regards