Summary of public comments submitted in response to the IANA Functions Further Notice of Inquiry

The Internet Assigned Numbers Authority (IANA) functions are critical to the Internet Domain Name System (DNS). The Internet Corporation for Assigned Names and Numbers (ICANN) performs the IANA functions on behalf of the United States (US) government through a contract with the Department of Commerce's National Telecommunications and Information Administration (NTIA). That contract is set to expire on 31 March 2012.

On 25 February 2011, NTIA released a Notice of Inquiry (NOI) to obtain public comment on the performance of the IANA functions. NTIA is now seeking public comment through a Further Notice of Inquiry (FNOI) on a draft statement of work (SOW). The SOW outlines measures for the operational management of the IANA functions in support of accountability and transparency, and is a key element of the procurement process for the new IANA functions contract.

The FNOI received 46 responses. We have summarized each below. And we have broken out the responses by topic on a different post.

Association Francaise pour le Nommage Internet en Cooperation (AFNIC), manager of the French ccTLDs, was involved in the development of CENTR's responses and shares many of the same concerns. They are concerned about the move away from the voluntary fees system and the potential for ICANN to use cost recovery fees for other work. They support including end-to-end automation of the parts of the root zone management process handled by DoC and VeriSign. AFNIC also shares CENTR's opinion that, except where confidentiality is required, all procedures and standards "should be conducted and applied in a transparent and accountable manner" and reports should be published to the greatest extent possible. AFNIC also asks that performance metrics and levels be defined in consultation with IANA's customers (noting that ICANN has yet to consult ccTLDs on performance metrics for IETF).

The Asia Pacific Top Level Domain Association (APTLD) commented at length on the structural separation between policy-related activities and management of the IANA functions. The APTLD does not believe that a complete prohibition on participation by IANA staff in policy development and policy-related activities would serve the interests of the communities empowered to develop IANA related policies and wants to make sure the SOW clarifies that IANA staff are not precluded from such engagement or any discussion on applicable policies. The APTLD agrees that: "...the inconsistencies in delegation and redelegation policies might not have occurred if there had been functional separation between execution of the IANA functions and the associated policy development processes," but noted that the ccNSO DRDWG was concerned primarily with the activities of the ICANN Board, rather than IANA staff.

The APTLD also suggested that the wording of C.2.2.1.3.2 may be unnecessary due to work already undertaken by the DRDWG and the FOIWG and in the development of the gTLD Applicant Guidebook (AGB). The APTLD warned that pre-empting the work done within ICANN could be inconsistent with the US Government's stated commitment to a multi-stakeholder governance model. Finally, APTLD joins the ccNSO in cautioning against any departure from the established principles and practices with regard to sovereignty in the management of ccTLDs and the voluntary nature of ccTLD contributions to the maintenance of the IANA functions.

The Association of National Advertisers (ANA) questioned ICANN's "fitness to make key policy decisions and to continue to perform the IANA functions," at least without checks and balances on "what increasingly seems to be ICANN's unbridled power." ANA believes that ICANN has violated its own code of conduct -- and "abrogated its Affirmation of Commitments with the Department of Commerce" -- by failing to approach policy development related to the gTLD program fairly, transparently and with a bottom-up, consensus-driven approach. If this program is allowed to proceed, ANA thinks it is likely to cause irreparable injury to brand owners, diminishing the power of trademarks and causing consumer confusion, dilution, cybersquatting, violations of online security and privacy and a host of other malicious conduct. ANA considers paragraph C.2.2.1.3.2 an important first step, providing some limited protection against gTLDs being deposited to the authoritative root zone without appropriate justification.

The At-Large Advisory Committee (ALAC) -- At-Large is the community of individual Internet users who participate in the policy development work of ICANN -- is enthusiastic about NTIA's decision to keep the three Core IANA functions/processes bundled and performed by a single entity and supports the automation of the IANA's root zone management functions, as well as any improvement of transparency and security associated with IANA's functions and reporting. ALAC also understands the rationale behind limiting the length of the first contract term with ICANN, though it expresses support for ICANN's request for a longer-term contractual arrangement. ALAC is concerned, however, by the proposal to separate policy development from the IANA function and suggests both the reason for and extent of this separation be specified. They would like to see decisions regarding delegations and re-delegations of TLDs called out as being required to "be made within existing policy frameworks."

.au Domain Administration (auDA) issued a number of warningsÖ
- Determining the ërelevance' or ëapplicability' of national laws can be incredibly complex in regard to ccTLDs and, given their generic, global and cross jurisdictional reach, even more complex in the case of many gTLDs.

  • A complete prohibition on participation by IANA staff in policy development and policy-related activities would not serve the best interests of the community.
  • Section C.6.2, read literally, would prohibit ICANN from implementing policy changes without prior approval from the US government.
  • Sections C.2.2.1.3.1 and C.2.2.1.3.2 cover ground that community representatives have been working, through the DRDWG and the FOIWG. In support of the multi-stakeholder model, the SOW should not pre-empt the outcomes and recommendations of these processes.
  • Requiring further documentation from the contractor to confirm that criteria for consensus support and consistency with the global public interest have been met could be interpreted as rating these as more important than all other criteria -- and as a lack of faith in the multi-stakeholder model. The IANA contractor's role should simply be to verify that the AGB process has been followed and all evaluation criteria have been met.

