Comments

Please find my comments on the IANA Function NoI attached as both Word (.doc) and as a PDF. I prefer that the PDF rather than the .doc be posted to the comments location because it is easier for most people to view.

Please accept the following comments in response to the Notice of Inquiry regarding IANA functions(1). Go Daddy reserves the right to future comments on this issue and our positions include, but are not necessarily limited to, the text herein.

OVERVIEW
In general, we are satisfied with the current procurement of IANA functions and the incumbent operator. We would, however, encourage the NTIA to consider additional enhancements to IANA functions, as described below.

Additionally, we do not believe there are dependencies that require all IANA functions to be provided by a single operator, nor are there compelling reasons to divide these functions. This arrangement is purely a matter of NTIA policy and community consensus.

Furthermore, we do not believe that any significant changes, such as separating IANA functions, changes to the procurement process, selecting a new IANA operator, or permanent assignment of the IANA contract should be undertaken so early in the Affirmation of Commitments lifecycle. The reviews prescribed in the AoC could inform such changes, and completing this work is therefore critical before any substantial changes are considered.

ENHANCING ROOT ZONE MANAGEMENT
The IANA Operator's management of Root Server operators can be characterized as good, but inconsistent. Because the Root Server System is critical to the operation of the Internet, we encourage the IANA operator to formalize its relationships with Root Server operators. All operators should be transitioned to a standard agreement, which includes a Service Level Agreement (SLA). Additionally, we note that Root Server operators are in a position to collect and aggregate traffic statistics that may have significant commercial value. Root Server operator agreements should prohibit this practice.

The ongoing deployment of DNSSEC is a technically and operationally complex project, and we believe that the IANA operator has functioned well in its role. We anticipate expanded DNSSEC deployment and adoption going forward.

NUMBER RESOURCE ASSIGNMENTS
In this functional area, the primary topic is the transition from IPv4 to IPv6. The IANA operator has performed satisfactorily in this area, but we note with concern that the increased scarcity of IPv4 address space is creating a market for unused blocks. We would prefer to see these returned to the Regional Internet Registry (RIR).

MANAGEMENT OF .ARPA AND .INT
Ideally, the IANA operator would not be engaged, either temporarily or indefinitely, in the direct management of any TLDs. The two existing examples of this, however, do not present any immediate concerns.
However, with the expectation that dozens or hundreds of new gTLDs will be delegated in the next 1-2 years, we would caution against contingency planning that involves direct management of failed gTLDs by the IANA operator.

CONCLUSION
In most cases, we support the existing procurement arrangement, and would like to see some specific enhancements in the areas mentioned above. And while we have numerous concerns with ICANN, and do not believe that the IANA contract should be assigned to them on a permanent basis, we do support private sector leadership and maintain that it is the most appropriate IANA Contract operator. We appreciate the opportunity to share our thoughts on this procurement process, and will continue to work within the larger community to improve and enhance the critical functions of the Internet.

Sincerely,
GoDaddy.com, Inc.

Tim Ruiz
Vice President
Corporate Development and Policy
GoDaddy.com, Inc.

Asia Pacific Top Level Domain Association (APTLD) is a membership based organisation for ccTLD (country-code Top Level Domain) registries in the Asia Pacific region. APTLD was informally established in 1998, and in 2003 legally established as a membership society incorporated in Malaysia. APTLD works as the forum of information exchange regarding technological and operational issues of domain name registries for ccTLDs.. Also, APTLD acts as an interface to other international Internet coordinating bodies including Internet Corporation for Assigned Names and Numbers (ICANN), APNIC and the Internet Engineering Task Force (IETF). APTLD fosters and elevates participation of AP ccTLDs in these global fora, as well as acting in the best interest of APTLD members in global Internet policy development processes.

Currently, APTLD has 60-odd members in total; including 36 AP based ccTLDâ€™s..

Comments

