<html><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;">hi all,<div><br></div><div>i’m using Kal’s comment as a great reason to start up a new thread that focuses on SAC060. i’m going to put my kickoff questions at the top of this post and then provide background and documentation links below.</div><div><br></div><div>some thread-starting questions:</div><div><br></div><div>- what do the “ongoing” and “open” statuses in MyICANN imply? </div><div><br></div><div>- opening up the details under the recommendations i’m confronted with many “TBC” entries — what does that mean. to be considered? to be confirmed? to be completed? </div><div><br></div><div>- only a couple of the entries on this page list an action-taken by the Board - is there a plan?</div><div><br></div><div>- Recommendation 9 (the one about emergency back-end operators/EBERO’s supporting variant TLDs) is listed as closed and fully implemented. is that possible, given the other open issues? </div><div><br></div><div>- what’s the overall status of all this? good? bad? </div><div><br></div><div>- there are a fair number of IDNs in the root now — is the the user-experience framework far enough along that we’re comfortable that label generation rules (LGRs) will not conflict?</div><div><br></div><div>- given all this, is there GNSO policy-action (initial report, alert to a currently-running Working Group, notification to constituencies and stakeholder groups, etc.) that would be helpful in moving this along?</div><div><br></div><div>mikey</div><div><br></div><div><br></div><div>here’s a link to the report</div><div><br></div><div><span class="Apple-tab-span" style="white-space:pre"> </span><a href="https://www.icann.org/en/groups/ssac/documents/sac-060-en.pdf">https://www.icann.org/en/groups/ssac/documents/sac-060-en.pdf</a></div><div><br></div><div>here’s a (sorry, gigantic) link that will take you to a listing of the recommendations and their current status on MyICANN</div><div><br></div><div><span class="Apple-tab-span" style="white-space:pre"> </span><a href="https://www.myicann.org/board-advice#advice-to-board_f=sac060&advice-to-board_d=false">https://www.myicann.org/board-advice#advice-to-board_f=sac060&advice-to-board_d=false</a></div><div><br></div><div>and here’s the list of recommendations from the SAC060 Executive Summary (any typos are mine, i had to retype these)</div><div><br></div><div><b>Recommendation 1:</b> The root zone must use one and only one set of Label Generation Rules (LGR). <br><br><b>Recommendation 2:</b> 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. <br><br><b>Recommendation 3:</b> ICANN should concentrate foremost on the rules for the root zone. <br><br><b>Recommendation 4:</b> ICANN should coordinate and encourage adoption of these rules at the second and higher levels as a starting point by: <br><br></div><blockquote style="margin: 0 0 0 40px; border: none; padding: 0px;"><div>• 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; </div><div><br></div><div>• Maintaining and publishing a central repository of rules for second - level domain labels ( 2LD s ) for all Top Level Domains ( TLDs ), encouraging TLD operators to publish their LGRs publicly in the repository maintained by ICANN; and </div><div><br></div><div>• Conducting specific training and outreach sessions in cooperation with generic TLD ( gTLD ) and country code TLD ( ccTLD ) operators who intend to launch Internationalize d 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. </div></blockquote><div><br><b>Recommendation 5:</b> Be very conservative with respect to the code points that are permitted in root zone labels. <br><br><b>Recommendation 6:</b> 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.</div><div><br></div><div><div><b>Recommendation 7:</b> 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. </div><div><br></div><div><b>Recommendation 8:</b> A process should be developed to activate variants from alloca ta ble variants in LGR. </div><div><br></div><div><b>Recommendation 9:</b> 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. </div><div><br></div><div><b>Recommendation 10:</b> 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. </div><div><br></div><div><b>Recommendation 11:</b> 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. </div><div><br></div><div><b>Recommendation 12:</b> The matching algorithm for TMCH must be improved. </div><div><br></div><div><b>Recommendation 13:</b> 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. </div><div><br></div><div><b>Recommendation 14:</b> ICANN should ensure that the number of strings that are activated is as small as possible</div></div><div><br></div><div><br></div><div><br>On Feb 24, 2014, at 1:15 AM, Kal Feher <<a href="mailto:Kal.Feher@ariservices.com">Kal.Feher@ariservices.com</a>> wrote:<br><br><blockquote type="cite"><br><br>i have an almost-sure recollection that there's a review of the new-gTLD rollout that is supposed to happen some time (1-year, 2-years?) after launch. from a policy-making standpoint, which things in this discussion can wait for that review and which (if any) are more urgent and might require policy attention - again, keeping the focus on SSR if possible.<br><br>KF - IMO anything requiring changes in behaviour for systems already in use should be addressed as soon as possible. SSAC60 comments on an ICANN report which attempted to predict user expectations of variants at the root, based on observations at the lower levels. So at the heart of the conclusions in the original report and therefore underpinning the advice within SSAC60, are assumptions about user expectations, which in turn are influenced by system behaviour. Implementing changes after users have already adapted to existing behaviour may introduce instability. So I'd suggest we address:<br><br>KF - Recommendation 11<br><span class="Apple-tab-span" style="white-space:pre"> </span>Registries and Registrars (in presenting options to registrants) will already be using LGRs. If LGRs are to be modified, they should be done as soon as possible. Otherwise you run the risk that implementation is effectively impossible without grandfathering domains which break any expanded variant set <- which of course will confuse users even more. There should probably be some kind of drop dead date for this recommendation if not implemented. Otherwise you'll do more harm than good. Of course, in order to create the universal variant set, a registry will need to know all current (and soon to be implemented?) LGRs for that script. So the concise list will need to exist first.<br><br>KF - Recommendation 12<br>For the same reason as 11. Since labels are not exclusively allocated to users in the TMCH, there shouldn't be any grandfathering problems. But expectations of protection/notification may change as will the labels for which SMDs are eligible. <-presumably new SMDs would be provided to those applicable<br><br><br><br>On Feb 21, 2014, at 1:53 AM, Patrik Fältström <<a href="mailto:paf@frobbit.se">paf@frobbit.se</a>> wrote:<br><br><blockquote type="cite">On 2014-02-21 07:55, Kal Feher wrote:<br><blockquote type="cite">Comments in line.<br><br>KF - point taken, but vague assertions to dire consequences in any <br>stakeholder forum are of little use to the community and should be <br>discouraged.<br></blockquote><br>Once again, if comments are taken out of context, they will be out of <br>context. So that the assertions are vague I blame whoever did copy the <br>subset of the discussion (that also was via voice, not only text).<br><br><blockquote type="cite">KF - Frustration at a lack of progress should not automatically <br>translate to advice not to adhere to your Registry Agreement. I think <br>some perspective is required.<br></blockquote><br>There have not been any such advice that I know of.<br><br><blockquote type="cite">Please see the SSAC report.<br><br>KF - I reiterate that it is generic and lacking any actual detail, <br>especially with regards to security or stability issues. There's a <br>suggestion (recommendation 10) to clarify roles, which is certainly a <br>good idea, but hardly catastrophic if not implemented and has little <br>value in preventing homographic attacks.<br></blockquote><br>A clarification of the roles now exists.<br><br>The Registry Agreement (RPM Requirements) says that registries must <br>check all names in a variant set during the TM Claims period.<br><br>This is _not_ updated in the scorecard.<br><br><blockquote type="cite">KF - I think the TMCH should certainly be improved, I have a list of <br>gripes that would keep IBM busy for years, but we should be clear <br>about risks and impact. I see plenty situations in which TMCH clients <br>will not receive the result they expect. But there doesn't appear to <br>be any security or stability risks that can be coherently described.<br>Certainly none in the report.<br></blockquote><br>SSAC has as a role do detect stability risks which include cases where <br>the functionality of a system is not according to the claims.<br><br>TMCH is well defined for the latin script, but not for non-latin <br>scripts. Specifically when you have cases where different LGR is used <br>for the same script in two different TLDs.<br><br>Now, whether we will get different LGR for different TLDs is something <br>only the integration panel can say anything about.<br><br><blockquote type="cite">The SSAC document point out that the matching rules used in the TMCH <br>are not the same as the combination of matching rules plus variant <br>rules, specifically for non-ascii scripts.<br><br>KF - Irrelevant. Homographic attacks require an actual registration.<br>Either a registry's LGR's prevent it or they don't. for the TMCH it <br>is more a failure of user expectations, which should not be conflated <br>with an attack. It is important, but should be addressed separately.<br></blockquote><br>SSAC disagree with this conclusion of yours. But it is perfectly ok of <br>course for you to draw the conclusion that you do not think the issues <br>with IDN and variants in TMCH is a problem. That is your choice.<br><br>SSAC do think it is a problem that the TMCH does not have any well <br>defined rules for non-latin script. YMMV.<br><br><blockquote type="cite">KF - What of the registries that should be EBERO'd? If true it is of <br>serious concern, if not true we really need to tone down the hyperbole.<br></blockquote><br>The EBERO is an issue separate from TMCH and the question was whether <br>a zone that is not signed correctly is according to the EBERO <br>specification "broken" in such a way that EBERO can be invoked.<br><br>That question is not answered and not clear in the EBERO specification <br>or elsewhere. It would be sad if it is the case it will only be <br>resolved in court or arbitration when a real case is on the table.<br><br>Patrik<br><br><br><br></blockquote><br><br>PHONE: 651-647-6109, FAX: 866-280-2356, WEB: <a href="http://www.haven2.com">www.haven2.com</a>, HANDLE: OConnorStP (ID for Twitter, Facebook, LinkedIn, etc.)<br><br></blockquote><br><div><br>PHONE: 651-647-6109, FAX: 866-280-2356, WEB: <a href="http://www.haven2.com">www.haven2.com</a>, HANDLE: OConnorStP (ID for Twitter, Facebook, LinkedIn, etc.)<br></div><br></div></body></html>