ICANN|ARCHIVES
Internet Corporation for Assigned Names and Numbers
Please note:
You are viewing archival ICANN material. Links and information may be outdated or incorrect. Visit ICANN's main website for current information.
Frequently Asked Questions (FAQs) About the Policy Development Process (PDP) on Development of Predictable Procedure for Consideration of Proposals for Contractual Approvals or Amendments
Have a question not covered in this FAQ? Please send questions to the editor of this report at <pdp-reports@icann.org>.
To help council members prepare for the renewed discussion, at the 20/21 November meeting the staff manager offered to prepare and post FAQs in response to questions submitted. The resulting FAQs appear below. These FAQs may be supplemented if additional questions are received.
- What is the issue that will be the subject of the PDP?
- Will the PDP deal with the procedure for handling requests for amendments of or approvals under ccTLD sponsorship agreements?
- Will the PDP deal with the procedure for handling requests for amendments of or approvals under sponsored TLD (sTLD) sponsorship agreements between ICANN and the sTLD sponsors?
- Does the PDP involve developing recommendations for changes to ICANN?s agreements with gTLD registry operators and sTLD sponsors?
- Why did ICANN management request the GNSO to commence this PDP?
- What changes to the current procedures are contemplated?
- When the GNSO is consulted about a particular request, how will proprietary information of registry operators and sponsors be kept confidential?
- What alternatives for handling this PDP are available under the ICANN bylaws?
- What is the issue that will be the subject of the PDP?
- How the procedure should be documented. Better and more specific documentation of the procedure will increase transparency to all affected parties, but should be done in a sufficiently flexible manner to permit the procedure to be applied in assessing registry operator/sponsor requests pursuant to the differing agreements under which they operate.
- How actions on particular registry requests should be documented, including both interim actions and final actions.
- Timelines for ICANN's actions (and for review of those actions) on requests, including actions under the "quick look" procedure.
- Measures to preserve, where possible and appropriate, proprietary information submitted in support of requests for contractual approvals or amendments.
- Procedures for ICANN to consult with outside, impartial experts to assist in ICANN?s evaluation of requests.
- Procedures for ICANN to ascertain the views of affected parties, where the "quick look" procedure determines that those parties' interests should be investigated.
- Will the PDP deal with the procedure for handling requests for amendments of or approvals under ccTLD sponsorship agreements?
- Will the PDP deal with the procedure for handling requests for amendments of or approvals under sponsored TLD (sTLD) sponsorship agreements between ICANN and the sTLD sponsors?
- Does the PDP involve developing recommendations for changes to ICANN's agreements with gTLD registry operators and sTLD sponsors?
- Why did ICANN management request the GNSO to commence this PDP?
- What changes to the current procedures are contemplated?
- When the GNSO is consulted about a particular request, how will proprietary information of registry operators and sponsors be kept confidential?
- What alternatives for handling this PDP are available under the ICANN bylaws?
The issue raised for consideration in the PDP is the development of a policy to guide the establishment of a predictable procedure for ICANN's consideration of proposals by registry operators and sponsors for changes in the architecture or operation of a gTLD registry. (See item (a) under the "Compliance with Bylaw Requirements" section of the issue report.) Aspects of the guiding policy that should be investigated include:
No. The PDP is to be conducted by the GNSO, which under ICANN?s bylaws is responsible for formulating recommended policies relating to generic top-level domains. (Bylaws Art. X, Sec. 1.) Development of recommended policies relating to ccTLDs is the responsibility of the Country-Code Names Supporting Organization. (Bylaws Art. IX, Sec. 1.)
Yes. Although portions of the policy-development authority for each sTLD are delegated to the designated sTLD sponsor, there are some situations in which an sTLD's sponsor will requests amendments to, or approvals under, the sponsorship agreement it has with ICANN. Although approval and amendment requests are much more common in the case of unsponsored TLDs than for sTLDs, the overall goals (e.g., predictability, timeliness, transparency) of the procedures for handling gTLD and sTLD requests are similar, even though there are differences in the provisions of the underlying agreements that must be observed. It therefore is appropriate to develop a recommended policy to guide the establishment of the procedures under which ICANN handles requests for approvals and amendments under ICANN's agreements for both gTLDs and sTLDs.
It should be noted that the sponsorship agreements for the current three sTLDs (.aero, .coop, and .museum) delegate to the sponsors the responsibility to select and enter agreements with those sTLDs' registry operators. The sTLD sponsors are responsible for establishing the procedures they use to handle requests made by registry operators under the agreements between the sTLD sponsors and their operators. Although PDP would not be directly concerned with such requests, sTLD sponsors may find the recommendations resulting from the PDP to be useful in developing their procedures.
No. The scope of the PDP is limited to developing recommended policies concerning the essential characteristics of the procedure by which ICANN considers registry operator or sponsor requests for contract changes and approvals to allow changes in the operation of gTLD registries. Changes to the substantive obligations of ICANN and registry operators/sponsors under their agreements are outside the scope of this PDP. Changes to the provisions of those agreements must be agreed by both ICANN and the registry operator/sponsor. Other processes (such as the currently ongoing study of the New TLD program) may investigate possible policies that might entail seeking changes to the substantive requirements of the agreements.
ICANN's procedures for handling registry requests for contractual approvals and amendments are currently informal, having been developed to address requests as they were received. Because the procedures are not broadly understood throughout the community, there is no common understanding as to when and how the community is consulted about, and participates in, ICANN's decisions as to whether to give consents or make contractual amendments. The differing expectations in the community as to the extent of consultation and participation have been significant sources of controversies, as reflected by statements by some registry operators that consultation is unnecessary. In two recent cases, registry operators implemented significant changes to TLD operations without first obtaining consents which ICANN believes should have been obtained; these changes resulted in impairments to the operation of the DNS. (In both cases, the registry operators reversed the changes after requests from ICANN.)
It is important to develop a well-documented procedure for handling requests made by registry operators under the agreements to change TLD operations. Rather than simply documenting the current procedure, however, it is appropriate to first obtain policy guidance on the essential characteristics of the procedure that ICANN should follow. This is in keeping with ICANN's commitment to community-based development of policy, and is also important to promote the development of commonly held expectations about when and how the community will be consulted when ICANN is asked to amend registry agreements or give consents under them.
The changes to be made, of course, will depend on the outcome of the PDP. As noted in the issue report: "The goal of the PDP should be the creation of a policy concerning the essential characteristics of the process by which ICANN considers registry operator or sponsor requests for contract changes and approvals to allow changes in the operation of TLD registries." Those essential characteristics will ultimately affect the detailed procedures that ICANN staff will design.
When the GNSO is consulted regarding aspects of a request for contractual changes or amendments, continuing confidentiality about those aspects is neither possible nor appropriate. ICANN's core values of developing policy in an open and transparent way, with broad, informed participation of affected stakeholders, inevitably limit the ability of a registry operator to maintain full secrecy were it wishes to change how it operates a TLD under its contract with ICANN.
Nonetheless, the PDP should explore ways (including those currently employed) to limit the extent to which information must be publicly disclosed. For example, under the current "quick look" process, consultation with outside stakeholders does not occur for uncontroversial changes. As another illustration, in consultations with the DNSO/GNSO that have occurred in the past, ICANN staff has prepared summaries of information submitted by registry operators, so that only the information necessary for informed consultation is disclosed and the proprietary nature of underlying data (e.g., detailed cost information) is preserved.
Goals of the PDP should include developing guidance as to whether these confidentiality-preserving measures are appropriate, and whether additional means of protecting proprietary information should be implemented.
According to Item 4 of the GNSO PDP, at the time it initiates a PDP the GNSO Council shall decide whether (a) to appoint a task force or (b) to proceed without a task force.
Task forces are formed from the constituencies. Item 6 of the PDP prescribes that any task force must consist of one or more representatives appointed by each constituency, with the Council having the option of appointing up to three outside advisors. Item 7 of the PDP defines the role of a task force if one is appointed:
Role of Task Force. If a task force is created, its role will generally be to (i) gather information detailing the positions of formal constituencies and provisional constituencies, if any, within the GNSO; and (ii) otherwise obtain relevant information that will enable the Task Force Report to be as complete and informative as possible.
The task force shall not have any formal decision-making authority. Rather, the role of the task force shall be to gather information that will document the positions of various parties or groups as specifically and comprehensively as possible, thereby enabling the Council to have a meaningful and informed deliberation on the issue.
Item 7 then prescribes, in subparts (b)-(e), a detailed series of steps to occur if a task force is created.
If no task force is appointed, the GNSO follows a more flexible approach, offering greater participation at the Council level, as described in Item 8 of the PDP. Each constituency appoints a representative to solicit the constituency's views on the issue and submits its position in writing on the issue within 35 calendar days. n addition, Item 8(b) (applicable only where no task force is appointed) empowers the Council to specially tailor the PDP procedures:
The Council may also pursue other options that it deems appropriate to assist in the PDP, including appointing a particular individual or organization to gather information on the issue or scheduling meetings for deliberation or briefing. All such information shall be submitted to the Staff Manager within thirty-five (35) calendar days after initiation of the PDP.
Have a question not covered in this FAQ? Please send questions to the editor of this report at <pdp-reports@icann.org>.