APTLD welcomes the opportunity to provide comments in response to the National Telecommunications and Information Administrationâ€™s (NTIAâ€™s) Notice of Inquiry on the IANA functions. APTLD shares and supports NTIAâ€™s commitment to preserving the security and stability of the DNS. At the same time, we echo NTIAâ€™s view that the security and stability of the DNS are a shared responsibility among all stakeholders in the Internet community, nevertheless, we are of the view that the topic of reform and possible separation of IANA functions should be approached with caution and extensive stakeholder consultations, in order to avoid unintended fragmentation and disruption of the current services.

APTLD conducted a survey among its members specifically for this NoI. Our comments on the questions raised in the NoI are largely based on the survey results.

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.

APTLD recommends NTIA take a most cautionary approach to this issue. There are merits to having a single entity performing the IANA functions, and avoiding overcomplicating the process. APTLD appreciates the historical reasons behind having a single entity to perform a range of interdependent technical functions.

APTLD agrees there are 4 distinctly different categories included in the IANA function, namely the database management of the root zone file for ccTLDs, gTLDs, IP addresses, and the fourth area of technical databasing such as that required for .arpa and IETF purposes. From the technical perspective, the updating and maintenance of the IANA database is potentially best provided by a single operator and under the ICANN umbrella the IANA technical functions appear to be operating moderately efficiently and effectively and APTLD notes ongoing improvements in IANA services. APTLD recommends that there should be a clear distinction between the technical IANA function and the policy development processes required to provide the necessary guidelines for the IANA function. Some of the policy processes are discreet to the individual 4 areas in which IANA functions, and some are intertwined across these 4 areas.

APTLD suggests that if ICANN is able to demonstrate a clear separation and distinction between the policy development processes and the IANA technical functions, whereby all affected stakeholders are involved in the policy development processes, then some greater autonomy from the US Government for ICANN to manage IANA functions would be appropriate. To elaborate, for example, within ICANN the ccNSO is accorded the responsibility for the development of policies applicable to the ccTLDs who are members and such policy function should be performed by ccNSO clearly separated from IANA functions. However less than half of the ASCII ccTLDs are members of ICANNs ccNSO, and therefore any policy development affected the ccTLD world must include ccTLDs both within and outside of the ccNSO. APTLD would further suggest that increased independence from the US Government for IANA would be appropriate for the ccTLD community,

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.

In accordance with the multi-stakeholder approach advocated by the ICANN and generally accepted by the entire global Internet community, APTLD recommends that references should be made to the policies developed by the ccTLD community in the IANA functions contract. The IANA contractor should acknowledge that polices developed by the ccTLDs are legitimate and relevant in their respective local Internet communities and governments, and consistent with the U.S. Principles on the Internet's Domain Name and Addressing System.

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.

In view of the introduction of the DNSSEC and new TLDs, the automation of processes relating to IANAâ€™s root zone management would certainly improve the efficiency of routine zone management changes, and should be given the highest priority.

DNSSEC deployment has introduced a severe timing issue to the root zone management that may affect the TLD zone visibility on the Internet. For example, if a TLD registry put a wrong DS record value in the root zone, such TLD zone disappears from the Internet. In such a case, such DS record should be deleted immediately by the root zone management following the urgent demand by the TLD operator. Such process should not be intervened by non-automated process to achieve the immediate consequence. As in this case, secured, immediate, and automated root zone management function is mandatory.

APTLD notes that within the ccNSO a working group has been formed to provide a Framework of Interpretation for the delegation and redelegation of ccTLDs that will help significantly to make these processes more transparent. With this process underway we see no need at this juncture for the NTIA to consider an alternate policy development entity to ICANN to address the shortcomings in the treatment of ccTLDs in regard to the critical issues surrounding delegations and redelegations.

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?

