Phil, are you suggesting that different claims notices should be sent depending on what element of the domain triggered the notice? I think this is a good idea if it’s technically feasible without undue expense. Depending on how (if) Greg’s proposal is implemented, perhaps we could keep things manageable by only creating one notice form for each of the categories specified in his proposal. This could then simply be coded, by the TMCH, to send the appropriate notice. Regards, Steve [cid:5464EBA5-C49A-411A-832D-838FBF68B10E] Steven M. Levy, Esq. Accent Law Group, Inc. 301 Fulton St. Philadelphia, Pennsylvania 19147 United States Phone: +1-215-327-9094 Email: slevy@AccentLawGroup.com<mailto:slevy@accentlawgroup.com> Website: www.AccentLawGroup.com<http://www.accentlawgroup.com/> <http://www.accentlawgroup.com/>LinkedIn: www.linkedin.com/in/stevelevy43a/<http://www.linkedin.com/in/stevelevy43a/> From: <gnso-rpm-wg-bounces@icann.org<mailto:gnso-rpm-wg-bounces@icann.org>> on behalf of Phil Corwin <psc@vlaw-dc.com<mailto:psc@vlaw-dc.com>> Date: Wednesday, May 31, 2017 at 9:11 AM To: Phil Corwin <psc@vlaw-dc.com<mailto:psc@vlaw-dc.com>>, Greg Shatan <gregshatanipc@gmail.com<mailto:gregshatanipc@gmail.com>>, gnso-rpm-wg <gnso-rpm-wg@icann.org<mailto:gnso-rpm-wg@icann.org>> Subject: Re: [gnso-rpm-wg] A Proposal for Smarter Non-Exact Matches PS—An additional question: While arguably in the realm of our upcoming Claims Notice review, how and to what extent would the language of the notice need to be altered and expanded to accurately inform the potential domain registrant of the reason that he/she received the Notice? Would there need to be additional language for each new category of non-exact matches, or would we be able to generate a customized claims notice based on the category that triggered it? This question stems from the consideration that when considering policy changes we should also consider implementation details and practicalities. Thanks Philip S. Corwin, Founding Principal Virtualaw LLC 1155 F Street, NW Suite 1050 Washington, DC 20004 202-559-8597/Direct 202-559-8750/Fax 202-255-6172/Cell Twitter: @VlawDC "Luck is the residue of design" -- Branch Rickey From: gnso-rpm-wg-bounces@icann.org<mailto:gnso-rpm-wg-bounces@icann.org> [mailto:gnso-rpm-wg-bounces@icann.org] On Behalf Of Phil Corwin Sent: Tuesday, May 30, 2017 10:46 PM To: Greg Shatan; gnso-rpm-wg Subject: Re: [gnso-rpm-wg] A Proposal for Smarter Non-Exact Matches Greg: Thank you for submitting this proposal. I think it will certainly help focus our ongoing discussion. Attached is a copy of the proposal annotated by initial comments and questions it has raised for me in my personal capacity. I hope you will be prepared to address them in your presentation or follow-up WG dialogue. See you on the call tomorrow. Best, Philip Philip S. Corwin, Founding Principal Virtualaw LLC 1155 F Street, NW Suite 1050 Washington, DC 20004 202-559-8597/Direct 202-559-8750/Fax 202-255-6172/Cell Twitter: @VlawDC "Luck is the residue of design" -- Branch Rickey From:gnso-rpm-wg-bounces@icann.org<mailto:gnso-rpm-wg-bounces@icann.org> [mailto:gnso-rpm-wg-bounces@icann.org] On Behalf Of Greg Shatan Sent: Monday, May 29, 2017 10:12 PM To: gnso-rpm-wg Subject: [gnso-rpm-wg] A Proposal for Smarter Non-Exact Matches All, As I've mentioned earlier, I think that a proposal to use non-exact matches other than "mark contained" matches ("dumb matches") makes sense to pursue. Various types of matches have been discussed; however, there has been no actual proposal for "smarter" matches that can be used by the group. The attached proposal seek to fill that gap. It is more in the nature of an addendum to the initial proposal on non-exact matches. However, it does provide a more formal proposal on the types of non-exact matches to be considered. The intent is to provide a sufficient framework to discuss these types of non-exact matches and to add these non-exact matches to the proposal. I hope that this helpful to the work of the group. Greg ________________________________ No virus found in this message. Checked by AVG - www.avg.com<http://www.avg.com/email-signature> Version: 2016.0.8013 / Virus Database: 4776/14514 - Release Date: 05/29/17 ________________________________ No virus found in this message. Checked by AVG - www.avg.com<http://www.avg.com/email-signature> Version: 2016.0.8013 / Virus Database: 4776/14514 - Release Date: 05/29/17