The global provider of domain name registry technology, software and consulting services, AusRegistry International, is concerned about section C.2.2.1.3.2: this proposal conflicts with both the community-approved process for the introduction of new gTLDs represented in the AGB and with section C.2.2.1.1, which seeks to clearly distinguish operational execution from policy development.

The Canadian Internet Registration Authority (CIRA) opposes a complete prohibition on IANA staff participation in policy development and policy-related activities related to ICANN's mandate. IANA staff should be permitted to serve as a resource in support of policy-related activities.

CIRA also expressed concern about the collection of fees for performance of the IANA function on a cost-recovery basis: CIRA participates in the ccNSO Finance Working Group, which is examining existing and potential ccTLD contribution models and will deliver a report by the end of 2012. Input from relevant stakeholders should be reflected in the automated root zone management system -- and should be required by the C.2.2.1.3.3 provision.

Finally, regarding standardizing user documentation for root zone changes and a process for documenting the source of policies and procedures and the application of relevant policies and procedures in processing requests associated with TLDs, CIRA urged NTIA to ensure that the SOW does not "pre-empt, foreclose, or circumvent the multi-stakeholder process under way to better manage one of the most critical and contentious aspects of IANA services." Related sections of the SOW overlap with recommendations of the DRDWG and the ongoing work of the FOIWG.

China Internet Network Information Center (CNNIC) is concerned, primarily, that "the use and management of the Internet should be guaranteed for the benefit of people throughout the whole world. The IANA functions are clearly crucial for the global Internet, thus requiring more involvement of all stakeholders."

CNNIC asserts that development of policies and procedures regarding delegation and redelegation should involve all stakeholders, which should be reflected in a multi-stakeholder model of policy development specified in section C.2.2.1.1. Performance standards, metrics and reports should be made public and, in the long term, more steps should be taken to transform the current DOC-supervising-only model into a complete independent multi-stakeholder model.

Governments have sovereignty concerns with respect to the delegation and management of ccTLDs, so the IANA functions should be performed independently and without interference from the US Department of Commerce. CNNIC is concerned about the designation of the COTR and suggests that the COTR should be elected and approved by all relevant stakeholders.

The Contingency and Continuity of Operations Plan (CCOP) should be delivered or published to all related stakeholders, in lieu of being delivered solely to the US government. All relevant stakeholders should be invited to participate in the development of the root zone management dashboard, not just the contractor, NTIA and VeriSign. Finally, CNNIC strongly suggests maintaining the current voluntary contribution model.

China Organizational Name Administration Center (CONAC) sees the transparent operation and widespread acceptance by the global Internet community of the organization performing the IANA functions as vital to the effective performance of those functions and, therefore, the efficient assignment of global Internet resources. CONAC challenges the dominant role of the US, asking that:

  • An independent body be accredited to deal with information confidentiality.
  • The transparency and accountability described in section C.2.2.1.3.1 originate in the initial policy development stage.
  • The challenge of dealing with legal conflicts between US laws and registries' local laws be recognized as significant.
  • The annual security plan be made available for comment by all stakeholders -- rather than just to the US. Maintaining the security of cyberspace is not a mission exclusive to the US government, and cannot be accomplished by any single nation.