About half of the APTLD members found the IANA performance to be acceptable in terms of process and timeframe. Nevertheless, APTLD supports the development of a service level agreement for the IANA services that includes the framework parameters and timelines. The agreement should be accompanied by detailed documentation that explains the root zone management functions. However, APTLD suggests avoiding the implementation of an overly complicated and bureaucratic reporting regime of the IANA functions.
Furthermore, maintaining an up-to-date website on the requirements of the various services provided by IANA is crucial to the further speed of the services provided.

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.

APTLD members are generally satisfied with the feedback and coordination mechanism of the IANA. Reiterating our comments to question 4, documentation should be provided by IANA detailing the functions, framework parameters and timelines for better predictability and transparency of the IANA processes.

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.

APTLD members are of the view that better authentication process should be introduced to the receipt and management of the change requests, as email authentication is inadequate We also suggest periodic auditing of the security provisions of the IANA function by external, independent, specialised auditors against a relevant international standard. Also a documented urgency process for customers to follow if they are experiencing an emergency, which includes private emergency contact numbers for the operator to be contacted on.

Furthermore, APTLD contests that it is an essential development for IANA to have a published disaster recovery plan, that is regularly consulted upon.

APTLD thanks the NTIA for providing the opportunity to input into the future of the IANA function.

Attached please find the comments of the Coalition for Online Accountability (COA) in response to the Notice of Inquiry published Feb. 25, 2011. The comments are attached both in MS Word format, in accordance with the Federal Register notice, and as a PDF file. Please contact the undersigned with any questions or for more information. Thank you in advance for considering the views of COA.

Find attached the IAB's response to the Request for Comments on the Internet Assigned Numbers Authority (IANA) Functions (Docket No. 110207099â€“1099â€“01). The IAB is available should you have further questions or seek clarification.

Attached the Swiss response to your inquiry regarding the future of the IANA
function. It is a joint document submitted to you by the Swiss Federal
Office of Communications (OFCOM) and SWITCH, the Swiss registry for .CH
domain names. Hard copy and diskette follow by postal mail. Thank you very
much for the opportunity to comment.

Best regards,

Marcel Schneider
Mgr. Special Operations and International Relations
SWITCH

Please find attached, in both .doc & .pdf formats, the response by the Government of Egypt to the Department of Commerce National Telecommunications and Information Administration [Docket No. 110207099â€“1099â€“01] RIN 0660â€“XA23: Request for Comments on the Internet Assigned Numbers Authority (IANA) Functions.

As you undertake your evaluation of the IANA functions contract, I would like to bring your attention to the following recently completed ICANN Working Group (WG) document on the question of Delegation and Re-delegation of country code top-level (ccTLD) domains:

â€œFinal Report of the Delegation, Re-delegation and Retirement Working Group of the ccNSOâ€

Comments (submitted as an Individual) in response to the Notice of Inquiry issued by the National Telecommunications and Information Administration of the U.S. Department of Commerce on the Internet Assigned Numbers Authroity (IANA) functions

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.

It is a good idea to continue to have all the IANA fucntions performed together by a single entity to preserve the Internet as a unified network of networks. The present funcitons of IANA are central and critical to the funcitoning of the Internet and it is not wise to distribute these core functions among mutltiple entities, which could cause interorganizational communication latencies and larger (or at least subtle) coordination issues, which are to be avoided for the smooth functioning of the Internet.

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.

This process of including references to various entities has to ensure enromous care in identifying the entities for this purpose, to start with. It is important to ensure that the IANA embraces only those policies that are developed by the traditional Internet Technical Community which is a community free of direct and indirect commercial links in the business of communication and a community that remains free of political aspiration for enhanced commercials ends. The Internet Technical Community is the one driven by a passion to contribute more and more to the evolution of the Internet while the unfathomable commercial potential of the Internet has caused Commercial entities to aspire for control of the Internet Standards process. Internet, at its core, is a community process driven by a desire to continue its evolution as a free, open, accessible and universal medium beyond barriers. The Technical Community including the IETF continuously contribute to the Internet and their role and contribution has been central and significant. It would be fair to make a reference to the policies and standards developed by the Internet Community with a strong recommendation that the policies be largely embraced as developed and where there are is a compelling need felt to alter developed policies IANA could request review of componets of the policy.