Going back to Greg's proposal, it would lead to an enormous number of expanded matches, and is in no way a "smarter non-exact matches" system. As an exercise, I challenge Greg to produce a list of ALL the "smarter non-exact matches" for just the top 10 TMCH terms as documented by The Analysis Group, to see how expansionary this so-called "smarter" set of non-exact matches. Remember, there are already tens of thousands of terms in the TMCH, and if Greg's proposal was adopted, it would attract even more entries into that database. Let's do a little bit of math: 1. missing-dot typos: triples the number of matches (by adding 2 more terms) 2. fat finger typos: there are between 3 and 8 possible "fat-finger" characters surrounding *each* letter of the standard QWERTY keyboard. Let's suppose the average is 5. That means 5 new matching terms for each LETTER in the mark. For a 10 letter mark, that means 5x10 = 50 additional matching terms! 3. Character duplication: this adds an additional number of matches equal to the length of the mark. For a 10 letter mark, that's another 10 matching terms. 4. Character swaps: this can add an additional number of matches *up to* the length of the mark ("up to", because in some cases the adjacent letters will be identical, e.g. 'Google' has the 'oo'). Conservatively, it'll be 60% x the length of the mark. So, for a 10 letter mark, that's at least 6 more matching terms. 5. Character removal: this can add an additional number of matches *up to* the length of the mark ("up to", because in some cases the adjacent letters will be identical, e.g. 'Google' has the 'oo') Conservatively, it'll be 60% x the length of the mark. So, for a 10 letter mark, that's at least 6 more matching terms. 6. Plurals: This is poorly defined in the proposal, since adding "s" doesn't always make sense as a plural. Sometimes it will be "es", sometimes "ies" (delivery -- deliveries), and then there are plurals in non-English languages where it might be something else: http://www.dummies.com/languages/french/how-to-make-french-nouns-plural/ Also, this assumes the term is a noun. What's the "plural" of a mark that is a verb or adjective? Anyhow, the "naive" rule of adding just the letter 's' will add 1 more term per mark. 7. Digit Addition: this is a puzzler. What's magical about the number '1'?? If it's as stated, it adds 1 more term per mark. Or, maybe 10 more terms per mark, if one doesn't discriminate between '1' and 2/3/4/5/6/7/8/9/0 8. CHEAP / BUY: 4 more matches per term. Unclear if Greg wants to also consider hyphens, which would match even more. 9. Non-Latin character substitutions: these are IDN matches which would result in a gigantic number of increased matches (e.g. multiple languages, plus variations for each letter, etc.) 10. Latin Character Substitutions: this is poorly defined. If it's only 'w' vs 'vv' then that's a small number of additional matches. But, as the "SWORD" algorithm debacle demonstrated, similarity is in the eye of the beholder. 11. Goods and Services and Industry Keywords: poorly defined, would add presumably at least 10 or more terms per mark, multiplied by even higher variations if hyphens are included or not. 12. Commonly abused terms: see #11. Greg hasn't discussed whether these also apply in *combination*, e.g. missing dot + character sway, or "cheap/buy + digit addition", etc. If so, that's a combinatorial explosion in the number of matches. The number of false positives would be enormous. Furthermore, there would be multiple mark matches per domain name (e.g. multiple marks generating a claim for a single domain name registration attempt), especially for short marks (5 characters or less), where the "density" or registrations of "nearby" coexisting and non-infringing strings is high. Sincerely, George Kirikos 416-588-0269 http://www.leap.com/ On Wed, May 31, 2017 at 9:11 AM, Phil Corwin <psc@vlaw-dc.com> wrote:

PS—An additional question: While arguably in the realm of our upcoming Claims Notice review, how and to what extent would the language of the notice need to be altered and expanded to accurately inform the potential domain registrant of the reason that he/she received the Notice? Would there need to be additional language for each new category of non-exact matches, or would we be able to generate a customized claims notice based on the category that triggered it?

This question stems from the consideration that when considering policy changes we should also consider implementation details and practicalities.

Thanks

Philip S. Corwin, Founding Principal

Virtualaw LLC

1155 F Street, NW

Suite 1050

Washington, DC 20004

202-559-8597/Direct

202-559-8750/Fax

202-255-6172/Cell

Twitter: @VlawDC

"Luck is the residue of design" -- Branch Rickey

From: gnso-rpm-wg-bounces@icann.org [mailto:gnso-rpm-wg-bounces@icann.org] On Behalf Of Phil Corwin Sent: Tuesday, May 30, 2017 10:46 PM To: Greg Shatan; gnso-rpm-wg Subject: Re: [gnso-rpm-wg] A Proposal for Smarter Non-Exact Matches

Greg:

Thank you for submitting this proposal. I think it will certainly help focus our ongoing discussion.

Attached is a copy of the proposal annotated by initial comments and questions it has raised for me in my personal capacity. I hope you will be prepared to address them in your presentation or follow-up WG dialogue.

See you on the call tomorrow.

Best, Philip

Philip S. Corwin, Founding Principal

Virtualaw LLC

1155 F Street, NW

Suite 1050

Washington, DC 20004

202-559-8597/Direct

202-559-8750/Fax

202-255-6172/Cell

Twitter: @VlawDC

"Luck is the residue of design" -- Branch Rickey