While appreciative of the steps taken so far and, in particular, since the last comment period, the chief concern of the Coalition Against Domain Name Abuse (CADNA) remains: the way ICANN currently operates the IANA functions could compromise the security and stability of the Internet. Since ICANN possesses both the IANA contract and its policy development functions, ICANN has a great deal of authority over all aspects of Internet operations, but has operated without regard for transparency, accountability or the best interests of all Internet users. (CADNA cites as an example of this the ICANN Board's approval of the controversial new gTLD program.)

If NTIA does choose to give the IANA functions back to ICANN, CADNA would like to see an external audit of ICANN's internal structure, in order to make the necessary changes and ensure that all conflicts of interest are resolved. And CADNA would prefer to see outside oversight -- rather than separation of staff -- to ensure that ICANN is not able to abuse its power. Perhaps a third party could handle the IANA functions or policy development.

The leading priority of the Coalition of National and International Trade Associations and Labor Organizations is "to ensure that any music themed gTLD, or any gTLD that is based or focused on driving music discovery or consumption, is used productively and responsibly, and not as a means to facilitate copyright or trademark infringement." Toward this end, the coalition strongly supports C.2.2.1.3.2. The coalition wants to see the IANA contractor document how a gTLD's entry into the root would meet the global public interest standard and believes that this draft SOW provision "helps 'fill the gap' left by the ICANN evaluation process to ensure that this resource is used responsibly."

The Coalition for Online Accountability (COA), consisting of eight leading copyright industry companies, trade associations and member organizations of copyright owners, argued vehemently that NTIA should retain -- in the face of opposition from ICANN -- the provision in C.2.2.1.3.2 that obliges the IANA contractor to require documentation for new gTLD delegation requests that demonstrates how a proposed string has received consensus support from relevant stakeholders and is supported by the global public interest. COA fully agrees with NTIA that such a requirement "provides checks and balances for TLD root zone management changes, to ensure the continued stability and security of the DNS."

Connecting.nyc focused its response on "Section C.2.2.1.3.2 Responsibility and Respect for Stakeholder" in the interest of seeing good domain names reserved for those currently unable or unprepared to use them. Connecting.nyc was delighted to see that applicants for new TLDs may need to demonstrate consensus support for their applications under the proposed IANA contract, which would also serve to avoid any appearance of impropriety in the wake of "the Application Guidebook's guiding hand having moved to a firm specializing in acquiring new TLDs." How is that consensus to be defined? Connecting.nyc suggested using guidelines [pdf] developed for grant-makers from the US Department of Housing and Urban Development measuring the level of local engagement to assess consensus in applications for geographic community TLDs.

The Cooperative Association for Internet Data Analysis (CAIDA) pointed out that several entities commenting on "Section C.2.2.1.3.2 Responsibility and Respect for Stakeholders" seem to believe that "global consensus" and "public interest" already appear in the evaluation criteria for new gTLDs, while others -- including ICANN itself -- insist that these are not requirements for a new gTLD.

CAIDA considers this "a damning admission given that the Affirmation of Commitments clearly states the commitment to: '(a) ensure that decisions made related to the global technical coordination of the DNS are made in the public interest and are accountable and transparent. That stakeholders do not even agree to what has been agreed is another symptom of failure of ICANN's process." CAIDA considers this provision in the SOW "a valiant attempt by NTIA to recover some oversight capability in the face of ICANN's failure to meet this Commitment." CAIDA also requested clarifications in section C.4 and asked whether the tracking of IPv6 and DNSSEC deployment is something IANA should be responsible for, or something that should be funded by interested governments.

The Council of European National Top Level Domain Registries (CENTR) welcomed the open and transparent way in which the new terms and requirements for the future IANA functions procurement contract are being developed and applauded the inclusion of the 24/7 service guarantee and the more secure communication channels. CENTR does have a few reservations, however:

  • A move away from the voluntary fees system could create barriers for some developing countries.
  • Any cost recovery fees for the IANA functions should not be available to ICANN for other work.
  • The automation process should also include available end-to-end automation of the parts of the process handled by the DoC and VeriSign -- with dedicated, secure communication channels.

CENTR seeks a number of clarifications and a requirement of maximum possible transparency for IANA procedures and standards.

The Country Code Name Supporting Organization (ccNSO) appreciates and supports NTIA's commitment to ICANN's multi-stakeholder process for coordination of the Internet's DNS; its decision to keep the three core IANA functions processes bundled and performed by a single entity; and, the commitment to automation of the root zone management function and to making improvements to the transparency and security with which this function is executed.

The ccNSO has been involved in several IANA-related policy and process development efforts that demonstrate the success of an inclusive approach to ICANN's work and the multi-stakeholder model. Regarding the separation of policy development and operational roles, the ccNSO thinks IANA staff should cooperate with and provide information and resources to related policy and process development activities to facilitate better communication between the ICANN community and staff, improve and inform deliberations and outputs and improve staff understanding.

Support for any ICANN Board involvement in policy development should not be inferred as, within the multi-stakeholder model, this appropriately remains the responsibility of the community through supporting organizations and advisory committees. The ccNSO believes that the task of adopting standardized documentation must be informed by the output of the FOIWG and, in the interim, would welcome modifications in IANA documentation and ICANN consideration of IANA reports to address the deficiencies and inconsistencies cited in the findings of the DRDWG. The ccNSO also recommends that the SOW specify that timelines for performance standards development activity may be modified by the COTR at the request of the FOIWG.

Regarding the requirement that the contractor act in accordance with applicable local laws, the ccNSO suggests, as would normally be the case with respect to delegations made under RFC 1591, that ccTLD operators be required to maintain an in-country presence, giving local government meaningful personal and subject matter jurisdiction to enforce its law with respect to a ccTLD operator.

The ccNSO also came out in favor of developing standards and metrics to ensure that demands on IANA resources in connection with the new gTLD program do not adversely affect IANA's ability to respond in a timely fashion to root zone change requests for existing TLDs. Contributions should remain voluntary. The COTR should not be required to approve policies, procedures, documentation and mechanisms used to process requests related to ccTLDs or demonstrate that delegation requests for new gTLD strings have consensus support and meet the global public interest.

Relevant stakeholders should provide input regarding the development of an automated root zone management system, and, to the maximum extent possible, the full range of the contractor's stakeholders should be afforded the opportunity to provide input to assessment processes and all resulting performance reports should be published. International quality standardization should be included. C.6.2 establishes that the IANA functions contract does not authorize ICANN to make material changes in the policies or procedures developed by the relevant entities associated with the performance of the IANA functions and prohibits ICANN from implementing policy changes without the prior approval of the US government. "The ccNSO urges NTIA to clarify that this provision is not intended to apply to policies that are properly and appropriately developed through an ICANN policy development process or policy-related process."

The Direccion General Adjunta de Asuntos Internacionales appreciates NTIA's efforts to improve transparency and accountability and its development of the Contingency and Continuity of Operations Plan (CCOP) and the Customer Service Complaint Resolution Process (CSCRP). They would, however, prefer to see a longer-term contractual arrangement for the IANA functions in place and would also like to make sure IANA staff are allowed to inform and advise policy-makers with respect to the IANA functions. Finally, the Direccion General Adjunta de Asuntos Internacionales requested clarification that not all delegation requests for new gTLDS will require consensus support or support by the global public interest, which -- it should be mentioned -- will involve the participation of GAC.

As a potential new gTLD applicant, Donuts focused their attention on C.2.2.1.3.2. The AGB recognizes and balances the views of relevant stakeholders potentially affected by a new gTLD, said Donuts EVP & Co-Founder Jon Nevett, but does not require consensus support for good reasons:

  1. Competition. Requiring consensus could deliver too much control to existing industry players.
  2. Innovation, which is rarely the result of consensus.

The proposed SOW language is broad enough to be used by dissatisfied or incumbent entities to engineer challenges to any TLD award, so Donuts would like to see section C.2.2.1.3.2 amended to require demonstration of "how the string proposed reflects the opportunity for input from relevant stakeholders and the process utilized was supportive of the global public interest."

The European Telecommunications Network Operators' Association (ETNO) believes that, while US Government oversight of the IANA functions has been "a suitable model" historically, there is "no compelling reason for the IANA functions to continue to be subject to a US Government procurement contract.

ETNO believes that ICANN is the best placed body to oversee these functions, assuming that ICANN continues to comply with the obligations set out in the Affirmation of Commitments." ETNO is also deeply concerned that the IANA functions could be used as a means to verify or revisit decisions made on new gTLDs on the basis of an evaluation of consensus among relevant stakeholders or evaluation of the global public interest. Delegation decisions should be made according to the process set out in the new AGB.

Go Daddy.com hailed the draft SOW as an "enhancement in the performance of the IANA Functions Contract and the relationship between the Contractor, the NTIA and interested stakeholders" and embraced the additional transparency requirements for handling changes to the DNS root zone. Go Daddy did ask that the SOW specify penalties or sanctions in "Section C.4 Performance Metrics" and "Section C.5 Audits" and specify contractor obligations with regard to ccTLD delegations in C.6.3. Generally "satisfied with the current procurement of IANA functions and the incumbent operator," Go Daddy urges caution in making "sweeping and material changes," asking for due consideration of their impact on the long-term continuity of the IANA functions.

Hong Kong Internet Registration Corporation Limited (HKIRC) asked, first, that the working relationship between the contractor and its stakeholders be defined as one in which the contractor operates "based on and following policies developed and agreed upon by all interested and affected parties." Regarding the separation of IANA functions staff from policy development, HKIRC feels that IANA staff should be directed to "cooperate with, and provide information and resources to, related policy and process development activities amongst the community of stakeholders." HKIRC went on to warn that stakeholders are already reviewing policies on voluntary financial contributions made to maintain the IANA functions. The mention of collecting fees in the SOW might pre-empt work already done and limit the available options.

Industry Canada finds answers to many of the challenges identified in the SOW within ICANN and the ICANN community:

  • The ongoing FOIWG is expected to provide additional clarity to IANA staff in implementing processes and compiling documentation for ccTLD requests.
  • The GAC can play a key advisory role to IANA Functions staff in reviewing delegation requests for new gTLDs based on community consensus support and the global public interest, with the understanding that some TLDs -- such as dot-brand TLDs -- will not explicitly serve the public interest.
  • In relation to the corporate governance of an IANA functions contractor, corporate and legal documents (such as ICANN's Bylaws), as well as relevant legislation, would be the main points of reference.
  • Existing rules and procedures can be updated or enhanced to address conflicts of interest by introducing codes of conduct or drawing on best practices. The ICANN community, including members of
    the GAC, can also recommend improvements in accountability and transparency.

The International Telecommunication Union (ITU) regards it as critical that international organizations -- and especially organizations established by international treaties -- "have an appropriate presence and identity on the Internet, in line with their special status and requirements. Since these treaty organizations have already agreed that the provisions contained in Recommendation ITU-T E.910 correspond to their special requirements, it might be appropriate for the Draft SOW to include the specification that the manager of the .INT top-level domain name implement the provisions of Recommendation ITU-T E.910."

The International Trademark Association (INTA) supports "the ongoing development of the multi-stakeholder private sector model of managing Internet resources in a manner that is representative of global stakeholders and furthers the public interest."

What INTA is looking for is a relationship between the IANA functions contractor and stakeholders that allows for the timely development of policies that can further the goals of transparency, accountability and promotion of the public interest. In order to build a foundation of transparency and accountability for that relationship, INTA seeks the following:

  • The language of C.2.2.1.1 should be broadened to make sure that "any and all staff dedicated to executing the IANA functions" cannot be read narrowly and applied only to technical personnel engaged in the management of the root zone.
  • While the administrative functions associated with root zone management should remain with the IANA functions contractor, additional oversight needs to be provided by NTIA -- especially when it comes to the creation of performance standards and metrics, which should be done in coordination with stakeholders.
  • At a minimum, periodic reports should be required to detail root zone change requests, the timing and accuracy of their fulfillment and any denials and non-compliance with such requests (with rationales).
    These reports should be publicly accessible to the extent allowed by law.
  • Accountability measures should be developed to ensure the accuracy of contact, name server, delegation and resource record information before new TLDs are created.
  • Preliminary performance standards should be put in place prior to selection of the IANA functions contractor.
  • Greater specificity is required in a number of areas, including "Provision C.2.2.1.3.5 Customer Service Complaint Resolution Process," which should provide an analog or model process currently in use as guidance.

The Internet Architecture Board (IAB) responded to the FNOI both "as the body that approves the entity that serves as IANA for the Internet Engineering Task Force (IETF)" and on a broader level, looking at the IANA functions and stability and interoperability issues. IAB suggested a number of corrections and clarifications, and then gave their counsel.

  • They asked that the DNS, addressing and protocol functions of the IANA be treated on an equal footing and that the SOW not imply that other IANA functions essentially support the DNS function.
  • The IAB also objected to a single governmental agency being seen as having close, management-level oversight of IANA and would like the NTIA to work toward more autonomy for the IANA function.
  • The NTIA should write requirements that focus on IANA's working relationships with those who specify IANA actions or are direct consumers of IANA decisions and registries, rather than with anyone claiming to be interested and affected. Any stakeholder would still be able to participate in policy development.
  • Requirements for security, performance and audits should be set by the materially affected parties, and reporting should be done publicly.
  • Services on which the whole Internet depends should be "designed with off-continent replication and general system robustness in mind."
  • "Section C.2.2.1.2 Coordinate the Assignment of Technical Protocol Parameters" should clearly identify the IETF as the policy development body and the performance standards and metrics should be oriented primarily toward the IETF as the consumer of the services.
  • The contractor should not be required to take on tasks that belong in the policy realm, such as ensuring that policies are not in conflict with national laws or making judgments about the quality of documentation demonstrating consensus (as in C.2.2.1.3.2). The contractor should also approve changes in methods requested by materially affected parties unless they explicitly contradict some aspect of the contract (C.6).

The Internet Corporation for Assigned Names and Numbers (ICANN), in its response to the FNOI, described the scheduled expiration of the current IANA functions contract as "an opportunity to increase global confidence that the governance and performance of the IANA functions are carried out in the spirit of the multistakeholder approach."

In an effort to increase global confidence in the management of the protocol parameter registry and the dot-arpa domain, ICANN suggested allowing them to be subject to the oversight of the affected organizations by separating the governance of these functions from the procurement contract, which would still allow them to be bundled and operated by the same entity. ICANN also argued that, in the spirit of the multi-stakeholder approach, the COTR should not be responsible for approving performance metrics; at most, the COTR should comment on whether they conflict with any other aspect of the IANA functions agreement.

ICANN notes, too, that under the proposed SOW, the IANA functions operator would become accountable to the US Government rather than to the relevant stakeholder communities. To the greatest extent possible without compromising confidentiality requirements, transparency should take place in a timely and predictable fashion; progress in root zone modification requests, for example, should become publicly available as soon as is reasonably possible and the requesters should be kept informed of the progress of their requests.

ICANN considers the strict functional separation proposal counterproductive. Currently, the IANA functions staff is able to "make valuable and transparent contributions to the policy development process without compromising the integrity of the performance of the IANA functions. To the extent that the separation proposal is motivated by a concern that the policies and principles applied by the IANA functions staff are unclear, the solution is to allow relevant stakeholders to develop new or clarify existing policiesÖThe practical distinction between policy development and operational execution of the IANA functions is therefore already a reality."

Paragraph C.2.2.1.3.2 does not distinguish between ccTLDs and gTLDs, but only makes sense in the context of ccTLDs, as gTLDs are likely to serve many different populations, located in many jurisdictions. That said, a growing number of ccTLDs have opened their second level domain space to registrants from multiple jurisdictions and the IANA functions operator should not have to determine whether or not a particular ccTLD request complies with the law of the relevant jurisdiction. "It would create an enormous risk of politicizing the role of the IANA functions operator, and therefore run contrary to the distinction between policy-making and operational implementation."

The documentation requirements for new gTLDs seem to replace the process laid out in the AGB with new requirements to demonstrate that each string has explicit consensus support and is consistent with the global public interest. Instead, the IANA functions operator should simply forward documentation published by the ICANN Board regarding the approval of each new gTLD delegation request. "The IANA functions contract should not be used to rewrite the policy and implementation process adopted through the bottom-up decision-making process."

Finally, ICANN warned that a one-year contract with options to renew exercisable at the sole discretion of the US Government "creates a persistent threat that the operator and operations of the IANA functions could be changed at any time. By contrast, a term of at least five years would instill global confidence that the IANA functions will be carried out in a manner that ensures the security and stability of the DNS and other Internet resources. If the current framework must continue, the addition of a presumptive renewal clause would enhance global confidence in the stability of the performance of the IANA functions."

The Internet Governance Project (IGP), an alliance of independent academic experts on Internet governance issues, was "unpleasantly surprised" by changes made in the proposed SOW for which they can find no source in either public comments or in the original set of questions in the NOI. "There are elements in the proposed SOW which could radically alter the nature of the IANA functions contract. Historically, the IANA contract has been a minimal framework for the supervision and auditing of changes to the DNS root in order to ensure neutrality, transparency and accountability. The IANA contract has never been -- and must not become -- a mechanism by which the U.S. government attempts to influence or second-guess the policies developed by ICANN."

The IGP finds that one reading of C.2.2.1.3.2 would threaten this principle: if ICANN is required to make a determination that any new gTLD enjoys consensus support and is in the public interest before it can enter the new string into the DNS root, this review would come after the ICANN Board had already approved a TLD and in the absence of any definition of the global public interest or any metric for assessing TLD applications against a public interest standard. This is not the only requirement that the IGP considers worrisome -- or, potentially, just open to misinterpretation.

The IGP is concerned about NTIA's use of responses to the February 2011 NOI regarding root zone management requests for ccTLDs. Those responses were used as the basis for establishing new requirements for IANA's delegation of new gTLDs as well. "In the case of ccTLDs, it may make sense for IANA to ascertain whether a new delegation or a re-delegation enjoys consensus support among the parties involved, and serves the local and global public interest (as RFC 1591 vaguely suggests it should).

It makes no sense, however, for newly approved gTLDs, which will have already passed through an elaborate, expensive process ensuring conformity to ICANN policies, to go through such a review at the hands of the IANA." The IGP also questioned where in the original NOI or public comments NTIA located a request that it be given authority over ICANN's hiring of a security director.

The IGP does support the separation of the IANA functions staff from any policy development related to the performance of the IANA functions and does not think such a separation would prevent IANA staff from providing factual information about their activities upon request.

Internet New Zealand Inc (InternetNZ) approves of the overall structure proposed for the IANA contract, but does see the need for a bit of tidying up. In C.1.3, the contract should explicitly state that all stakeholders are equal, that "neither the technical community, nor the governmental community, nor any other that may assert primacy."

To establish a separation between the IANA functions operator and policy development, the following elements of IANA functions operation should be managed independently of any policy body such as ICANN:

  1. Control over pay and working conditions for the staff who deliver the IANA functions.
  2. Financial accounting.
  3. Legal advice.

InternetNZ thinks this could best be achieved by the IANA functions operator being a separate legal entity. InternetNZ also notes that, though IANA functions staff are experts in certain areas, their expertise is not unique and would not be an irrecoverable loss in policy development discussions.

Finally, InternetNZ has a number of thoughts regarding C.2.2.1.3.2, including:

  • All the registry functions must be treated with equal priority and the development of the service for any function must not be allowed to fall behind that of the others.
  • The end goal for the process for TLD delegation and re-delegation should be as follows: the relevant policy body receives delegation/re-delegation requests, decides whether or not to accept each request based on its policy framework and requests that the IANA functions operator delegate or re-delegate. The role of the IANA functions operator would be to ensure that due process has been followed, rather than to decide on the merits of the request.
  • The IANA functions operator should no longer accept gTLD delegation requests from any body other than ICANN, as this is the one area of the TLD delegation/re-delegation policy framework that is well-developed. This means removing the requirement that the contractor demonstrate consensus support and public interest, as that responsibility will fall to ICANN.

The Internet Society (ISOC) provides the organizational home for the groups responsible for Internet infrastructure standards (including the IETF and the IAB) and fully supports the comments contained in the IAB submission.

The IAB asked that some entities be defined as "materially affected parties" in relation to the IANA contract. ISOC, too, believes that the contract needs to acknowledge that stakeholders' roles, responsibilities and capabilities vary and some have a greater need for involvement than others. 'Materially affected parties' include the policy development bodies (ICANN, represented through its board, the IETF and IAB and regional address policy groups as represented by the ASO/NRO), regional registries, ccTLD operators/managers and governments.

This acknowledgement would avoid any perception that the contract is intended to expand the scope of IANA or to assert authority over those organizations. An examination of the roles and responsibilities of the Internet technical community would also underscore the fact that all three IANA functions are of equal importance.

ISOC continues to believe in functional separation, but the requirement for separation should be at the level of functional operation specification and not at the level of staffing. To be consistent with this requirement, the IANA contractor's staff should be responsible only for documenting compliance with objective policy requirements, procedures and laws and for certifying the compatibility of proposed standards and metrics with the terms of the contract. Assessing compliance and certifying community support must also remain separate from the procedural functions of the contractor.

Internet Society - Bulgaria supports the positions expressed by the global Internet Society.

The Internet Society of China (ISC) reiterated comments it submitted to NTIA on 31 March:

  • All stakeholders should be equally endowed with rights to participation, information and supervision over the IANA functions.
  • Unilateral control by the US should not be permitted to continue: it is inconsistent with US support for multi-stakeholder governance. ISC proposed the establishment of a "supervision mechanism including government, civil societies, the private sector, non-governmental organizations, technical community, and interests-related parties to supervise IANA functions performance."
  • The IANA function operator must be responsible for the global Internet community to ensure Internet security, stability and unity.

In a joint submission, Island Networks and Island Networks (Jersey) adopted and endorsed the submission of Lesley Cowley OBE / Nominet UK to this FNOI.

They expressed appreciation for NTIA's response to issues relating to the separation of the IANA function from the policy-making role and the issue of McGonnell fairness in respect to ICANN's dual role as registry manager and IANA contractor.

Additionally, they asked that the SOW specify that the IANA contractor is required to hold itself to the standards set out in ërelevant international law' and "must govern its actions, at bare minimum, by those shared principles common to democratic societies governed by the Rule of Law that are set out both in the 1948 Universal Declaration, and the 1950 European Convention."

Though ICANN has, in its Articles of Incorporation (Article 4), bound itself under the law of the state of California to respect relevant international law, ICANN's directors have, for more than four months failed to respond to an inquiry of Island Networks and Island Networks (Jersey) as to the IANA contractor's view on the relevance of fundamental rights to the IANA function. NTIA should require the IANA contractor to respect fundamental rights, such as those of free expression, respect for private and family life, peaceful enjoyment of possessions, fair hearing before an independent and impartial tribunal and protection of intellectual property.

Kuwait Information Technology Society (KITS) is grateful for this effort to create a more transparent process on issues relevant to the Internet and its users. While in favor of the IANA functions contractor refraining from developing policies related to IANA functions, KITS does advocate for that contractor being allowed to express an opinion from a technical point of view -- without taking part in any decision making on these policies.

KITS also suggested that, with reference to the collaboration with relevant stakeholders in C.2.2.1.2 and C.2.2.1.3, the number of stakeholders should be, at minimum, all those mentioned in C.1.4. Since the IANA functions operator may not have the capability to correctly interpret national laws related to all ccTLDs, KITS recommends that the operator collaborate with relevant ccTLDs operators in the process of documenting its decision making with respect to relevant national laws of the jurisdiction which the TLD registry serves.

KITS asked that the complaint resolution process be developed in collaboration with all relevant stakeholders and that the IANA functions contractor be obliged to forward the input of relevant stakeholders to NTIA. KITS supports requiring the contractor to gather and report on statistics regarding global IPv6 and DNSSEC deployment and suggested that the IANA functions contractor publish the monthly report described by C.4.1 and the final report described by C.4.5 to increase transparency.

Latin American and Caribbean ccTLDs Organization (LACTLD) recognized the positive value in IANA staff contributions to the policy development processes and expressed the expectation that those contributions will continue to be made in the future upon the request of the different working groups and committees involved in the PDP. In reference to C.2.2.1.3.2, LACTLD pointed out that TLDs are "circumscribed to national, local or jurisdictional legislations," which could render the definition of a unique process non-viable. Additionally, LACTLD requested more specific information on complaint resolution.

The Ministry of Industry and Information Technology (MIIT), China, believes that an international management system of Internet critical resources should be established in line with governments' and public interests, and that system should be "multilateral, democratic and transparent," as defined by the World Summit on the Information Society (WSIS).

Internet critical resources should be governed within the framework of international laws in order to ensure the security and stability of the Internet. The contractor, in cooperation with all stakeholders, needs to establish a well-defined procedure and regular reporting mechanism for root zone management and performance reports and survey and audit results should be published in the six UN working languages.

No single country or region should interfere with the activities of another country or region in administrating a local ccTLD registry by law. The gTLD registry should follow the laws of the country or region where it is located; cross-border operated TLDs should follow the laws, rules and regulations of the countries or regions where the services of domain registration are provided.

MIIT also requested more information from NTIA regarding the requirement that the IANA functions operator document consensus support and support of the global public interest for delegation requests for new gTLDs.

The Namibian Network Information Centre (NA-NiC), manager of dot-na, expressed grave concerns about the SOW's failure to address the rights of ccTLD managers, due process issues and issues surrounding TLDs established prior to awarding of DABT63-09-C-0095. NA-NiC seeks substantial revision of the draft SOW.

NetChoice is a coalition of global e-commerce and online companies and more than 10,000 small businesses that rely on the DNS. Having learned that paragraph C.2.2.1.3.2 (regarding the requirement for consensus support and support by the global public interest) requires only that the contractor include related documentation provided by the applicant, NetChoice now wants to make sure that the contractor not determine the type and quantity of documentation to be requested.

NetChoice also recommends that NTIA develop a working definition of the term "global public interest" as it relates to the IANA functions for the DNS; this term should not be used to expand the responsibilities or the scope of the IANA contractor into policy interpretation or application.

NetChoice also insists that the one-year IANA functions contract term presents an annual opportunity to "support continued accountability." NTIA should retain annual IANA contract reviews and use these as a reminder that ICANN (should it continue to serve as the contractor) serves at the pleasure of global stakeholders.

Netnod highlighted the need for increased transparency with regard to the IANA functions. They maintain that most information related to IANA's activities can be disclosed to the general public and would like to see the SOW specify that reports will be made publicly available.

Another change Netnod would like to see in the SOW is more careful use of the term 'stakeholder.' In some areas, it may make more sense to refer to only those specific stakeholders affected by IANA's processes and to call them 'affected parties.' Backup facilities for security and operational components located within the US should be established on other continents. Restrictions on policy involvement should extend beyond the contractor staff performing the IANA functions to all staff members, but Netnod joins the many other organizations interested in calling upon the unique experience of IANA staff and wants to make sure that C.2.2.1.1 not be interpreted as excluding this. Netnod also declared "Section C.2.1.3.2 Responsibility and Respect for Stakeholders" "vague and confusing. It does not make a clear distinction between the current Contractor (ICANN) and a future Contractor. Further, it confuses policy development (by current or future Contractor) and policy implementation (by the IANA function itself)."

Nokia Siemens Networks supports the open and transparent process for future modifications to the IANA functions contract and changes to IANA-related policies, as well NTIA's stated commitment to maintaining the multi-stakeholder processes on the issue of IANA functions and Internet governance. They believe that the development, standardization and governance of the Internet should stay with the organizations currently responsible for them, and that IANA functions should continue to be directed and guided by the IAB and IETF. Core IANA functions should remain bundled under one entity in order to "take advantage of the various synergies and interdependencies between the functions."

Nominet is the registry for dot-uk and has been involved in the development of the responses from the ccNSO and from CENTR, both of which Nominet endorses and supports.

Nominet made a number of recommendations:

  • Any fees should be voluntary. The IANA function is a fundamental service and some countries would be unable to pay mandatory fees for political and economic reasons.
  • The functional separation of the IANA functions contractor and the bottom-up, multi-stakeholder development of policy is important and necessary at the oversight level, but IANA staff must not be excluded from serving as advisors to policy discussions.
  • Nothing in the SOW should pre-empt work the ccNSO has initiated to clarify the policy framework for delegations and redelegations.
  • The contractor should require local parties to demonstrate that due process has been followed under local law in relation to ccTLDs. The contractor should not demonstrate how new gTLD strings have received consensus support from relevant stakeholders; at most, ICANN should provide a summary of its evaluation against recognized criteria and of how any objections were addressed.
  • The contractor should work with relevant stakeholders (in addition to NTIA and VeriSign) to deploy an automated root zone management system with appropriately secure communications and interfaces and updates for customers about the status of requests.
  • All reports should be published (including those mentioned in C.4.1 and C.4.5) unless there are clear privacy or security reasons to withhold the information.
  • The COTR should not withhold approval for changes agreed to through multi-stakeholder, consensus-based discussions in ICANN: any security or policy concerns should be raised during policy discussions.

The Number Resource Organization (NRO) underscored the need to "make the Contractor accountable to the community materially affected by their performance as well as to the NTIA." The NRO sought clarifications on points where they see potential adverse affects on the Regional Internet Registries (RIRs) and their relationship with the IANA functions contractor. RIRs must be included in the SOW wherever materially affected parties are listed. Wording should be inserted in C.2.2.1.4 specifying that the Contracting Officer's Technical Representative (COTR) should approve proposed standards and metrics unless they are found to be in direct conflict with the contract.

In developing a secured communication system, per C.3.1, the contractor should coordinate with parties materially affected by the policies. It should be specified in C.6.2 that the contractor not "change or implement established methods associated with the performance of IANA functions without direction via recognized consensus under documented multi-stakeholder processes." And, finally, the NRO proposed that the contractor not be required to gather and report statistics about global Ipv6, given the contractor's role in allocating IPv6 addresses and the complexities associated with determining if allocated and assigned IP addresses have been deployed.

The Registries Stakeholder Group (RySG) of the ICANN Generic Names Supporting Organization (GNSO) is concerned by the requirement that delegation requests for new gTLDs demonstrate consensus support from relevant stakeholders for the proposed string and support by the global public interest. According to the RySG, this provision opens the door to subjectivity and would violate C.2.2.1.1.

Looking at the Customer Service Complaint Resolution Process, the RySG recommends the addition of:

  • 24-hour customer service every day of the year
  • service level requirements for initial response times and for closure of customer service requests; and
  • monthly customer service reports posted publicly within 15 days of the previous month.

The SportAccord is the umbrella organization for Olympic and non-Olympic sports and, as such, has a direct interest in protecting the interests of its member international sports federations and organizations in connection with the expanse of the gTLD space.

With this in mind, SportAccord supports the requirement that the contractor include documentation demonstrating that a proposed string has received consensus support from relevant stakeholders and is supported by the global public interest. SportAccord believes this to be consistent with the contractor's "obligation to act as a trustee of a global resource, and in line with the concerns raised by a number of national governments in ICANN's Government Advisory Committee."

While commercial interests -- such as existing registries and registrars -- advocate for the unlimited expanse of the domain name space, the NTIA should take into account the need to address all stakeholder concerns, especially considering the recent European Commission communication regarding vertical integration, in which the issue of registrars' and registries' service on the ICANN Board and ICANN's reliance on their funds "may cast doubts on the impartiality of its decision-making."

The Taiwan Network Information Center (TWNIC) advocated for an IANA process that:

  • is neutral, open and transparent
  • takes the Internet community's best interests into consideration, and
  • recognizes and defers to the practice, operation and status of each registry (ccTLD) manager.

The United States Council for International Business (USCIB) contended that the current model of contracting with a single entity to perform the interdependent IANA functions has provided stability and should be maintained, with a focus on improving transparency and accountability.

With that focus in mind, the USCIB is in favor of functional separation of the processing of the IANA functions and the development of associated policies. This separation requires a re-examination of the requirement that the IANA contractor document compliance with relevant policies and procedures and with relevant national laws.

Compliance is a matter for the policy-making bodies and IANA contractor staff should be responsible only for documenting that the requesting organization has stated that their decision is compliant with policy, procedures and laws. USCIB recommended, too, that implementation of an automated root zone management system be tested and monitored on a ongoing basis to ensure that no problems arise that could impact the commercial aspects of most ccTLDs today. Also: NTIA should ensure that scrutiny of fees for IANA services does not rise to the level of being an inhibition to charge in order to secure a future contract.

VeriSign responded to the FNOI with input based on their experiences with the operation of the IANA functions and in their commitment to upholding the security and stability of the DNS. "On matters pertaining to Internet governance and oversight, VeriSign supports the Hippocratic principle: 'first, do no harm.' It is important to remind all stakeholders that the existing contractual framework for IANA has supported the stable, secure and efficient execution of those functions, which are critical to the operation of the Internet. Any substantive changes to that contract, therefore, must be weighed according to their potential for disrupting an efficient, effective and, above all, stable process."

VeriSign does support the SOW's clear demarcation of the contractor's policymaking and technical management functions and provision C.2.2.1.3's call for standardized metrics to document the IANA functions process, which will provide the NTIA with a valuable tool for tracking improvements in efficiency. The focus of "Section C.4 Performance Standards Metric Requirements" reflects the increased focus on metrics and transparency throughout the global community of Internet stakeholders and VeriSign noted that ICANN has already made strides toward greater transparency and more effective use of performance metrics.

Related posts