The policies developed by RIR's as regional organs could be considered as policies peculiar to the respective regions to be respected as long as the regional policies are broadly in tune with Global Polies, and where the RIRs propose policies that extend beyond one region, the policies could be treated as regional inputs at mid-level of the bottom up policy making process of the IANA functions.

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.

I am not familiar with the inside workings of the process of handling root zone management requests. At the same time, my general suggestion is that the technical policies and processes for root zone management of ccTLDs should be the same as that of gTLDs. Except for the essential differences in category, that of a gTLD being global and a ccTLD being national, and for the differences in the process of delegation, there ought not to be any technical separation of ccTLDs from gTLDs in the root zone or in the DNS.

Broad performance metrics and reporting are currently required under the contract.7 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?

The current performance metrics and reporting requirements appear to have been drafted based on templates of Government Contracts for general purchase of goods and services rather than a contract drafted for the unique situation of an independant organization that is part of a non-commercial corporation with a multi-stakeholder governance model carrying out the Number functions for the global Internet. The terminology â€œcost contractâ€ at â€œno costs to the US Governmentâ€ and â€œthe contractor receives no feesâ€ does not fit in at all.

The reporting requirements also appear to come from a Government contract modalities and procedures, rather than from the realities and the uniques needs of the IANA functions.

The emphasis could instead be on checks and balances, rather than on forms and paperwork. (The inspiration for the idea of checks and balances comes from the elaborately conceived American Constittuion.)

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.

ICANN helps coordinate IANA's areas of responsibilities; IANA does not set policies, but follows the policies developed by the community policy development process of ICANN and follows the technical standards developed by the Internet Technical Community. Its present outreach activities at ICANN and IETF and with TLD operators, RIRs are sufficient given its role as a body that does not directly decide on its policies. However, IANA could extend / improve upon its outreach activities with ccTLDs with a view to work towards blurring the distinctions between gTLDs and ccTLDs in areas where a separation is unnecessary.

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.

ICANN's Security and Stability teams pay ample attention to the Security needs of the root zone and the DNS, and are dedicated to the cause of ensuring the security and stability of the Internet. Additional Security considerations could be shared with them but such concerns may not quite fit in as contractual obligations on the part of IANA. It would be more effective to rely on informal and time to time communications with the Secutiy and Stability teams of ICANN, (or better still, to share the Security concerns throught the multi-stakeholder process) than to seek to draft clauses after clauses for compliance, which can not possibly be as thorough when drafted as contractual clauses. Informal communication with ICANN's Securiy and Stability volunteers, or formal participation through a multi-stakeholder Polciy Development Process would help define the needs better by actually filling in gaps in Government's definitions of Secutiy needs while helping to redefine inadequately advised or unnecessary concerns if any.

It is vital to preseve the Internet numbering system as a central, unified, singular function. IANA has been the Authroity that has maintained these functions that are essential to the stability of the DNS. But IANA's performance of its functions are not to be assumed as a result of the oversight and definitely not to be assumed to be a result of the clauses ennumerated in the â€œpurchase orderâ€ so drafted.

IANA is the legacy of Jon Postel. It functions more by following Community Standards and Community Policies rather than from Governmental directives.

US Government has so far assumed a purpose in holding on to the IANA contact and to the very process of contracting, as the contracting party. This is a political position that arises out of concern for two conflicting causes, namely, concern for the Stability and Security of the Internet which is Global and universally benevolent as also by an unwillingness to concede this central, symbolic and vital function to the multilateral, possibly multi-stakeholder arena. Even part of this unwillingness to give up its unilateral hold could possibly arise from apprehensions of altering the Security and Stability of the Internet. However, viewed from the outside as an outsider, it appears narrow and counter-productive to America's Global thinking to hold on to its traditional role of being the unilateral contracting party to IANA.

