[Gnso-ssr] Broken TMCH?

[Mike O'Connor]

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 at 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.)