Public Comment is a vital part of our multistakeholder model. It provides a mechanism for stakeholders to have their opinions and recommendations formally and publicly documented. It is an opportunity for the ICANN community to effect change and improve policies and operations.
Ce contenu est uniquement disponible en
If no, please explain
1.2.16 Post Contracting (and 7.5): States that “New registry operators must delegate their TLD within one year from the date of Base RA execution”. In fact, the Base RA section 2.20 sets out circumstances where this one year period might be extended. It would be helpful to mirror that here. This could also be better clarified in 7.5.
If no, please explain
2.1.10 RSPs (and also 1.2.1.9 of Module 1): Our understanding is that the RSP pre-evaluation window will re-open when the TLD application window opens, such that RSPs who have not yet been evaluated might apply. It would be helpful if the AGB could make it clearer that if an applicant wishes to work with an RSP who has not yet been pre-evaluated they can still do so, subject to that RSP passing the evaluation, and how this should be handled when submitting the TLD application. Do they leave the RSP selection blank, and identify them later? Or can they identify an RSP in parallel to that RSP going through its pre-evaluation? 2.1.1, 2.3.1, and 1.2.1.2 (in Module 1) Payment of Invoices: It is presently envisaged that the invoice for the application fee must be paid by the earlier of 30 days of invoicing or 7 days from the close of the application window. Even a 30-day payment term can be very difficult for some companies to meet if their internal processes require the recipient first to be set up on their accounting system, which usually requires some formal documentation or order number as evidence that it is a legitimate payment. For an applicant submitting their application towards the end of the application window, 7 days will be impossible. We would suggest, for fairness, that all applicants are allowed the same payment term, to run from the date of invoice, and/or ICANN find some way to issue official evidence of the upcoming payment prior to invoicing, for those who need it in order to get ICANN set-up on their accounting systems (e.g. a pro-forma invoice, or order documentation).
If no, please explain
3.3.1 Response to GAC Advice: SubPro recommendation 30.7 refers to measures an applicant might take in response to GAC Advice and encourages GAC members to make themselves available during a specified period of time for direct dialogue with impacted applicants. AGB section 3.3.1, however, requires that an applicant has only 21 days from receipt of notice of the GAC Advice to submit a statement to the Board and GAC, which may include suggested amendments intended to address the concerns. This 21-day period seems inadequate to allow for necessary dialogue. We would suggest a longer period be permitted, or at a minimum that the 21-day period could be extended by request of the applicant. 3.5.8.1 Timing for String Confusion Objection (and 1.2.7): The timing for the 30-day window for filing string confusion objections is not clear and the language used is ambiguous. In 3.5.8.1 it says the 30 days will commence “following the publication of contention sets”. 1.2.7 refers to “30 days following publication of initial list of contention sets” but follows on from 1.2.6 which deals with updated contention sets after String Evaluation. It is unclear whether the timing runs from the initial publication of contention sets on Reveal Day (1.2.2.2), the publication of updated contention sets on String Confirmation Day (1.2.2.4), or the publication of updated contention sets following String Evaluation (1.2.6). Given the process flow in 1.3, we assume the 30-day window to object starts after String Evaluation, but this should be stated clearly. 3.5.1.1 Ground for Objection String Confusion: In 3.5.1.1, 3.5.2.1 and 3.5.5 use the capitalised, defined term “Similar” to set out the test for String Confusion Objections. However, in 1.2.4.1 footnote 19, “Similar” is defined for String Similarity as ‘means visually confusing strings, or “strings so visually similar that they create a probability of user confusion if more than one of the strings is delegated into the root zone. See String Similarity for more information.’ Given the tests for String Similarity and String Confusion Objections are different, a capitalised Similar should not be used in the String Confusion Objection test. Instead, a lower-case similar should be used in the String Confusion Objection test.
If no, please explain
4.2.3.1 Prohibition of the Private Resolution of String Contention by Applicants: This section sets out the types of communications about their application that are restricted under the AGB, and flags specific instances where applicants can discuss their application. However, there is no language around mediation and settlement of objections, which is encouraged by 3.5.8.11. Based on the last round, it is possible that one applicant in a contention set has filed an objection against another. It is unclear whether mediation and settlement still be encouraged in this situation or not, and the AGB needs to provide this clarity. This clarification could be set out in 4.2.3.2 Exceptions, or as a fourth bullet point as a ‘specific case’ where communications about the application are permitted.
If no, please explain
6.2.1 Blocked names: Why are “three letter ASCII country codes” listed as a separate bullet to “Country and Territory names in relation to Geographic Names”? The Geographic Names section which is linked-to already includes the “alpha-3 code listed in the ISO 3166-1 standard”. Is this intended to highlight some differential treatment? 6.10 and 6.10.1 Blocked names and string similarity: We appreciate the clarifying footnote 222 in section 6.10.1, making it clear that only a subset of the blocked names are considered in string similarity evaluation. However, the introductory paragraph at 6.10 does still imply that all blocked names are considered. This should be clarified for the avoidance of doubt. For example, by adding wording such as “as set out in more detail in 6.10.1”.
If no, please explain
Questions 120, 129, 135 and 141 require that the applicant certifies that “this applied-for string is not a “generic string” using the definition of "generic string" in Section 3(d) of Specification 11 of the Base RA”. There is no prohibition on a “generic string”, only on a “closed generic”. The certification is only relevant therefore if the applicant is seeking a Code of Conduct Exemption.