IANA is totally useless to the United States of America as a infrastructural, strategic or even a symbolic asset. America's unilateral control over IANA accords merely a notional Authority and an empty postion of actual power that is akin to the empty power of nuclear weapons that can't even be used on the negoitiating table. What would the United States do by retaining the IANA fucntions? Would it shut down an existing TLD that is a commercial success or deny any new TLD that emerges from the ICANN Board? Would it exclude any one country or region from the Internet, friend or foe? Would it negotiate for its national trade interests in exchange for 'granting' a larger address space?

While the rest of the world has broader trust in the United States and largely understands that the US postion on IANA fucntions is mostly symbolic, there remains a widespread feeling of discomfort that it is not entirely fair that US should maintain unilateral control of the root, and this gives room for spoken and unspoken differences with at least a few of the rest of the world. US could choose not to take note and could continue for an extended period, but it would be in tune with the US spirit of Internationalism to make this contracting process inclusive.

While it is important to include all or more participants, it is necessary to ensure a responsible transition from unilateral control to a balanced, coordinated multilateral / multistakeholder oversight.

My recommendations as an individual, (drafted entirely and completely on my own, without any reference to any of the published or unpublised views of the Government of my country or any other, and without any form of help or consultaion or even conceptual correction from the community I belong to) is that the United States Government could gracefully graduate IANA from being a US Government 'contractor' to that of an independant, truly global, non-governmental, apolitical organ that is coordinated by ICANN which has an exemplary form of Governance which is being strengthened more and more as a transparent and accountable multi-stakeholder organization.

What is desirable is not a contract, not even a multi-lateral contract, but a process of checks and balances. ICANN, which sets broader policies for IANA, has the desired process of checks and balances largely built in already and American Government could inspire the ICANN community to further strengthen the processes of checks and balances within for a greater balance.

Such a gesture for the good of the Internet and for the good of the whole world, would cause America to part with this notional and unusable Authority and gain greater informal Infulence over global Internet policy, and would naturally gain deeper and wider acceptance of US concerns over broader global issues.

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.

The Association of European Telecommunications Network Operators (ETNO) is pleased to present its attached

ETNO Reflection Document - Response to the National Telecommunications and Information Administration of the US Department of Commerce on the Internet Assigned Numbers Authority (IANA) Functions

ETNO represents 40 major European telecommunications operators from 35 countries (www.etno.eu).The attached paper has the format of a Reflection Document, meaning it has been unanimously approved by all Member companies and has been endorsed by the Associationâ€™s Executive Board. The paper falls in the public domain and may be published.

In ETNOâ€™s view, the responsibilities of the IANA functions should remain as a whole within ICANN and not fall under any direct government oversight. In this respect, we urge ICANN to work towards fully implementing the Affirmation of Commitments and its resulting recommendations for improvement and we ask the US government to act as a catalyst in this direction.

The Multilingual Internet Group is pleased to submit the following comments in PDF format to the National Telecommunications and Information Administration process on the Internet Assigned Numbers Authority functions.
[Docket No. 110207099â€“1099â€“01] RIN 0660â€“XA23: Request for Comments on the Internet Assigned Numbers Authority (IANA) Functions

Best regards,

Khaled Fattal
Group Chairman
The Multilingual Internet Group www.MLiGrp.com
Linking Together The Current & Next Multi-Billion Multilingual Internet Users
Member of ICANN President's Advisory Committee on IDNs (ICANN) www.icann.org

Please find attached comments from Nokia Siemens Networks in response to NTIA's Notice of Inquiry requesting comments on the Internet Assigned Numbers Authority (IANA) functions. I have included the comments in both our preferred format, PDF, but also in Word format as the NOI did not specifically include PDF format as an option.

