Deadline for comments from At-Large members: Close of business on Thursday, 28 July 2011
Deadline for public comments: Friday, 29 July 2011
DRAFT text for ALAC Discussion/ approval as => Comments are due on or before COB July 28th, 2011 after which the resulting text (subject to format/style edit) will be transmitted to NTIA as Comments from the ALAC.
At-Large Advisory Committee (ALAC) comments in response to the IANA Further Notice of Inquiry (FNOI)
Insert Day of July 2011
Fiona M. Alexander
Associate Administrator
Office of International Affairs
National Telecommunications and Information Administration
U.S. Department of Commerce
1401 Constitution Avenue, N.W.
Room 4701
Washington, DC 20230
IANAFunctions@ntia.doc.gov
RE: Comments on Billing Code 3510-60-P, Department of Commerce National Telecommunications and Information Administration Docket No. 110207099-1319-02 RIN 0660-XA23 The Internet Assigned Numbers Authority (IANA) Functions Further Notice of Inquiry.
The At-Large Advisory Committee (ALAC) welcomes the opportunity to provide comments in response to the Further Notice of Inquiry (FNOI) issued by the National Telecommunications and Information Administration (NTIA) regarding its contract with the Internet Corporation for Assigned Names and Numbers (ICANN) for certain Internet Assigned Numbers Authority (IANA) functions (the IANA Functions Contract).
About At-Large
At-Large is the name for the community of individual Internet users who participate in the policy development work of ICANN. More than 134 At-Large Structures (ALSes) each representing the views of hundreds and indeed thousands more individual Internet users are active throughout the world. At Large Structures are accredited organisations who are included in the ICANN community and its activities, as way to participate in building the future of the worldwide Domain Name System (DNS) and other unique identifiers which every single user of the Internet relies on with every online visit they make. These ALSes are organised into 5 Geographically defined Regional At-Large Organisations (RALOs); for more detailed information on this and these structures please see the Google Map of the RALOs and ALSes at: http://www.atlarge.icann.org/maps/ and it is through this unique and well balanced model that we claim a truly global spread of influence between ICANN and end users and individual domain name registrants 'at-large'.
About the At-Large Advisory Committee (ALAC)
The At-Large community selects a 15 person committee with 3 representatives from each of the 5 ICANN Geographic Regions. Two of these are selected/elected for staggered 2 year terms by each of the RALOs and the third is appointed via the ICANN Nominating Committee process again for 2 year terms and staggered with 3 regions alternating with the other 2 in appointment rotation. The At Large Advisory Committee (ALAC) is an essential driving force, maintaining openness, ensuring accountability and transparency in ICANN's role in the naming and addressing of the Internet. These ALAC Comments to NTIA were discussed during the July meeting of the ALAC and developed from Wiki based draft materials and text that was open to public comment and input until end 28th July. Before transmission to NTIA. It will become a 'Statement of the ALAC' when ratified by an online vote of the ALAC during August 2011.
The attached graphic shows the relationships of each of these structure within ICANN At-Large, RALO and ALAC in ICANN diagram
For more information please visit:ALAC and At-Large
ICANN At-Large Contact staff@atlarge.icann.org
----
Specific comments to FNOI:
Like other respondents and specifically the ccNSO community, ALAC welcomes NTIA’s commitment to ICANN’s multi-stakeholder process for coordination of the Internet’s Domain Name System and its decision to keep the three core IANA functions processes bundled and performed by a single entity, and further appreciates and supports the NTIA’s commitment to automation of the IANA’s root zone management functions as well as the intention for improvements to the transparency and security associated with IANA's functions and reporting. ALAC is also particuparly pleased that NTIA agrees with us and many in the Internet community in that ICANN’s multistakeholder processes must continue to respect and facilitate the participation of all stakeholders, including governments in these processes .
Like other parts of the ICANN community ALAC is concerned about the separation of Policy Development and IANA function, but like the ccNSO we also believe that that a complete prohibition on participation by IANA staff in policy development and policy-related activities that appropriately sit within ICANN’s mandate, is advantageous and serves community need to draw on expertise and information that such staff experience would bring to these deliberations, so ask NTIA to revise Section C.2.2.1.1. of the draft SOW to allow IANA staff to act as a resource in support of ICANN policy-related activities that touch on delivery of the IANA functions, as determined by the Charters of relevant Work Groups, and/or supporting organization.
C.6.2 states that the IANA functions contract does not, in and of itself, authorize ICANN to make material changes in the policies and procedures developed by the relevant entities associated with the performance of the IANA functions. The provision further prohibits ICANN from implementing policy changes without the prior approval of the U.S. government. The ALAC is most concerned about this matter* and asks NTIA to ensure assure us that, this provision is not intended to apply to policies that are properly and appropriately developed through an ICANN PDP or policy-related process.
General Comments:
Term of Contract; ALAC agrees with the points raised by ICANN in its submission to the FNOI and would seek to have a longer term contractual arrangement for IANA in the order of 5 years was contracted but would at this point in time understand if a first contract term with ICANN for a period as short a period (renewable with a following 2 year option) before any future longer term contracts were arranged for IANA functions.
Insert here additional points raised (as very brief bullets) from the ICANN response to FNOI that it wishes to agree with and/or endorse... … ….
ALAC is actively involved in the current consensus based work being carried out by Framework of Interpretation Working Group (FOIWG) in ICANN as a Cross Community Work Group (Multi Stakeholder model) several terms this group is discussing and defining relating to delegation and redelegation issues are raised/used in the FNOI, and as such ALAC is concerned that the agreed meaning(s) / definitions of terms resulting from the FOIWG outcomes and how they are used in IANA functions 'match' or “properly relate” to the meanings and intent assigned to them by NTIA. Considerable detail and rational for the concerns ALAC has on these issues are outlined in the observations, from the original provided by Mr Kieth Davidson, Chair of the FOIWG, as his personal comments to the FNOI, copied directly with the authors permission, for your ease of reference, should be read as also being endorsed as comments reflective of issues of concern by the ALAC to the FNOI on these specific matters.
”... Question 5 (NTIA Response): Some commenters stated there should be a process for ccTLDs to appeal root management zone decisions made by the IANA functions contractor, in the event it does not follow existing and documented policies. They also noted the need for the IANA functions contractor to consistently interpret broad policy guidance such as RFC 1591, ICP-1 and the GAC ccTLD Principles and publish information that documents the root zone change request process. Commenters suggested that the IANA functions contractor should better respect national sovereignty as it relates to ccTLDs, including the legitimate interests of governments, the local Internet communities, and the primacy of national laws, which have been clearly stated by the GAC in its ccTLD Principles, and the 2005 U.S. Principles on the Internet's Domain Name and Addressing System
Comment 1: The use of the term “local Internet communities” is not defined, and for clarity in referencing for the future, it may be more appropriate to use the language from RFC1591 which refers to “Interested Parties” or “Parties interested in the TLD”. The FOIWG's first report will be on terminology and is likely to include a reference to how the term 'local internet communities' should be interpreted.
C.2.2.1.1 The Contractor shall ensure that any and all staff dedicated to executing the IANA functions remain separate and removed (not involved) from any policy development that occurs related to the performance of the IANA functions.
Comment 2a: NTIA's recognition of structural separation is critical to ensure IANA remains a function or process. In the absence of policy IANA is appropriately required to seek clarification from the affected stakeholders, rather than developing policy on the fly.
Noting the NTIA response to question 3 “Furthermore, NTIA agrees with commenters 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”, it should be noted that the DRDWG had its greatest concerns with the ICANN Board decisions on delegations and redelegations of ccTLDs and their interpretation or creation of policy, rather than any general trend from IANA staff to do so. To remove any doubt regarding the decision making process, an additional clause as follows may be appropriate for inclusion as follows “Decisions on delegations and redelegations of TLDs must be made within existing policy frameworks. Where no policy exists to cover a specific instance, the relevant stakeholder communities responsible for policy development should be consulted and any decision made that is not within policy must be openly and transparently disclosed along with the justification for the decision in the specific circumstances”.
Comment 2b: It is a necessary aspect of many Policy Development Processes that IANA staff be engaged with stakeholders during the policy development, for the provision of information, advice and suggestions. This clause as currently worded could be interpreted to mean that IANA staff would be precluded from such engagement or, indeed, any discussion on applicable policies. To remove this ambiguity I offer the following revision: “In executing the IANA functions, the Contractor shall ensure that multistakeholder policy development remains free from undue influence by its staff, noting that, upon request from stakeholders, IANA staff shall continue to provide information and guidance to assist stakeholders with policy development relating to the IANA function”.
C.2.2.1.3 Perform Administrative Functions Associated With Root Zone Management - - This function addresses facilitation and coordination of the root zone of the domain name system, with 24 hour-a-day/7 days-a-week coverage. This function includes receiving delegation and redelegation requests, and investigating the circumstances pertinent to those requests. This function also includes receiving change requests for and making routine updates to all top-level domains (TLDs) contact (including technical and administrative contacts), nameserver, and delegation signer (DS) resource record (RR) information as expeditiously as possible. Within six (6) months of award, the Contractor shall submit to NTIA performance standards and metrics developed in collaboration with relevant stakeholders for approval.
Comment 3a: The 24/7 coverage of IANA administrative functions will be warmly welcomed by the ccTLD community.
Comment 3b: The FOIWG will not conclude its activities until mid year in 2013. The timeframe of 6 months referenced above would require the IANA Contractor to “second guess” the outcomes of this Working Group's activities, and therefore a staged implementation through to mid-2013 for those aspects relating to ccTLD delegation and redelegation policies would be beneficial.
C.2.2.1.3.2 Responsibility and Respect for Stakeholders - - The Contractor shall, in collaboration with all relevant stakeholders for this function, develop a process for documenting the source of the policies and procedures and how it has applied the relevant policies and procedures, such as RFC 1591, to process requests associated with TLDs.
Comment 4: RFC1591 is generally accepted by ccTLD Managers as being the applicable policy guiding the delegation and redelegation of ccTLDs, and steps by NTIA to confirm and strengthen this by enshrining it as the appropriate applicable policy within the IANA functions contract would be beneficial to the ccTLD community.
C.2.2.1.3.2 (continued) In addition, the Contractor shall act in accordance with the relevant national laws of the jurisdiction which the TLD registry serves.
Comment 5: Appreciating the sentiment of the above wording, it appears potentially ambiguous and lacks clarity. For example, if the majority of registrants in a ccTLD are from one legal jurisdiction, and the registry is operated in another jurisdiction, for a ccTLD that applies to yet another jurisdiction, which “relevant national laws” will apply? Perhaps greater clarity could be achieved through phrasing as follows “In addition the Contractor shall act in accordance with the broad principles of subsidiarity”.
C.2.2.1.3.5 Customer Service Complaint Resolution Process - - The Contractor
shall establish a process for IANA function customers to submit complaints for timely resolution.
Comment 6: In commenting on Question 5, NTIA notes “Some commenters stated there should be a process for ccTLDs to appeal root management zone decisions made by the IANA functions contractor, in the event it does not follow existing and documented policies”. The introduction of C.2.2.1.3.5 usefully introduces a valid complaints process, and perhaps could be extended to endorse the natural justice right of appeal against IANA decisions, which might be codified as follows “The Contractor shall establish and publish a process for IANA function customers to appeal any decision made by the Contractor which appears to have been made outside of existing and documented policies”....”
