hi all, this is a two-for-one deal — another SSAC-report thread AND a procedure. SAC060 came out in July, this Label Generation Rules procedure implementation report was just released for comment yesterday. it would be helpful to me to have a discussion about both at the same time, since SSAC seems to be making recommendations that bear, at least in part, on this procedure. i’m happy to split this topic in two if they really AREN’T about the same thing. :-) i will be the first to admit that i’m coming from behind on this issue. Chris Wright was kind enough to take me through the baby steps i needed to get a really basic introduction to the IDN Variant topic. we made a short series of videos from that conversation and you can view them on the ISPCP site. Chris did all the heavy lifting, i just listened and learned (a lot). here’s the link for those of you who’d like to get that briefing on the basics. http://www.ispcp.info/policy-resources/idns-a-brief-whirlwind-tour/ i’ve included the Executive Summary of SAC060 and a link to the newly-released procedure below. here’s my little list of questions: - how does the new procedure align with the SSAC findings? - are there gaps, overlaps, conflicts between the two? - is this even possible? reading both reports, i am struck by how nuanced this conversation is, especially in the “Procedure” document, and wonder if it will be possible to implement something like this. - are there things that the GNSO (community or PDP) can do to help at this time? mikey here’s a link to SAC060 — https://www.icann.org/en/groups/ssac/documents/sac-060-en.pdf here’s the Executive Summary from SAC060, including brief summaries of the recommendations (sorry, once again there’s a little trouble with the formatting) Executive Summary At the request of the Board of Directors of the Internet Corporation for Assigned Names and Numbers (ICANN), the ICANN Security and Stability Advisory Committee (SSAC) provides comments and advice regarding ICANN’s Report on Examining the User Experience Implications of Active Variant TLDs.1 With respect to that Report the SSAC makes the following recommendations: Recommendation 1: 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 LGR calculations. Recommendation 3: ICANN should concentrate foremost on the rules for the root zone. 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 and recognizing that a modified version of these rules or a review or appeals process must be required to address special cases for the first and second levels; Maintaining and publishing a central repository of rules for second- level domain labels (2LDs) for all Top Level Domains (TLDs), encouraging TLD operators to publish their LGRs publicly in the repository maintained by ICANN; and Conducting specific training and outreach sessions in cooperation with generic TLD (gTLD) and country code TLD (ccTLD) operators who intend to launch Internationalized Domain Name (IDN) 2LDs or IDN TLDs, with a focus on consistency of user experience. The outreach should include among others registrants, end users, and application developers. 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.

News Alert

http://www.icann.org/en/news/announcements/announcement-2-03mar14-en.htm

IDN Variant TLDs – LGR Procedure Implementation – Maximal Starting Repertoire Version 1 is Now Open for Public Comment 3 March 2014

Forum Announcement: Comment Period Opens on Date: 3 March 2014 Categories/Tags: Internationalized Domain Names IDN IDN Variant TLD new gTLD Purpose (Brief): As first deliverable under the "Procedure to Develop and Maintain Label Generation Rules for the Root Zone With Respect to IDN Labels" [PDF, 772 KB] (the Procedure), ICANN is releasing for public comment version 1 of the Maximal Starting Repertoire (MSR-1). The contents of MSR-1 and the detailed rationale behind its development are described in "Maximal Starting Repertoire – MSR-1-Overview and Rationale" [PDF, 393 KB].

Public Comment Box Link: http://www.icann.org/en/news/public-comment/msr-03mar14-en.htm

This message was sent to mike@haven2.com from: ICANN | 12025 Waterfront Drive Suite 300 | Los Angeles, CA 90094-2536 Email Marketing by

Manage Your Subscription

PHONE: 651-647-6109, FAX: 866-280-2356, WEB: www.haven2.com, HANDLE: OConnorStP (ID for Twitter, Facebook, LinkedIn, etc.)