China Internet Network Information Center (CNNIC) welcomes the National Telecommunications and Information Administration (NTIA) request for public comment on the Internet Assigned Numbers Authority (IANA) functions. CNNIC appreciates NTIAâ€™s commitment to preserving the security and stability of the Internet DNS. In the meantime, we would like to emphasize that the security and stability of the DNS are shared responsibility among all stakeholders in the Internet community, which CNNIC thinks is yet properly incorporated in the management of the IANA functions. In this context, CNNIC would suggest that the future management of IANA functions reflect the smooth operation of IANA and reflect the interests of multi-stakeholders in the Internet community.

Specifically, CNNIC would like to make comment on the questions raised in the NTIAâ€™s NOI,

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.

Generally, CNNIC doesnâ€™t think itâ€™s necessary to separate the IANA functions except for running a root server by IANA itself. CNNIC would suggest any separation of IANA functions take into consideration the stability and smooth operation of the functions.

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.

CNNIC thinks IANA contract should include references to ccTLD operators for advice with regard to the ccTLD management principles and guidelines on IANA performance. Similarly, it is also advised that other performance of IANA functions consult with other proper entities to meet the demand of other stakeholders.

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.

CNNIC submitted its IDN ccTLD application last year, and the request process took two distinctive processes within ICANN and IANA. While the ICANN process is relatively clear and transparent, the IANA delegation process isnâ€™t clear and well-defined, which made CNNIC made a strenuous effort to meet the requirement. Based on this experience, CNNIC suggests the IANA process optimized to ease the burden with regard to the change of the request of ccTLDs. Moreover, it is also suggested the approval process by DOC be removed in the IANA process when change of request is submitted by ccTLDs to reflect the fact that the ccTLDs are to serve local community of the nation. The change of root zones should be maintained by IANA itself completely without involving DOC and Verisign.

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?

The reporting should be public, and the best multi-stakeholder model is to change the DOC-supervising-only model, and make IANA to be a real independent organization or run by an independent organization, which is supervised by the global Internet communities themselves.

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.

Current IANA contract failed to include Service Level Agreement (SLA) in its service to the whole Internet community. In order to better serve the Internet community and to protect the stability and security of the Internet, it is highly recommended that SLA be introduced in the IANA management and the performance of IANA be published in a transparent and timely manner.

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.

IANA should strengthen the multi-stakeholder model, and ensure all the root server operators to follow the policies and instructions that are developed by the community. Of course, as a neutral organization, itâ€™s not necessary for IANA to operate a root server by itself.

About CNNIC

Founded in 1997, China Internet Network Information Center (CNNIC), a non-profit organization, assumes the responsibility of â€œ.CNâ€ and ".中国/.中國" ccTLDs registry and other services for the development of the Internet in China, which are authorized by Chinese government. CNNIC is also an active participant in the global Internet community, helping to shape the global Internet policy making process for the sake of Chinese Internet users.

My name is Jonathan Zuck and I am the President of the Association for Competitive Technology, a information technology trade association, representing nearly 4,000 small and medium sized enterprises. Attached please find our comments to the Department of Commerce Notice of Intent regarding the IANA Functions contract. Thank you for your consideration.

On behalf of Mr Jonathan Shea, CEO of the Hong Kong Internet Registration Corporation Limited (HKIRC), I submit the attached response to the captioned Notice of Inquiry. The original hardcopy of the attached submission will reach your address soon.

ICANNâ€™s Responsibility to Respect International Human Rights Principles
IP Justice [1] appreciates this opportunity to provide comment to US Department of Commerce National Telecommunications and Information Administration (NTIA) regarding improvements to the functions of the Internet Assigned Numbers Authority (IANA) and its relationship with the Internet Corporation for Assigned Names and Numbers (ICANN).

IP Justice would like to focus NTIAâ€™s attention on one issue fundamental to all of ICANNâ€™s responsibility -- one that impacts all of ICANNâ€™s functions: ICANNâ€™s obligation to respect internationally recognized human rights principles in carrying out its duties.

