Request for Comments on the Internet Assigned Numbers Authority (IANA) Functions

Topics: 
Date: 
February 25, 2011
Docket Number: 
110207099-1099-01

Namibian Network Information Centre (NA-NiC), | Dr EberhardWLisse

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

el

AttachmentSize
noiiana01.pdf 130.08 KB
noiiana01.txt 9.77 KB

Self | Sivasubramanian M

Fiona M Alexander
Assistant Administrator
Office of International Affairs
National Telecommunications and Information Administration
Washington DC




Sivasubramanian M

President

Internet Society India Chennai Chapter

isolatednet@gmail.com




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.




(attachements:




Sivasubramanian M India comment on NTIA's NOI on IANA.doc ( in word 97/2000/XP format )

Sivasubramanian M India comment on NTIA's NOI on IANA.pdf







Sivasubramanian M


President
Isoc India Chennai
http://isocindiachennai.in



facebook: http://is.gd/x8Sh
LinkedIn: http://is.gd/x8U6
Twitter: http://is.gd/x8Vz

AttachmentSize
Sivasubramanian M India comment on NTIA's NOI on IANA.doc 39 KB
Sivasubramanian M India comment on NTIA's NOI on IANA.pdf 46.21 KB

Self | Stephen Deerhake

Greetings,

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”

The document may be found at

http://ccnso.icann.org/workinggroups/final-report-drd-wg-17feb11-en.pdf


A copy of it is attached in text format as specified in your notice and as a PDF file for ease of reference.


Best Regards,

Stephen Deerhake
sdeerhake@gdns.com

AttachmentSize
DRDWG-DraftFinalReport.pdf 95.86 KB
DRDWG-DraftFinalReport.txt 33.96 KB

National Telecom Regulatory Authority, Egypt | Manal Ismail

Dear Ms Fiona,

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.



Please accept my best regards ..



--Manal Ismail



Egypt GAC Representative

Director International Technical Coordination

National Telecom Regulatory Authority, Egypt

AttachmentSize
Egypt Response to NTIA NoI on IANA Functions.doc 141.5 KB
Egypt Response to NTIA NoI on IANA Functions.pdf 137.8 KB

Self | George Papapavlou

I am one of Greece's representatives in the GAC, previously European Commission representative in the GAC.
Attached you will find my personal comments on possible changes to the IANA Functions.

Regards,

George Papapavlou

AttachmentSize
IANA comments.doc 38 KB

Swiss Federal Office of Communications (OFCOM) and the Swiss foundation SWITCH

Dear Ms. Alexander,

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

Attachment:
* Response-NTIA-IANA-NoI-2011_31113_05.pdf

AttachmentSize
Response-NTIA-IANA-NoI-2011_31113_05.pdf 204.37 KB

IAB | Bernard Aboba

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.


Kind Regards,
for the IAB,

Bernard Aboba
IAB Chair

AttachmentSize
IAB-IANA-NOI.doc 46.5 KB

Coalition for Online Accountability (COA) | Steven J. Metalitz (Counsel)

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.

Steven J. Metalitz
Counsel, Coalition for Online Accountability
www.onlineaccountability.net

AttachmentSize
COA NOI response re IANA 033111 (3700034).DOC 147 KB
COA NOI response re IANA 0331111.pdf 19.87 KB

Asia Pacific Top Level Domain Association (APTLD) | Ms. Jian Zhang

Asia Pacific Top Level Domain Association (APTLD) response to NTIA Notice of Inquiry (NOI) on the IANA functions

March 31 2011
TO: Fiona M. Alexander, Associate Administrator, International Affairs National Telecommunications and Information Administration (NTIA) U.S. Department of Commerce
1401 Constitution Avenue, Rm 4701
Washington, DC 20230

About APTLD

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.

Ms Jian Zhang
General Manager
APTLD

AttachmentSize
APTLD comments on NTIA NoI on IANA.doc 45 KB

Nokia | Leo Fitzsimon

Dear Ms. Alexander:

Attached please find comments from Nokia on the above-referenced proceeding. A copy of these comments will also be sent via regular mail.

Should you have any questions or need additional information, please do not hesitate to contact me.

Br,


Leo Fitzsimon
Head of Government & Industry Affairs

AttachmentSize
Nokia_comments on the_IANA_functions_.pdf 37.63 KB

Chair – ccNSO Council | Lesley Cowley

Please find attached the ccNSO comments to the NOI on IANA functions.

AttachmentSize
2011-03 ccNSO response to NTIA NOI on IANA.pdf 134.73 KB

Netnod | Kurt Erik Lindqvist

The below response has also been submitted with postal letter.

Best regards,

- kurtis -

AttachmentSize
Netnod-Response-NTIA-IANA.doc 153.5 KB

auDA | Chris Disspain

Please find attached auDA’s response to the NTIA’s request for comments on the IANA functions.

AttachmentSize
auDA submission to NTIA NOI regarding the IANA functions.pdf 101.65 KB

Internet Society of China | CQ

there is Internet Society of China comments on the IANA contract in the annex,please see the annex.

AttachmentSize
Internet Society of China comments on the IANA contract-V3[1].doc 62 KB

Canadian Internet Registration Authority | Byron Holland

Dear Ms. Alexander,

On behalf of the Canadian Internet Registration Authority, please find attached our response to the NTIA on the IANA functions.

Kind regards,

Byron Holland
President and CEO
Canadian Internet Registration Authority

AttachmentSize
CIRANTIANOI.pdf 126.77 KB

GoDaddy.com, Inc. | Tim Ruiz

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.


1.
http://www.ntia.doc.gov/frnotices/2011/fr_ianafunctionsnoi_02252011.pdf

AttachmentSize
Go Daddy response IANA NOI.doc 56.5 KB

Self | John Schnizlein

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.

AttachmentSize
John Schnizlein Comment-IANA-NOI-2011-March.pdf 77.77 KB

Self | Dina Barakat

Kindly find the file attached regarding the comments on IANA Functios.
Thank you and my best regards,

Dina Barakat
Egyptian Universities Network

AttachmentSize
Comments on IANA Functions.pdf 156.49 KB