From: gnso-rpm-wg-bounces@icann.org [mailto:gnso-rpm-wg-bounces@icann.org] On Behalf Of Greg Shatan Sent: Monday, May 29, 2017 10:12 PM To: gnso-rpm-wg Subject: [gnso-rpm-wg] A Proposal for Smarter Non-Exact Matches

All,

As I've mentioned earlier, I think that a proposal to use non-exact matches other than "mark contained" matches ("dumb matches") makes sense to pursue. Various types of matches have been discussed; however, there has been no actual proposal for "smarter" matches that can be used by the group.

The attached proposal seek to fill that gap. It is more in the nature of an addendum to the initial proposal on non-exact matches. However, it does provide a more formal proposal on the types of non-exact matches to be considered. The intent is to provide a sufficient framework to discuss these types of non-exact matches and to add these non-exact matches to the proposal.

I hope that this helpful to the work of the group.

Greg

________________________________

No virus found in this message. Checked by AVG - www.avg.com Version: 2016.0.8013 / Virus Database: 4776/14514 - Release Date: 05/29/17

________________________________

No virus found in this message. Checked by AVG - www.avg.com Version: 2016.0.8013 / Virus Database: 4776/14514 - Release Date: 05/29/17

_______________________________________________ gnso-rpm-wg mailing list gnso-rpm-wg@icann.org https://mm.icann.org/mailman/listinfo/gnso-rpm-wg

Hello, On Tue, May 30, 2017 at 11:33 PM, Jonathan Agmon <jonathan.agmon@ip-law.legal> wrote:

I would therefore suggest that you consider adding a few additional rules to your addendum proposal:

1. Upper/Lower case substitution (to avoid abuse of the fact that the DNS is case sensitive);

Domain names are *not* case sensitive. The owner of Example.com doesn't need to worry about anyone cybersquatting on eXample.com, eXAMPle.com, EXAmple.com, eXaMpLe.CoM, etc. Sincerely, George Kirikos 416-588-0269 http://www.leap.com/

Not intending to cause heartache but .... Please keep in mind that the TMCH is a tool that is used for the following: 1. Exclusive registration of domain names during sunrise. 2. The claims notice process. These two serve vastly different purposes, provide vastly different forms of protection, and have drastically different consequences. I have less concern about #2 provided the notice is clear and simply understood. I have a big problem with any expansion as to #1 and actually want to see this dialed back so as to provide fewer rights to exclusivity. Let's not forget there remain the UDRP and litigation in the event of infringement. I am also very opposed to the use of UDRP and judicial decisions to bolster trademark rights for the above purposes. The UDRP is a streamlined process with under educated (sometimes uneducated) panelists - some of whom are not attorneys and at least one of which was a traffic court judge. There is little or no evidence and the panelists conduct little or no research. At least one ADR provider is known to unfairly favor certain panelists (statistically proven) and the others are completely opaque as to the manner of selection. The tests for trademark equivalence is extremely low and the entire element is considered a "standing" requirement that has been overly simplified. And, the result is often dependent upon the quality of the party representatives. Litigation is a private dispute among private parties. Any evidence or legal argument is dependent upon the quality of the litigant counsel and the jurisdiction. Neither is N acceptable standard to use in granting a global monopoly over domain. Name registration. The global nature mandates (IMHO) that we use the most severe of standards. Sincerely, Paul Keating, Esq.

On May 31, 2017, at 8:55 AM, Mike Rodenbaugh <mike@rodenbaugh.com> wrote:

Of course George is correct on this, wrt ASCII names. But we are seeing punycode (IDN) look-alike names a bit more often rear their ugly heads in the wild. I am unsure how or whether that could realistically be addressed through TMCH/sunrise/claims protection, but probably we all would agree we should protect against them if possible? Anyone have ideas whether it would be possible?

Thanks, Mike

Mike Rodenbaugh RODENBAUGH LAW tel/fax: +1.415.738.8087 http://rodenbaugh.com

...

On Tue, May 30, 2017 at 8:56 PM, George Kirikos <icann@leap.com> wrote: Hello,

On Tue, May 30, 2017 at 11:33 PM, Jonathan Agmon <jonathan.agmon@ip-law.legal> wrote:

...

I would therefore suggest that you consider adding a few additional rules to your addendum proposal:

1. Upper/Lower case substitution (to avoid abuse of the fact that the DNS is case sensitive);

Domain names are *not* case sensitive. The owner of Example.com doesn't need to worry about anyone cybersquatting on eXample.com, eXAMPle.com, EXAmple.com, eXaMpLe.CoM, etc.

Sincerely,

George Kirikos 416-588-0269 http://www.leap.com/ _______________________________________________ gnso-rpm-wg mailing list gnso-rpm-wg@icann.org https://mm.icann.org/mailman/listinfo/gnso-rpm-wg

_______________________________________________ gnso-rpm-wg mailing list gnso-rpm-wg@icann.org https://mm.icann.org/mailman/listinfo/gnso-rpm-wg