hi all, here’s a snip from the chat transcript of the recent CEO/Community-Leaders webinar. i’m curious about the “broken TMCH” comment that Patrik made. Patrik (or others) would you like to expand on that? i’m curious whether that would be an SSR topic that one/all of the GNSO constituencies might want to request a review by the SSAC. here’s the chat transcript: Patrik Fältström: I would like to remind everyone that regarding the issues SSAC have seen on broken TMCH has not been acted on, at all. And I urge people to not rely on TMCH yet. In any process. Patrik Fältström: https://www.myicann.org/board-advice#advice-to-board_f=tmch&advice-to-board_... Michele Neylon: Security + stability issues should be core Michele Neylon: I thought they were core to ICANN’s mission Patrik Fältström: I also want to point out that we do have new gTLDs that are so broken technically that I think various clauses that say EBERO could be invoked has matched. Michele Neylon: Patrik - already? Michele Neylon: wow Patrik Fältström: Part from me supporting the issue that Michele mentioned, that the fact people in some legislations cannot sign contracts with ICANN due to US-centric clauses is something that MUST be addresses, or else our enemies might be able to say that "the internal ICANN change processes does not work" PHONE: 651-647-6109, FAX: 866-280-2356, WEB: www.haven2.com, HANDLE: OConnorStP (ID for Twitter, Facebook, LinkedIn, etc.)
On 2014-02-20 17:51, Mike O'Connor wrote:
hi all,
here’s a snip from the chat transcript of the recent CEO/Community-Leaders webinar. i’m curious about the “broken TMCH” comment that Patrik made. Patrik (or others) would you like to expand on that?
The question is whether a TLD that is not signed correctly with DNSSEC, and because of that does not validate, is to be classified as "not working" according to the criteria in EBERO. Patrik
i’m curious whether that would be an SSR topic that one/all of the GNSO constituencies might want to request a review by the SSAC.
here’s the chat transcript:
Patrik Fältström: I would like to remind everyone that regarding the issues SSAC have seen on broken TMCH has not been acted on, at all. And I urge people to not rely on TMCH yet. In any process.
Patrik Fältström: https://www.myicann.org/board-advice#advice-to-board_f=tmch&advice-to-board_...
Michele Neylon: Security + stability issues should be core
Michele Neylon: I thought they were core to ICANN’s mission
Patrik Fältström: I also want to point out that we do have new gTLDs that are so broken technically that I think various clauses that say EBERO could be invoked has matched.
Michele Neylon: Patrik - already?
Michele Neylon: wow
Patrik Fältström: Part from me supporting the issue that Michele mentioned, that the fact people in some legislations cannot sign contracts with ICANN due to US-centric clauses is something that MUST be addresses, or else our enemies might be able to say that "the internal ICANN change processes does not work"
PHONE: 651-647-6109, FAX: 866-280-2356, WEB: www.haven2.com <http://www.haven2.com>, HANDLE: OConnorStP (ID for Twitter, Facebook, LinkedIn, etc.)
_______________________________________________ Gnso-ssr mailing list Gnso-ssr@icann.org https://mm.icann.org/mailman/listinfo/gnso-ssr
I find these kinds of vague assertions troubling. Not only do they cause drama with little path to resolution, they also increase the barrier to participation in working groups because new entrants are expected to know (intuitively? through osmosis?) these issues in order to discuss them. So if you take nothing else from my email, I ask that everyone please at least clarify predictions of doom with actual evidence matching the prediction. The advice linked in the email is generic advice regarding LGRs. I'm not clear how a malign TMCH label can cause harm in a registry with label generation rules that enforce homogeneity and prevent cross language/script homographic attacks. Is this advice for Registries that aren't using effective LGRs? Is this advice for the TMCH being sued because said malicious registrant can't actually use their SMD effectively (because registries prevent the label)? Is this a legal risk or a risk to infrastructure or DNS consumers? Are we going to address legal risks on this mailing list? What can't we trust the TMCH for? What is the risk? <- again is it legal, infrastructure, other..? I'm concerned that TLDs may not be meeting their SLAs. Is there a mechanism we can use to exchange examples and suggestions without turning it into a finger pointing exercise? My understanding of EBERO activation is that it is primarily a mechanism to protect registrants and DNS consumers. Are they at risk? Are contracts a Security, Stability or Resiliency issue? (I realise this post was from another mailing list, where contracts may be of relevance) Kal From: gnso-ssr-bounces@icann.org [mailto:gnso-ssr-bounces@icann.org] On Behalf Of Mike O'Connor Sent: Friday, 21 February 2014 3:51 AM To: GNSO SSR List Subject: [Gnso-ssr] Broken TMCH? hi all, here's a snip from the chat transcript of the recent CEO/Community-Leaders webinar. i'm curious about the "broken TMCH" comment that Patrik made. Patrik (or others) would you like to expand on that? i'm curious whether that would be an SSR topic that one/all of the GNSO constituencies might want to request a review by the SSAC. here's the chat transcript: Patrik Fältström: I would like to remind everyone that regarding the issues SSAC have seen on broken TMCH has not been acted on, at all. And I urge people to not rely on TMCH yet. In any process. Patrik Fältström: https://www.myicann.org/board-advice#advice-to-board_f=tmch&advice-to-board_... Michele Neylon: Security + stability issues should be core Michele Neylon: I thought they were core to ICANN's mission Patrik Fältström: I also want to point out that we do have new gTLDs that are so broken technically that I think various clauses that say EBERO could be invoked has matched. Michele Neylon: Patrik - already? Michele Neylon: wow Patrik Fältström: Part from me supporting the issue that Michele mentioned, that the fact people in some legislations cannot sign contracts with ICANN due to US-centric clauses is something that MUST be addresses, or else our enemies might be able to say that "the internal ICANN change processes does not work" PHONE: 651-647-6109, FAX: 866-280-2356, WEB: www.haven2.com<http://www.haven2.com>, HANDLE: OConnorStP (ID for Twitter, Facebook, LinkedIn, etc.)
On 2014-02-21 00:43, Kal Feher wrote:
I find these kinds of vague assertions troubling.
The statements where made during a telephone conference between SO/AC/SG chairs, and is copied text from the telephone conference adjacent chat room. They are definitely not conclusive descriptions of the situation. What people also should have a look at to know the status of advice is the tracking mechanism for advice to the board. You can find the tracker here for the TMCH issues: <https://www.myicann.org/board-advice#advice-to-board_f=tmch&advice-to-board_...>
The advice linked in the email is generic advice regarding LGRs. I’m not clear how a malign TMCH label can cause harm in a registry with label generation rules that enforce homogeneity and prevent cross language/script homographic attacks.
Please see the SSAC report.
Is this advice for Registries that aren’t using effective LGRs? Is this advice for the TMCH being sued because said malicious registrant can’t actually use their SMD effectively (because registries prevent the label)? Is this a legal risk or a risk to infrastructure or DNS consumers? Are we going to address legal risks on this mailing list?
The SSAC document point out that the matching rules used in the TMCH are not the same as the combination of matching rules plus variant rules, specifically for non-ascii scripts. Patrik
Comments in line. On 2014-02-21 00:43, Kal Feher wrote:
I find these kinds of vague assertions troubling.
The statements where made during a telephone conference between SO/AC/SG chairs, and is copied text from the telephone conference adjacent chat room. They are definitely not conclusive descriptions of the situation. KF - point taken, but vague assertions to dire consequences in any stakeholder forum are of little use to the community and should be discouraged. What people also should have a look at to know the status of advice is the tracking mechanism for advice to the board. You can find the tracker here for the TMCH issues: KF - Frustration at a lack of progress should not automatically translate to advice not to adhere to your Registry Agreement. I think some perspective is required. <https://www.myicann.org/board-advice#advice-to-board_f=tmch&advice-to-board_...>
The advice linked in the email is generic advice regarding LGRs. I'm not clear how a malign TMCH label can cause harm in a registry with label generation rules that enforce homogeneity and prevent cross language/script homographic attacks.
Please see the SSAC report. KF - I reiterate that it is generic and lacking any actual detail, especially with regards to security or stability issues. There's a suggestion (recommendation 10) to clarify roles, which is certainly a good idea, but hardly catastrophic if not implemented and has little value in preventing homographic attacks. recommendation 11 applies to registries not the TMCH and recommendation 12 will help TMCH clients get the names they actually want, but again no security or stability risks. Are they buried somewhere else in the report? KF - I think the TMCH should certainly be improved, I have a list of gripes that would keep IBM busy for years, but we should be clear about risks and impact. I see plenty situations in which TMCH clients will not receive the result they expect. But there doesn't appear to be any security or stability risks that can be coherently described. Certainly none in the report.
Is this advice for Registries that aren't using effective LGRs? Is this advice for the TMCH being sued because said malicious registrant can't actually use their SMD effectively (because registries prevent the label)? Is this a legal risk or a risk to infrastructure or DNS consumers? Are we going to address legal risks on this mailing list?
The SSAC document point out that the matching rules used in the TMCH are not the same as the combination of matching rules plus variant rules, specifically for non-ascii scripts. KF - Irrelevant. Homographic attacks require an actual registration. Either a registry's LGR's prevent it or they don't. for the TMCH it is more a failure of user expectations, which should not be conflated with an attack. It is important, but should be addressed separately. KF - What of the registries that should be EBERO'd? If true it is of serious concern, if not true we really need to tone down the hyperbole. Patrik
On 2014-02-21 07:55, Kal Feher wrote:
Comments in line.
KF - point taken, but vague assertions to dire consequences in any stakeholder forum are of little use to the community and should be discouraged.
Once again, if comments are taken out of context, they will be out of context. So that the assertions are vague I blame whoever did copy the subset of the discussion (that also was via voice, not only text).
KF - Frustration at a lack of progress should not automatically translate to advice not to adhere to your Registry Agreement. I think some perspective is required.
There have not been any such advice that I know of.
Please see the SSAC report.
KF - I reiterate that it is generic and lacking any actual detail, especially with regards to security or stability issues. There's a suggestion (recommendation 10) to clarify roles, which is certainly a good idea, but hardly catastrophic if not implemented and has little value in preventing homographic attacks.
A clarification of the roles now exists. The Registry Agreement (RPM Requirements) says that registries must check all names in a variant set during the TM Claims period. This is _not_ updated in the scorecard.
KF - I think the TMCH should certainly be improved, I have a list of gripes that would keep IBM busy for years, but we should be clear about risks and impact. I see plenty situations in which TMCH clients will not receive the result they expect. But there doesn't appear to be any security or stability risks that can be coherently described. Certainly none in the report.
SSAC has as a role do detect stability risks which include cases where the functionality of a system is not according to the claims. TMCH is well defined for the latin script, but not for non-latin scripts. Specifically when you have cases where different LGR is used for the same script in two different TLDs. Now, whether we will get different LGR for different TLDs is something only the integration panel can say anything about.
The SSAC document point out that the matching rules used in the TMCH are not the same as the combination of matching rules plus variant rules, specifically for non-ascii scripts.
KF - Irrelevant. Homographic attacks require an actual registration. Either a registry's LGR's prevent it or they don't. for the TMCH it is more a failure of user expectations, which should not be conflated with an attack. It is important, but should be addressed separately.
SSAC disagree with this conclusion of yours. But it is perfectly ok of course for you to draw the conclusion that you do not think the issues with IDN and variants in TMCH is a problem. That is your choice. SSAC do think it is a problem that the TMCH does not have any well defined rules for non-latin script. YMMV.
KF - What of the registries that should be EBERO'd? If true it is of serious concern, if not true we really need to tone down the hyperbole.
The EBERO is an issue separate from TMCH and the question was whether a zone that is not signed correctly is according to the EBERO specification "broken" in such a way that EBERO can be invoked. That question is not answered and not clear in the EBERO specification or elsewhere. It would be sad if it is the case it will only be resolved in court or arbitration when a real case is on the table. Patrik
hi all, as *I* am the one that chopped that snippet out of the chat transcript of the call, let me take the blame for launching a discussion that really had several completely different topics all in one. thanks to Kal and Patrik for putting up with that. 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. mikey On Feb 21, 2014, at 1:53 AM, Patrik Fältström <paf@frobbit.se> wrote:
On 2014-02-21 07:55, Kal Feher wrote:
Comments in line.
KF - point taken, but vague assertions to dire consequences in any stakeholder forum are of little use to the community and should be discouraged.
Once again, if comments are taken out of context, they will be out of context. So that the assertions are vague I blame whoever did copy the subset of the discussion (that also was via voice, not only text).
KF - Frustration at a lack of progress should not automatically translate to advice not to adhere to your Registry Agreement. I think some perspective is required.
There have not been any such advice that I know of.
Please see the SSAC report.
KF - I reiterate that it is generic and lacking any actual detail, especially with regards to security or stability issues. There's a suggestion (recommendation 10) to clarify roles, which is certainly a good idea, but hardly catastrophic if not implemented and has little value in preventing homographic attacks.
A clarification of the roles now exists.
The Registry Agreement (RPM Requirements) says that registries must check all names in a variant set during the TM Claims period.
This is _not_ updated in the scorecard.
KF - I think the TMCH should certainly be improved, I have a list of gripes that would keep IBM busy for years, but we should be clear about risks and impact. I see plenty situations in which TMCH clients will not receive the result they expect. But there doesn't appear to be any security or stability risks that can be coherently described. Certainly none in the report.
SSAC has as a role do detect stability risks which include cases where the functionality of a system is not according to the claims.
TMCH is well defined for the latin script, but not for non-latin scripts. Specifically when you have cases where different LGR is used for the same script in two different TLDs.
Now, whether we will get different LGR for different TLDs is something only the integration panel can say anything about.
The SSAC document point out that the matching rules used in the TMCH are not the same as the combination of matching rules plus variant rules, specifically for non-ascii scripts.
KF - Irrelevant. Homographic attacks require an actual registration. Either a registry's LGR's prevent it or they don't. for the TMCH it is more a failure of user expectations, which should not be conflated with an attack. It is important, but should be addressed separately.
SSAC disagree with this conclusion of yours. But it is perfectly ok of course for you to draw the conclusion that you do not think the issues with IDN and variants in TMCH is a problem. That is your choice.
SSAC do think it is a problem that the TMCH does not have any well defined rules for non-latin script. YMMV.
KF - What of the registries that should be EBERO'd? If true it is of serious concern, if not true we really need to tone down the hyperbole.
The EBERO is an issue separate from TMCH and the question was whether a zone that is not signed correctly is according to the EBERO specification "broken" in such a way that EBERO can be invoked.
That question is not answered and not clear in the EBERO specification or elsewhere. It would be sad if it is the case it will only be resolved in court or arbitration when a real case is on the table.
Patrik
PHONE: 651-647-6109, FAX: 866-280-2356, WEB: www.haven2.com, HANDLE: OConnorStP (ID for Twitter, Facebook, LinkedIn, etc.)
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. 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: KF - Recommendation 11 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. KF - Recommendation 12 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 On Feb 21, 2014, at 1:53 AM, Patrik Fältström <paf@frobbit.se> wrote:
On 2014-02-21 07:55, Kal Feher wrote:
Comments in line.
KF - point taken, but vague assertions to dire consequences in any stakeholder forum are of little use to the community and should be discouraged.
Once again, if comments are taken out of context, they will be out of context. So that the assertions are vague I blame whoever did copy the subset of the discussion (that also was via voice, not only text).
KF - Frustration at a lack of progress should not automatically translate to advice not to adhere to your Registry Agreement. I think some perspective is required.
There have not been any such advice that I know of.
Please see the SSAC report.
KF - I reiterate that it is generic and lacking any actual detail, especially with regards to security or stability issues. There's a suggestion (recommendation 10) to clarify roles, which is certainly a good idea, but hardly catastrophic if not implemented and has little value in preventing homographic attacks.
A clarification of the roles now exists.
The Registry Agreement (RPM Requirements) says that registries must check all names in a variant set during the TM Claims period.
This is _not_ updated in the scorecard.
KF - I think the TMCH should certainly be improved, I have a list of gripes that would keep IBM busy for years, but we should be clear about risks and impact. I see plenty situations in which TMCH clients will not receive the result they expect. But there doesn't appear to be any security or stability risks that can be coherently described. Certainly none in the report.
SSAC has as a role do detect stability risks which include cases where the functionality of a system is not according to the claims.
TMCH is well defined for the latin script, but not for non-latin scripts. Specifically when you have cases where different LGR is used for the same script in two different TLDs.
Now, whether we will get different LGR for different TLDs is something only the integration panel can say anything about.
The SSAC document point out that the matching rules used in the TMCH are not the same as the combination of matching rules plus variant rules, specifically for non-ascii scripts.
KF - Irrelevant. Homographic attacks require an actual registration. Either a registry's LGR's prevent it or they don't. for the TMCH it is more a failure of user expectations, which should not be conflated with an attack. It is important, but should be addressed separately.
SSAC disagree with this conclusion of yours. But it is perfectly ok of course for you to draw the conclusion that you do not think the issues with IDN and variants in TMCH is a problem. That is your choice.
SSAC do think it is a problem that the TMCH does not have any well defined rules for non-latin script. YMMV.
KF - What of the registries that should be EBERO'd? If true it is of serious concern, if not true we really need to tone down the hyperbole.
The EBERO is an issue separate from TMCH and the question was whether a zone that is not signed correctly is according to the EBERO specification "broken" in such a way that EBERO can be invoked.
That question is not answered and not clear in the EBERO specification or elsewhere. It would be sad if it is the case it will only be resolved in court or arbitration when a real case is on the table.
Patrik
PHONE: 651-647-6109, FAX: 866-280-2356, WEB: www.haven2.com, HANDLE: OConnorStP (ID for Twitter, Facebook, LinkedIn, etc.)
hi all, 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. some thread-starting questions: - what do the “ongoing” and “open” statuses in MyICANN imply? - 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? - only a couple of the entries on this page list an action-taken by the Board - is there a plan? - 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? - what’s the overall status of all this? good? bad? - 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? - 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? mikey here’s a link to the report https://www.icann.org/en/groups/ssac/documents/sac-060-en.pdf here’s a (sorry, gigantic) link that will take you to a listing of the recommendations and their current status on MyICANN https://www.myicann.org/board-advice#advice-to-board_f=sac060&advice-to-boar... and here’s the list of recommendations from the SAC060 Executive Summary (any typos are mine, i had to retype these) 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 ( 2LD s ) 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 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. 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 alloca ta ble 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 On Feb 24, 2014, at 1:15 AM, Kal Feher <Kal.Feher@ariservices.com> wrote:
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.
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:
KF - Recommendation 11 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.
KF - Recommendation 12 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
On Feb 21, 2014, at 1:53 AM, Patrik Fältström <paf@frobbit.se> wrote:
On 2014-02-21 07:55, Kal Feher wrote:
Comments in line.
KF - point taken, but vague assertions to dire consequences in any stakeholder forum are of little use to the community and should be discouraged.
Once again, if comments are taken out of context, they will be out of context. So that the assertions are vague I blame whoever did copy the subset of the discussion (that also was via voice, not only text).
KF - Frustration at a lack of progress should not automatically translate to advice not to adhere to your Registry Agreement. I think some perspective is required.
There have not been any such advice that I know of.
Please see the SSAC report.
KF - I reiterate that it is generic and lacking any actual detail, especially with regards to security or stability issues. There's a suggestion (recommendation 10) to clarify roles, which is certainly a good idea, but hardly catastrophic if not implemented and has little value in preventing homographic attacks.
A clarification of the roles now exists.
The Registry Agreement (RPM Requirements) says that registries must check all names in a variant set during the TM Claims period.
This is _not_ updated in the scorecard.
KF - I think the TMCH should certainly be improved, I have a list of gripes that would keep IBM busy for years, but we should be clear about risks and impact. I see plenty situations in which TMCH clients will not receive the result they expect. But there doesn't appear to be any security or stability risks that can be coherently described. Certainly none in the report.
SSAC has as a role do detect stability risks which include cases where the functionality of a system is not according to the claims.
TMCH is well defined for the latin script, but not for non-latin scripts. Specifically when you have cases where different LGR is used for the same script in two different TLDs.
Now, whether we will get different LGR for different TLDs is something only the integration panel can say anything about.
The SSAC document point out that the matching rules used in the TMCH are not the same as the combination of matching rules plus variant rules, specifically for non-ascii scripts.
KF - Irrelevant. Homographic attacks require an actual registration. Either a registry's LGR's prevent it or they don't. for the TMCH it is more a failure of user expectations, which should not be conflated with an attack. It is important, but should be addressed separately.
SSAC disagree with this conclusion of yours. But it is perfectly ok of course for you to draw the conclusion that you do not think the issues with IDN and variants in TMCH is a problem. That is your choice.
SSAC do think it is a problem that the TMCH does not have any well defined rules for non-latin script. YMMV.
KF - What of the registries that should be EBERO'd? If true it is of serious concern, if not true we really need to tone down the hyperbole.
The EBERO is an issue separate from TMCH and the question was whether a zone that is not signed correctly is according to the EBERO specification "broken" in such a way that EBERO can be invoked.
That question is not answered and not clear in the EBERO specification or elsewhere. It would be sad if it is the case it will only be resolved in court or arbitration when a real case is on the table.
Patrik
PHONE: 651-647-6109, FAX: 866-280-2356, WEB: www.haven2.com, HANDLE: OConnorStP (ID for Twitter, Facebook, LinkedIn, etc.)
PHONE: 651-647-6109, FAX: 866-280-2356, WEB: www.haven2.com, HANDLE: OConnorStP (ID for Twitter, Facebook, LinkedIn, etc.)
Mike, Fellow GNSO - SSR ers, I apologise in advance for the long reply, but you did ask a lot of questions, so it's not all my fault. I can't comment authoritatively on the open and ongoing statuses, since I am not aware of their original purpose. However they cover topics which may require long term policy or process development. So they may remain those statues for a very long time, which in my opinion robs them of their usefulness. It would also help if the actions were a little clearer and more direct. For example, the objection process comments (Recomm 2) suggest that in the process of developing an IDN LGR, public comments will suffice as a mechanism to manage disagreements regarding variants. However, there is no clarity how such comments should be assessed by each IDN LGR group. Should not requirements or an already developed assessment framework be inherited to their body of work? I'm particularly concerned that LGRs at the root are likely to be conservative (a later recommendation), yet these LGRs may well be used at the second and other levels. How then should comments be interpreted? Will the IDN LGR groups be able to accept comments and apply them only for second and lower levels? there is a contradiction here that will result in either LGRs for the root being inappropriately generous or LGRs at other levels (if they are in fact inherited) not generating the variants that users are used to today. I'd prefer a much more clear approach to passing requirements to working groups or third parties contracted to ICANN. I'd like a clear statement under each action like:"the working group/third party/whatever, will be required to document evidence that <insert requirement here> has been addressed in their final report" <- when the statement of work or working group guidelines are released, this section should be updated with a link to the matching requirement within that statement of work. We can all then trace advice, to requirement to eventually the action. The Recommendation 9 status is confusing. So perhaps we need to clarify exactly what this capability represents? does it represent the ability to host a second TLD zone file which mirrors the first? LGR capability is irrelevant in that case. does it represent the ability to take registrations or at least manage (update, including activation/deactivation of variants) IDNs in the TLD? <- that is a significantly more difficult capability to develop and assess. Perhaps conducting the PDT (recently updated) IDN test cases for all submitted languages and scripts might be a useful measure. Bearing in mind that the current LGRs TLD's use are likely to be very different to LGRs developed for the root (yet to be completed, if I'm not mistaken). I do note that Recommendation 4 is a little more realistic than the matching recommendation (recomm 6 I think) in the original report which required TLD operators to adopt LGRs developed for the root, at their lower levels or show cause why. We need to have a discussion on why the current situation, where TLDs can choose already adopted LGRs or choose not to (reasons undefined) is perceived, on the basis of a recommendation for regulation, to have failed. After all, many of the evaluated TLDs used for the original report were ccTLDs, so regulation is unlikely to influence them. If there are genuine failures of conformity (in implementing LGRs), as opposed to educated divergence, then some clear guidance will be needed in order to influence those TLDs to adopt this advice. If our understanding of the current status and intended actions improves, there may be some recommendations we could make. From: Mike O'Connor [mailto:mike@haven2.com] Sent: Tuesday, 25 February 2014 12:27 AM To: GNSO SSR List Cc: Patrik Fältström; Kal Feher Subject: discussion -- SAC060 -- User Experience Implications of Active Variant TLDs hi all, 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. some thread-starting questions: - what do the "ongoing" and "open" statuses in MyICANN imply? - 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? - only a couple of the entries on this page list an action-taken by the Board - is there a plan? - 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? - what's the overall status of all this? good? bad? - 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? - 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? mikey here's a link to the report https://www.icann.org/en/groups/ssac/documents/sac-060-en.pdf here's a (sorry, gigantic) link that will take you to a listing of the recommendations and their current status on MyICANN https://www.myicann.org/board-advice#advice-to-board_f=sac060&advice-to-boar... and here's the list of recommendations from the SAC060 Executive Summary (any typos are mine, i had to retype these) 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 ( 2LD s ) 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 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. 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 alloca ta ble 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 On Feb 24, 2014, at 1:15 AM, Kal Feher <Kal.Feher@ariservices.com<mailto:Kal.Feher@ariservices.com>> wrote: 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. 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: KF - Recommendation 11 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. KF - Recommendation 12 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 On Feb 21, 2014, at 1:53 AM, Patrik Fältström <paf@frobbit.se<mailto:paf@frobbit.se>> wrote: On 2014-02-21 07:55, Kal Feher wrote: Comments in line. KF - point taken, but vague assertions to dire consequences in any stakeholder forum are of little use to the community and should be discouraged. Once again, if comments are taken out of context, they will be out of context. So that the assertions are vague I blame whoever did copy the subset of the discussion (that also was via voice, not only text). KF - Frustration at a lack of progress should not automatically translate to advice not to adhere to your Registry Agreement. I think some perspective is required. There have not been any such advice that I know of. Please see the SSAC report. KF - I reiterate that it is generic and lacking any actual detail, especially with regards to security or stability issues. There's a suggestion (recommendation 10) to clarify roles, which is certainly a good idea, but hardly catastrophic if not implemented and has little value in preventing homographic attacks. A clarification of the roles now exists. The Registry Agreement (RPM Requirements) says that registries must check all names in a variant set during the TM Claims period. This is _not_ updated in the scorecard. KF - I think the TMCH should certainly be improved, I have a list of gripes that would keep IBM busy for years, but we should be clear about risks and impact. I see plenty situations in which TMCH clients will not receive the result they expect. But there doesn't appear to be any security or stability risks that can be coherently described. Certainly none in the report. SSAC has as a role do detect stability risks which include cases where the functionality of a system is not according to the claims. TMCH is well defined for the latin script, but not for non-latin scripts. Specifically when you have cases where different LGR is used for the same script in two different TLDs. Now, whether we will get different LGR for different TLDs is something only the integration panel can say anything about. The SSAC document point out that the matching rules used in the TMCH are not the same as the combination of matching rules plus variant rules, specifically for non-ascii scripts. KF - Irrelevant. Homographic attacks require an actual registration. Either a registry's LGR's prevent it or they don't. for the TMCH it is more a failure of user expectations, which should not be conflated with an attack. It is important, but should be addressed separately. SSAC disagree with this conclusion of yours. But it is perfectly ok of course for you to draw the conclusion that you do not think the issues with IDN and variants in TMCH is a problem. That is your choice. SSAC do think it is a problem that the TMCH does not have any well defined rules for non-latin script. YMMV. KF - What of the registries that should be EBERO'd? If true it is of serious concern, if not true we really need to tone down the hyperbole. The EBERO is an issue separate from TMCH and the question was whether a zone that is not signed correctly is according to the EBERO specification "broken" in such a way that EBERO can be invoked. That question is not answered and not clear in the EBERO specification or elsewhere. It would be sad if it is the case it will only be resolved in court or arbitration when a real case is on the table. Patrik PHONE: 651-647-6109, FAX: 866-280-2356, WEB: www.haven2.com<http://www.haven2.com>, HANDLE: OConnorStP (ID for Twitter, Facebook, LinkedIn, etc.) PHONE: 651-647-6109, FAX: 866-280-2356, WEB: www.haven2.com<http://www.haven2.com>, HANDLE: OConnorStP (ID for Twitter, Facebook, LinkedIn, etc.)
On 2014-03-04 03:55, Kal Feher wrote:
Mike, Fellow GNSO – SSR ers,
I apologise in advance for the long reply, but you did ask a lot of questions, so it’s not all my fault.
Maybe it is our, SSAC, fault :-)
It would also help if the actions were a little clearer and more direct. For example, the objection process comments (Recomm 2) suggest that in the process of developing an IDN LGR, public comments will suffice as a mechanism to manage disagreements regarding variants.
No, Recommendation 2 says that ICANN must have a known and predictable process for how to handle a disagreement. If that process is "no appeal or secondary review is possible" that might be the correct answer. The LGR process today does not say anything about what happens if someone do disagree with an LGR. Reason for the recommendation is that you can not allow an LGR to be started to be used, and then changed, without a very detailed review of potential backward compatibility implications of the change. You might add code points (not so problematic), remove code points (not fun if you have domain names using those code points) or decide two earlier distinct code points now are the same (definitely not fun if you have to earlier distinct domain names with different holders that now end up being treated equivalent).
The Recommendation 9 status is confusing. So perhaps we need to clarify exactly what this capability represents? does it represent the ability to host a second TLD zone file which mirrors the first? LGR capability is irrelevant in that case. does it represent the ability to take registrations or at least manage (update, including activation/deactivation of variants) IDNs in the TLD? <- that is a significantly more difficult capability to develop and assess. Perhaps conducting the PDT (recently updated) IDN test cases for all submitted languages and scripts might be a useful measure. Bearing in mind that the current LGRs TLD's use are likely to be very different to LGRs developed for the root (yet to be completed, if I'm not mistaken).
EBERO is to be able to do whatever changes needed to the zone, and because of that it is not "only" to host a zone file. And as later discovered (Recommendation 11) that each registry is to calculate variant sets of all LGRs used by any registry used for all scripts the registry uses (not only the LGRs the registry uses), the same must be true for anyone acting as EBERO.
I do note that Recommendation 4 is a little more realistic than the matching recommendation (recomm 6 I think) in the original report which required TLD operators to adopt LGRs developed for the root, at their lower levels or show cause why. We need to have a discussion on why the current situation, where TLDs can choose already adopted LGRs or choose not to (reasons undefined) is perceived, on the basis of a recommendation for regulation, to have failed. After all, many of the evaluated TLDs used for the original report were ccTLDs, so regulation is unlikely to influence them. If there are genuine failures of conformity (in implementing LGRs), as opposed to educated divergence, then some clear guidance will be needed in order to influence those TLDs to adopt this advice.
Different TLDs will have different LGRs for the same script. This is why SSAC say that _for_the_root_zone_ (which is the most important for ICANN), only one LGR can be used, and in reality that is the result of the integration panel working with whatever harmonization is needed. Patrik Fältström SSAC Chair
Some follow up questions in line. -----Original Message----- From: Patrik Fältström [mailto:paf@frobbit.se] Sent: Tuesday, 4 March 2014 5:42 PM To: Kal Feher; GNSO SSR List Subject: Re: [Gnso-ssr] discussion -- SAC060 -- User Experience Implications of Active Variant TLDs On 2014-03-04 03:55, Kal Feher wrote:
Mike, Fellow GNSO - SSR ers,
I apologise in advance for the long reply, but you did ask a lot of questions, so it's not all my fault.
Maybe it is our, SSAC, fault :-)
It would also help if the actions were a little clearer and more direct. For example, the objection process comments (Recomm 2) suggest that in the process of developing an IDN LGR, public comments will suffice as a mechanism to manage disagreements regarding variants.
No, Recommendation 2 says that ICANN must have a known and predictable process for how to handle a disagreement. If that process is "no appeal or secondary review is possible" that might be the correct answer. The LGR process today does not say anything about what happens if someone do disagree with an LGR. -KF in many regions there are committees and submission mechanisms, which is why language tables change over time. We don't want that process for the root though. Reason for the recommendation is that you can not allow an LGR to be started to be used, and then changed, without a very detailed review of potential backward compatibility implications of the change. You might add code points (not so problematic), remove code points (not fun if you have domain names using those code points) or decide two earlier distinct code points now are the same (definitely not fun if you have to earlier distinct domain names with different holders that now end up being treated equivalent). -KF I'm referring to the second sentence "However, each release of the integrated IDN LGR will be open to public comments prior to publication." What is each LGR group supposed to do with this advice? Are they supposed to document comments and categorise them? eg: relevant if applied to second level or lower, but not appropriate for root. I think actions from the board should be translatable to a specific action or criteria to each LGR working group.
The Recommendation 9 status is confusing. So perhaps we need to clarify exactly what this capability represents? does it represent the ability to host a second TLD zone file which mirrors the first? LGR capability is irrelevant in that case. does it represent the ability to take registrations or at least manage (update, including activation/deactivation of variants) IDNs in the TLD? <- that is a significantly more difficult capability to develop and assess. Perhaps conducting the PDT (recently updated) IDN test cases for all submitted languages and scripts might be a useful measure. Bearing in mind that the current LGRs TLD's use are likely to be very different to LGRs developed for the root (yet to be completed, if I'm not mistaken).
EBERO is to be able to do whatever changes needed to the zone, and because of that it is not "only" to host a zone file. And as later discovered (Recommendation 11) that each registry is to calculate variant sets of all LGRs used by any registry used for all scripts the registry uses (not only the LGRs the registry uses), the same must be true for anyone acting as EBERO. -KF But what does "Closed" mean for the current status? Do the EBERO providers have registries with all LGRs currently or soon to be in use? Or does "closed" mean "we have told EBEROs to do this"? Recommendation 11 will cause the grandfathering issue you were concerned about in the root in your earlier comment ..unless implemented straight away(less work but still too late). It ignores the reality that implemented LGRs are a choice by each TLD based on criteria important to them. If someone has made a decision to have a smaller set of variants than another TLD, they should be entitled to do so. The affect will be to homogenise IDNs with no capacity to allow for regional/dialect differences. A form of linguistic imperialism predicated on convenience? I'm wondering why strengthening regional committees for developing LGRs in cooperation was not suggested? It might allow for TLDs to consider the implications of divergent LGRs while still allowing them to represent the language as appropriate for their community. I note that the comment to Recommendation 11 suggests such efforts are not coming soon. The longer the wait, the worse the experience for everyone if this is ever actually implemented.
I do note that Recommendation 4 is a little more realistic than the matching recommendation (recomm 6 I think) in the original report which required TLD operators to adopt LGRs developed for the root, at their lower levels or show cause why. We need to have a discussion on why the current situation, where TLDs can choose already adopted LGRs or choose not to (reasons undefined) is perceived, on the basis of a recommendation for regulation, to have failed. After all, many of the evaluated TLDs used for the original report were ccTLDs, so regulation is unlikely to influence them. If there are genuine failures of conformity (in implementing LGRs), as opposed to educated divergence, then some clear guidance will be needed in order to influence those TLDs to adopt this advice.
Different TLDs will have different LGRs for the same script. This is why SSAC say that _for_the_root_zone_ (which is the most important for ICANN), only one LGR can be used, and in reality that is the result of the integration panel working with whatever harmonization is needed. -KF I think we are on the same page here. Patrik Fältström SSAC Chair
It is pretty hard to know what you did type without quoting... On 2014-03-04 08:40, Kal Feher wrote:
-KF in many regions there are committees and submission mechanisms, which is why language tables change over time. We don't want that process for the root though.
You do not want that in a TLD or any zone either. You only want backward compatible changes.
-KF I'm referring to the second sentence "However, each release of the integrated IDN LGR will be open to public comments prior to publication." What is each LGR group supposed to do with this advice? Are they supposed to document comments and categorise them? eg: relevant if applied to second level or lower, but not appropriate for root. I think actions from the board should be translatable to a specific action or criteria to each LGR working group.
What SSAC say is that the process must be made clear. That there is an ability to comment is part of the problem. SSAC do not propose a solution.
-KF But what does "Closed" mean for the current status? Do the EBERO providers have registries with all LGRs currently or soon to be in use? Or does "closed" mean "we have told EBEROs to do this"?
Unknown to SSAC. We have not asked for a clarification for the status "closed". To some degree I am nervous the "closed" status is the latter and that whoever did close the issue do not understand IDN and variants (and specifically changes between versions of LGRs). I hope I am wrong though and that the "closed" status is because the right thing has happened. Patrik Fältström
On 21 Feb 2014, at 7:43 am, Kal Feher <Kal.Feher@ariservices.com> wrote:
Are contracts a Security, Stability or Resiliency issue? (I realise this post was from another mailing list, where contracts may be of relevance)
They can be. Many of the compliance requirements are SSR related. For example, the contractual escrow requirements are a very important part of resiliency. Regards David
I should have specified *data* escrow. On 24 Feb 2014, at 4:41 pm, David Cake <dave@difference.com.au> wrote:
On 21 Feb 2014, at 7:43 am, Kal Feher <Kal.Feher@ariservices.com> wrote:
Are contracts a Security, Stability or Resiliency issue? (I realise this post was from another mailing list, where contracts may be of relevance)
They can be. Many of the compliance requirements are SSR related. For example, the contractual escrow requirements are a very important part of resiliency. Regards
David
I should have specified *data* escrow. On 24 Feb 2014, at 4:41 pm, David Cake <dave@difference.com.au<mailto:dave@difference.com.au>> wrote: On 21 Feb 2014, at 7:43 am, Kal Feher <Kal.Feher@ariservices.com<mailto:Kal.Feher@ariservices.com>> wrote: Are contracts a Security, Stability or Resiliency issue? (I realise this post was from another mailing list, where contracts may be of relevance) They can be. Many of the compliance requirements are SSR related. For example, the contractual escrow requirements are a very important part of resiliency. Regards KF - It was a long thread, so you may have missed it, but the contract question was of jurisdiction.
participants (4)
-
David Cake -
Kal Feher -
Mike O'Connor -
Patrik Fältström