With power, comes responsibility. As the organization responsible for the global governance of certain functions of the Domain Name Space (DNS), ICANN must also be willing to live up to the same high standards as other legitimate governance organizations in respecting the fundamental rights of Internet users. Until a suitable legal framework is in the place that can hold ICANN accountable for circumventing internationally recognized human rights guarantees, ICANN is in no position to receive additional autonomy.

As a private corporation, there is very little to hold ICANN in compliance with international legal standards and human rights protections that nation states must respect. As a private corporation ICANN does not believe it owes any legal duty or ethical obligation to respect internationally recognized legal principles. Some contend that the legal structure of ICANN as a private corporation serves as a legal â€œloop holeâ€ through which the organization can escape any responsibility to uphold human rights in the space where it governs.

ICANNâ€™s connection to the United Stated Government through its contractual arrangement with NTIA is one of the few ways that ICANN can be held accountable to upholding fundamental rights and freedoms. The US Government is legally obligated to respect human rights, while private corporations are not. ICANN has provided mixed messages about the extent to which it owes an obligation to uphold international legal principles including human rights.

Legitimate governance organizations are rooted in legal traditions that respect human rights and have means of enforcing them. For example, the US Government is prohibited from restricting the speech of its citizens except in narrowly defined circumstances under the First Amendment to the US Constitution. Furthermore the US (and most governments that participate at ICANN) have signed the Universal Declaration of Human Rights, including Article 19, which â€œguarantees everyone the right to freedom of expression in any medium and regardless of frontiersâ€. Unfortunately ICANN remains unwilling to commit to human rights principles, preferring to remain without any legal duty or ethical obligation to ensure the publicâ€™s most fundamental rights are protected in the critical realm over which it claims authority.

ICANN must affirmatively answer that it will uphold internationally recognized human rights, but to date ICANN has flouted any obligation to protect the public in this manner. At the Rome ICANN Meeting in 2004, a European Union Privacy Commissioner said that ICANNâ€™s â€œwhoisâ€ policies violate international privacy protections. ICANN has done nothing to rectify this deficiency of privacy protections in its policies.

ICANN sees no duty to protect freedom of expression in the DNS either. Proposed policies for new top-level domains that would prohibit â€œsensitiveâ€ words as domain names are in stark contrast to internationally recognized freedom of expression guarantees. Internationally recognized legal principles of â€œdue processâ€ which ensure fairness can also be easily skirted in a private corporation that believes it owes no duty to the public.

Unfortunately ICANNâ€™s lack of commitment to internationally recognized fundamental rights and freedoms threatens the healthy growth of the DNS and the global public interest. ICANNâ€™s structure must be rooted in a firm foundation and a legally enforceable obligation to uphold basic rights. Today more than ever, we see the promise and the power of a free and open Internet to empower citizens and strengthen democracies. And we recognize the critical need to ensure the Internet remains an engine of human progress and freedom. Respect for human rights in the policies governing the DNS is critical to furthering the global public interest.

Since ICANN claims its objective is to promote the global public interest, it ought to be willing to adhere to internationally recognized legal principles that guarantee the public basic rights and fundamental freedoms. Removing any duty or legal obligation to respect human rights, which ICANN may have by virtue of its relationship with the US Government, would leave the public defenseless in cyberspace.

Without a legal mechanism to ensure ICANN will respect internationally recognized human rights, the same way a legitimate governance organization must respect human rights, it would be dangerous to grant ICANN further autonomy.

The Number Resource Organization (NRO) is very pleased to submit comments to the National Telecommunications and Information Administration [Docket No. 110207099â€“1099â€“01] RIN 0660â€“XA23 Request for Comments on the Internet Assigned Numbers Authority (IANA) Functions.

Please find attached comments by the International Telecommunication Union (ITU) as a response to Request for Comments on the Internet Assigned Numbers Authority (IANA) Functions; National Telecommunications and Information Administration, Docket No. 110207099-01, RIN 0660-XA23; published in the Federal Register /Vol. 76, No. 38 / Friday, February 25, 2011, page 10569. You will also receive a paper copy of the comments by mail.