Policy Development Process for New gTLD Subsequent Procedures: Difference between revisions

← Older edit Newer edit →

VisualWikitext

@@ Line 190: / Line 190: @@
 | Allowed IDN applications and required consistency with root zone label generation rules
 | Affirm and continue the processing of IDN applications and the use of RZ-LGR; consider the use of single-character TLDs in cases where the character is an ideogram or ideograph; allow IDN variant TLDs for existing or applied-for strings only if the strings are applied for / operated by the same registry.
+|-
+| 26 - Security and Stability
+| Strings must not cause instability
+| Affirm and continue existing principles; shift focus on rate of change to monthly growth of the root zone (with implementation guidance around acceptable rates of change in a month), rather than delegated strings per year; "Emoji in domain names, at any level, must not be allowed"
+|-
+| 27 - Applicant Reviews: Technical & Operational, Financial, and Registry Services
+| 2007 Policy established technical, capability, criteria for evaluation and assessment
+| Affirm and maintain principles from 2007; Evaluation scores on all criteria should be limited to pass/fail (1/0); be as precise as possible to limit clarifying questions; publish all clarifying questions and responses; adjust 2012 evaluation so that applicants are not required to submit their full Security Policy; limit technical & operational evaluation if applicant opts to use a pre-evaluated RSP; simplify financial evaluation to ensure that the applicant can sustain long-term operations without imposing a "one size fits all" set of criteria
+|-
+| 28 - Role of Application Comment
+| 2012 round allowed for a public comment period on each evaluation, and such public comments could affect the scoring of the application
+| Affirm and continue the practice of soliciting community comment and the possibility that comments will impact scores; be transparent and consistent in explaining the impact of comment submission, the process of accepting comments, and the opportunities for applicants to respond; ensure that commenters validate an email address before commenting, and make best efforts to verify the commenter's identity; require commenters to reveal affiliations with the applicant; Emphasize ease of use in comment submission and allow attachments to comments; allow comments on confidential portions of the application, or submissions of confidential material, and allow applicants to respond under the same shield of confidentiality
+|-
+| 29 - Name Collisions
+| [[New gTLD Collision Occurrence Management]] framework
+| Affirm and continue use of the current collision management framework unless and until the ICANN Board approves a new one; ICANN must have a mechanism in place to evaluate the risk of name collisions prior to the launch of the application period
+|-
+| 30 - GAC Consensus Advice and GAC Early Warning
+| [[ICANN Bylaws]] cover consensus advice; 2012 AGB: “Concurrent with the [public] comment period, ICANN’s Governmental Advisory Committee (GAC) may issue a GAC Early Warning notice concerning an application. This provides the applicant with an indication that the application is seen as potentially sensitive or problematic by one or more governments.”
+| Consensus advice should be submitted to the Board prior to the finalization of the Applicant Guidebook for a given round; replace the "strong presumption that an application will be rejected" language from the AGB with a description of the voting threshold for the ICANN Board to reject consensus advice; either permit GAC Early Warnings within the application comment period, or specifically define a timeframe in which GAC Early Warnings may be submitted; permit applicants to submit changes to their application in response to consensus advice or early warnings
+|-
+| 31 - Objections
+| 2007 Policy established objection mechanisms, rationales, and criteria for assessment of objections
+| "The Working Group affirms the overall approach to the public objection and dispute resolution process described in Section 3.2 of the 2012 Applicant Guidebook, subject to the recommendations below. The Working Group further affirms that parties with standing should continue to be able to file formal objections with designated third-party dispute resolution providers on specific applications based on the following grounds: (i) String Confusion Objection (ii) Existing Legal Rights Objection (iii) Limited Public Interest Objection (iv) Community Objection;" Affirms the role of the Independent Objector, subject to incorporation of conflict of interest protections; transparent and clear process & explainers for objection proceedings; expand "quick look" process to allow dismissal of of "frivolous and/or abusive objections;" allow applicants to amend application or adopt RVCs to address and resolve objections; reduce risk of varying outcomes in string confusion objections (specific guidance provided)
+|-
+| 32 - Limited Challenge/Appeal Mechanism
+| [[ICANN Accountability]] measures, and in particular [[Reconsideration]], were available to applicants
+| "The Working Group recommends that ICANN establish a mechanism that allows specific parties to challenge or appeal certain types of actions or inactions that appear to be inconsistent with the Applicant Guidebook;" establish clear procedures and rules for use of the mechanism; apply a "clearly erroneous" standard to all appeals except conflict of interest appeals, which will be reviewed de novo; remedies, process and other suggested rules are detailed in Annex F of the Final Report
+|-
+| 33 - Dispute Resolution Procedures After Delegation
+| [[PICDRP]] and [[RRDRP]]
+| Affirm and continue the PICDRP and RRDRP; enhance, clarify, and better define guidance on the scope and uses of those appeal processes; Working Group declined to issue recommendation on the [[Trademark Post-Delegation Dispute Resolution Procedure]], as that was being reviewed by the [[PDP Review of All Rights Protection Mechanisms in All gTLDs]]
+|-
+| 34 - Community Applications
+| [[Community Priority Evaluation]] process to give priority to applicants who submit a community application
+| Affirm and continue the CPE process, with several amendments to the Applicant Guidebook delineating the rules of that process; Selection of CPE provider, and portions of the contract with the CPE provider that describe or provide specifications of the CPE process, should be public and subject to public comment; CPE procedures must be finalized and published prior to the start of the application period; amend AGB to set parameters around independent research by CPE provider: "The Community Priority Evaluation Panel may perform independent research deemed necessary to evaluate the application (the 'Limited Research'), provided, however, that the evaluator shall disclose the results of such Limited Research to the applicant and the applicant shall have an opportunity to respond. The applicant shall be provided 30 days to respond before the evaluation decision is rendered. When conducting any such Limited Research, panelists are cautioned not to assume an advocacy role either for or against the applicant or application."
+|-
+| 35 - Auctions: Mechanisms of Last Resort / Private Resolution of Contention Sets
+| [[Auction of Last Resort]] mechanism
+| Affirm and expand the means by which applicants may resolve contention sets, including business combinations or joint ventures, as well as auctions of last resort; applicants must affirmatively attest to a bona fide intention to operate a registry for the applied-for string; utilize the second-price auction method for ICANN auctions, with additional recommendations for rules and procedure; introduce "Contention Resolution Transparency Requirements"
+|-
+| 36 - Base Registry Agreement
+| Single Base [[Registry Agreement]] with Specifications
+| Affirm the use of a single base agreement with specifications; Affirm many recommendations and implementation guidelines from the 2007 policy; create a clearer, more transparent, and more predictable way to apply for, negotiate, and obtain exemptions to certain provisions of the base RA based on the unique circumstances of the operation of a particular registry; ICANN must add a covenant that the registry operator will not engage in "fraudulent or deceptive practices"
+|-
+| 37 - Registrar Non-Discrimination & Registry/Registrar Standardization
+| Registries must use ICANN accredited registrars, and may not discriminte between them
+| Affirm with modifications permitting a registry to request an exemption, subject to public comment
+|-
+| 38 - Registrar Support for New gTLDs
+| Registrars may choose which gTLDs to carry
+| Affirm
+|-
+| 39 - Registry System Testing
+| No current method
+| ICANN must develop a set of Registry System tests that demonstrate the technical capabilities of the registry operator; testing must be efficient (i.e. not duplicative of technical evaluation tests), but ICANN should not rely on registry self-certification unless testing would be disruptive of the security of the DNS
+|-
+| 40 - TLD Rollout
+| 2012 [[Applicant Guidebook]] and base [[Registry Agreement]]: successful applicants have nine (9) months following the date of being notified that is successfully completed the evaluation process to enter into a Registry Agreement; and registry operators must complete all testing procedures for delegation of the TLD into the root zone within twelve (12) months of the Effective Date of the Registry Agreement. Extensions of time are permitted.
+| Affirm and maintain current policies
+|-
+| 41 - Contractual Compliance
+| [[Registrar Accreditation Agreement]] and [[Registry Agreement]] must contain "a clear compliance and sanctions process"
+| Affirm, with the addition of more detailed reporting from [[Contractual Compliance]] regarding the context of the opening and closing of compliance actions (e.g. why an action was closed), and the standards or thresholds that Contractual Compliance utilizes in evaluating and accepting complaints for further action
 |}