Page History
Versions Compared
compared with
Key
- This line was added.
- This line was removed.
- Formatting was changed.
...
SAC060 was published on 23 July 2013. All SSAC publications can be found at https://www.icann.org/groups/ssac/documents.
| View file | ||||
|---|---|---|---|---|
|
| Recommendation | Description | Current Phase | ||||||
|---|---|---|---|---|---|---|---|---|
| Regarding ICANN's Report on Examining the User Experience Implications of Active Variant TLDs, The root zone must use one and only one set of Label Generation Rules (LGR). |
| |||||||
| Recommendation 2 | ICANN must maintain a secure, stable, and objective process to resolve cases in which some members of the community (e.g., an applicant for a TLD) do not agree with the result of the Label Generation Rules (LGR) calculations. |
...
|
| ||||||||
| Recommendation 3 | ICANN should concentrate foremost on the rules for the root zone (versus rules for TLD registry operators). |
| ||||||
| Recommendation 4 | ICANN should coordinate and encourage adoption of these rules at the second and higher levels as a starting point by: - Updating the IDN Implementation Guidelines; - Maintaining and publishing a central repository of rules for second- level domain labels (2LDs) for all Top Level Domains (TLDs); and - Conducting specific training and outreach sessions |
...
|
...
| Recommendation 5 | Be very conservative with respect to the code points that are permitted in root zone labels. |
| ||||||
| Recommendation 6 | Because the removal of a delegation from the root zone can have significant non-local impact, new rules added to a LGR must, as far as possible, be backward compatible so that new versions of the LGR do not produce results that are incompatible with historical (existent) activations. |
| ||||||
| Recommendation 7 | Should ICANN decide to implement safeguards, it should distinguish two types of failure modes when a user expects a variant to work, but it is not implemented: denial of service versus misconnection. |
| ||||||
| Recommendation 8 | A process should be developed to activate variants from allocatable variants in LGR. |
...
| |||||||
| Recommendation 9 | ICANN must ensure that Emergency Back-End Registry Operator (EBERO) providers support variant TLDs, and that parity exists for variant support in all relevant systems and functions associated with new TLD components. |
...
|
| ||||||||
| Recommendation 10 | The current rights protection regime associated with the Trademark Clearinghouse (TMCH) process is susceptible to homographic attacks. The roles of the involved parties, specifically registrars, registries, and TMCH, related to matching must be made clear. |
| ||||||
| Recommendation 11 | When registries calculate variant sets for use in validation during registration, such calculations must be done against all of the implemented LGRs covering the script in which the label is applied for. |
| ||||||
| Recommendation 12 | The matching algorithm for TMCH must be improved. |
| ||||||
| Recommendation 13 | The TMCH must add support for IDN variant TLDs. Particularly during the TM Claims service, a name registered under a TLD that has allocated variant TLDs should trigger trademark holder notifications for the registration of the name in all of its allocated variant TLDs. |
| ||||||
| Recommendation 14 | ICANN should ensure that the number of strings that are activated is as small as possible. |
|
