A place for the DG to collaborate.


As discussed on the first call, please provide your issue(s) that you want to be captured by the Discussion Group. You can edit this page to directly add your inputs here or you can add an attachment.

Issues from the First Round of New gTLDs

Add here or as an attachment...

  • No labels

7 Comments

  1. Posted Considering Informed Consent for City-TLD Applicants with some initial thoughts on the future application process for city-TLDs.

  2. Availability of RRA's in multiple languages prior to any set sunrise dates for registrars.

  3. Coming at this task from the perspective of a development economist who has had discussions with gTLD aspirants in Africa, and with African registrars, I want to make sure I have one thing clear. In addition to the costs and complications of application for a developing country gTLD applicant, the registrars raise the issue of ICANN contract language as it complicates sourcing both local financing and local insurance coverage. Am I correct in assuming that contract language is NOT a topic for the working group?  

  4. Registrar perspective:

    • Unified accreditation process (AROS?)
    • Response time requirements for Registries to accreditation requests
    • Requirement for provision of RAA in English non-binding reference copy.
    • Sunrise notice requirement expanded to availability of complete accreditation documentation and agreements at the time of the sunrise notice to allow timely accreditation
    • Registries should be required to disclose all promotional programs offered to registrars to prevent anti-competitive behavior
    • Removal of mandatory pre-registration TMCH notices to registrants

    General:

    • Open ended application process
    • Reductions in fees for identical applications
    • ICANN: Stick to the process and agreements defined by the community during or after the application process. No more last minute changes, no further concessions to lobbying, no more bites from the apple
    • Release procedure for all two-letter strings 
    • Clearer rules to prevent potential abuse of Spec 13 by generic TLDs


  5. Most of the items that follow speak to the need for ICANN to create an equitable, timely, predictable, transparent and accountable program.  Fortunately for applicants in subsequent rounds, many of the issues current applicants had and/or still do will very likely have been resolved. 

    Introduction of new program elements, some at particularly inopportune times, others in a very top-down approach and others often with little or no opportunity for community input:

    • Public Interest Commitments introduced in early 2013 and just prior to the deadline for filing objections and the anticipated receipt of GAC Advice.

    • TMCH details were initially developed in a vacuum and without engagement of the very experts (e.g., registries and registrars) charged with implementation.

    • Name Collision issue: introduced in August 2013, more than a year after the application deadline, and now more than a year later it still has unresolved issues.

    • Rules/guidelines wrt to CPE evaluators were developed long after the publication of the applicant guidebook and vague at best after months of delays waiting for such information. The CPE process needs to be completely revamped for the next round.

    ICANN not following the applicant guidebook:

    • Making up new processes sometimes years after the publication of the “final” guidebook.

    • GAC Advice was to be levied on individual applications, not classes of applications, which thereby created unnecessary work and distraction for parties that likely would not have been affected.

    Seemingly very little appreciation by ICANN for the business implications of their making up rules and processes on the fly and not adhering to the applicant guidebook including its estimated timelines of completion of critical path activities.

    Communications with applicants have been extremely inconsistent:

    • Sometimes quick responses

    • Sometimes very delayed responses

    • Sometimes no responses

    • Sometime non-answer responses

    Spurious use of ICANN Accountability and Review Mechanisms:

    • ICANN should have a quick-look process for uses of the three mechanisms (i.e., Request for Reconsideration, Independent Review, Ombudsman) to fend off abuse of the processes.

    • The Ombudsman mechanism, particularly in use for new gTLD cases, should have clear timelines and guidelines for process and resolution to avoid abuse of this process. For example, it shouldn’t take several months to get a report from the Ombudsman that effectively states consideration of the issue is outside his jurisdiction.

    Spurious activities, as they are propagated in connection with community applicants:

    • Encourage more activity since it often goes unchecked.

    • Enables business applicants to control the process.

    • Intimidates the supporters/endorsers as activity including letters containing misstatements about the application are often set to application supporters and their members. Deliberate misstatements sent with the only intention of causing alarm in the community and amongst supporters and hoping to create negative comments. 

    • Subsequent round applicants will find it harder to gain community support if they feel they are targeted for bullying.

    ICANN failure to fulfill its responsibility to launch new gTLDs to foster competition, consumer choice and consumer trust:

    • One example is the failure to rule out the permissibility of plural gTLDs; regrettably this already appears to be resulting in consumer confusion.  

    • ICANN could have for example mandated verification of registrants in gTLDs representative of highly regulated industries, per the GAC’s Advice, and rather succumbed to lobby by interested parties for a lesser approach.
  6. Issues from perspective of a trade mark owner

     

    URS:

    Lack of transfer of the domain name to TM owner, either at conclusion of the URS or at the end of the registered term;

    No opportunity for complainant to correct administrative errors – lack of balance between complainant and registrant;

    Consider whether it is appropriate to dispense with a full assessment on merits in the registrant defaults, given that they have opportunity to seek de novo review;

    Lack of balance due to limited financial risk to registrant.  Consider loser pays model;

    Lack of balance on “abuse”.  Currently for complainant – one year ban for two abusive complaints, possible permanent ban thereafter and no appeal on a finding of “abuse; for registrant - no penalty for abuse of process or recidivist cybersquatting.

     

    TMCH:

    Can the value of the TMCH registration be extended, eg use as proof of ownership rights for a UDRP;

    Since a TMCH recordal is a pre-requisite for qualifying as a dotBrand for Spec 13 there should be no requirement to also file a TM certificate;

    Issues around decision not to allow TM Claims for confusingly similar strings and “mark plus”, where the “plus” is a descriptive term;

    Consider making the TM Claims service a genuinely protective mechanism by giving the TM owner advance notice of registration with a mechanism for objection.

     

    Clarification of the rules around Reserved Names:

    Rules are insufficiently clear and thus open to interpretation and abuse to circumvent the sunrise.  Consideration needed as to whether there should be limits on the number of reserved names, prohibitions against reserving TMCH terms, and/or all subsequently-released names being offered on a sunrise.

     

    Clarification of rules on Premium pricing:

    Rules are insufficiently clear and thus open to interpretation and abuse.  Greater certainty required on what is permissible around the designation of names as premium, where they are trademarked terms, and on limits as to numbers.

     

    Block lists:

    The DPML has demonstrated what can be done.  There should be consideration of whether a formalised version of this could form part of any future application round, or whether applicants who voluntarily adopt such a mechanism are awarded additional evaluation points.

  7. Apologies if any of this duplicates what others have said

    Issues from perspective of an applicant (generally but not limited to dot Brands)

    Issues around robustness and scalability of ICANN systems: eg TAS Glitch, Digital Archery, CZDS problems

    Streamlining of the application process:

    One size does not fit all.  Failure to adopt a process that recognised that there are different types of  applications and these have different risk levels, methods of operation, and work/ costs involved in evaluating and thus should have different application process, fees and contractual requirements

    Background checks - Officers of publicly traded corporations, which already meet or exceed any screening ICANN does, do not need background checks

    Provide pre-approved back end providers, which would simplify the technical and operation portion of the application

    Data entry on application form – larger windows for free-text fields, clear notification when end of field length has been reached, ability to easily see uploaded document, ability to have more than one person working on an account at the same time, copy facility for similar applications by same applicant. Search and replace facility

    COIs - consider whether insurance could be a suitable alternative.  If there is to be a Letter of credit ICANN should provide compliant templates which recognise legal requirements in different countries.

    To facilitate ability to pay, provide applicants with option to receive an invoice in advance.

    Change requests - could be simplified and made more efficient.  Eg allow applicant to make requested changes directly in their application online, for review by ICANN.

    Consider whether there should be limits on numbers of applications by any one applicant/group of associated companies)

    Lack of certainty in the process for applicants due to lack of finalised policy / changes in policy after the event: eg open / closed generics, PICs, name collision. 

    Issues as a result of GAC issuing advice which is non-exhaustive as to the strings affected, subject to unpredictable timelines, lacking in transparent reasoning and not based on clearly-established guidelines for applicants.

    ICANN Failure to stick to timelines and lack of parity for missed deadlines.

    Decision that singular and plurals of the same string should generally not be considered in contention

    Dispute resolution issues - Inconsistent string contention panel decisions, timing of release of decisions, need to ensure the procedural rules are adhered to – times, statements of grounds, etc.  Consider having a single body with oversight over the providers; clearer criteria.

    Need for appeal mechanism to address clearly inconsistent decisions.

    Independent Objector – Issues around handling of conflict of interest (or perception of possible conflict).  Consider additional alternative IO to minimise risk.

    Auctions - Consider whether auctions are the most appropriate method of resolving contention.  Consider allowing applicants to designate an alternative related string, at a cost, at the time of application which could be adopted if the primary string is in contention.

    Indirect contention – still no rules to address this.

    GDD Service level and communication issues, as set out in the extensive letter from the RySG and NTAG.

    TMCH – consider level of fees for dotBrand Registries who do not run a Sunrise.