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.
Контент доступен только на следующих языках
If no, please explain
The language at 2.3.1 (and related text in 1.2.1.2) as currently written, would allow an applicant who submits their application on the last day of the application period only seven days to receive, process and pay in full the initial $227,000 initial fee. “The fee is due upon receipt of the invoice, and complete payment must be received by ICANN no later than seven days after the close of the application submission period. If the applicant has not paid the gTLD evaluation fee within this seven-day period, the application will generally not be processed any further and will be cancelled.” This is neither practical nor within the bounds of normal business behavior. The TAMS must be configured to automatically generate an invoice upon submission of the application and the applicant must be given no less than thirty days from the receipt of said invoice to remit full payment. Further, applicants should have an option to download a proforma invoice prior to submission of their application, to enable internal payment processes to be initiated and so ensure that ICANN’s very short payment terms can be met. The language at 2.3.3.1.4 is not consistent with the Implementation Guidance provided with respect to a refund based on a string refused due to name collision risk in Implementation Guidance 18.5. That Implementation Guidance provides for a FULL refund to applicants in the event of this type of refusal. Although 15.6 affirms the principle of cost recovery in relation to the new gTLD program, the nature of the new Name Collision Risk Assessment program is vastly different from the 2012 round and the potential impact on an applicant cannot be anticipated at the time of application given the guidelines under which the Assessment will occur. Sub Pro anticipated this possibility and Implementation Guidance 18.5 was designed to address that risk for applicants. Separately, in 2.3.3.1.3, ICANN should expressly acknowledge that a refusal by ICANN to accept a proposed Registry Voluntary Commitment made in good faith involves a material change that should result in a refund to the applicant if the string is withdrawn based on that refusal. There is a fee that must be paid by the applicant to evaluate the RVC but the potential for absolute refusal was not known at the time of Sub Pro deliberations. However, the concept of material changes to the program was clearly discussed and is covered in 2.3.3.1.3. Subsequent Board action governs the Registry Voluntary Commitment Evaluation process but nothing in the Board's actions specifies what level of refund should apply in the event of refusal of an RVC. Because the possibility of such a refusal constitutes a material change and the fact that such a refusal may occur very late in the game, a higher refund to the applicant for a withdrawal based solely on such a refusal should apply. In fact, it may be more appropriate to specify that the same percentage refund will apply to an RVC refusal as the one applicable to a refusal based on name collision risk.
If no, please explain
The language In Item (1) below does not comport with the policy. Applicants should not be prohibited from communicating on possible transfers of ownership once the Contention Sets have actually been resolved. Accordingly, these discussions should be able to take place before a Base Registry Agreement is signed. As long as no prohibited communications have occurred prior to the resolution of the Contention Set, the Board's policy is not violated. The current language for examples specifically contemplates "post-auction transfer arrangements". That language shows that such communications ARE permitted "post-auction" (not post-signing of a Base Registry Agreement.) Point (1) below should say "(1) the final resolution of the Contention Set". In addition, regarding the Examples given, the phrase "other things of value" should be modified to specify: "other things of value (such as monetary gain or operational control provisions) for withdrawing an application. For the avoidance of doubt, this provision does not prevent settlement discussions or settlements where the value to the parties is based on the resolution of disputes and associated costs in time and resources." This change is needed because in the process of settling objections and other disputes, there is always a value to the settlement itself. For example, if an applicant agrees to withdraw an application based on a Legal Rights Objection from a trademark holder, there will always be communications regarding the value of that withdrawal to the holder of the legal rights. One of the "things of value" will be the protection of the trademark holder's brand. Communicating during settlement settlement discussions regarding such "things of value" should not be prohibited. "Communications are prohibited from Reveal Day until the earlier of (1) the date a prevailing applicant signs a Base Registry Agreement (Base RA) for a specific contending gTLD string, or (2) the applicant withdraws the relevant application. The prohibition on “communicating directly or indirectly” includes public disclosures as well as private communications. Examples of prohibited communications and conduct by applicants include, but are not limited to: 1. Discussing, offering, or accepting of money or other things of value for withdrawing an application. 2. Discussing or negotiating settlement agreements or post-auction transfer arrangements in any manner with another applicant in contention for the same string with respect to any contending strings."
If no, please explain
The language in 6.1.2.4 says: A Brand TLD is a string that is identical to the textual elements (for example, a name, word, or phrase) of a registered trademark valid under applicable law and which the applicant operates as a Brand TLD. This is not consistent with the final recommendations which stated that the Trademark Clearinghouse rules on Exact Matches be implemented. Section 4.2.1 Additions to the Identical Match Rule of the TMCH manual says: “When a Trademark contains a special character that cannot be represented in a domain name label, the following rules will apply: − Special characters contained within a Trademark that are unable to be used in a domain name label may be either: (i) omitted; or (ii) replaced by hyphens. − In addition, special characters “@” and “&” contained within a Trademark may be spelled out with appropriate words of the official language(s) of the country/jurisdiction in which the mark is protected. However, in accordance with the ICANN IDN Guidelines, labels with mixed scripts will not be generated. At a minimum, Module 6 must be modified to allow special characters contained within a Trademark that are unable to be used in a domain name label may be either: (i) omitted; or (ii) replaced by hyphens; as well as allowing the special characters “@” and “&” contained within a Trademark may be spelled out with appropriate words of the official language(s) of the country/jurisdiction in which the mark is protected.
If no, please explain
The text itself is consistent with Board-adopted policy and with the SPIRT Charter adopted by the GNSO Council. The flowchart on page 351 needs one correction in that the box on the far right identifying the process for possible steps to address a policy variance in the existing round is inaccurate. The current language in that box states as follows: ICANN org, the GNSO Council, the SPiRT, and the ICANN Board develop a solution in variance of or exception to the policy for the existing round". This box should be revised to say: "ICANN org, the Board, and the GNSO Council (in consultation with the SPIRT) develop a solution in variance of or exception to the policy for the existing round." The Final Report does not permit the SPIRT to make policy so this language must be corrected. The role of the SPIRT in the event of a needed change in policy is one of consultation with the Council as the Council is responsible for policy development. The language in the flowchart must be amended in order to be consistent with the AGB text and the SPIRT Charter.