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
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<http://www.avg.com/email-signature> Version: 2016.0.8013 / Virus Database: 4776/14514 - Release Date: 05/29/17
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> [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
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
I think all you need is a variable field in the claims notice that is filled in with standard language based on the trigger for the notice. On Wed, May 31, 2017 at 11:55 AM, Steve Levy <slevy@accentlawgroup.com> wrote:
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
Steven M. Levy, Esq.
*Accent Law Group, Inc.* 301 Fulton St. Philadelphia, Pennsylvania 19147
United States
Phone: +1-215-327-9094 <(215)%20327-9094> Email: slevy@AccentLawGroup.com <slevy@accentlawgroup.com>
Website: www.AccentLawGroup.com <http://www.accentlawgroup.com/>
<http://www.accentlawgroup.com/>LinkedIn: www.linkedin.com/in/ stevelevy43a/
From: <gnso-rpm-wg-bounces@icann.org> on behalf of Phil Corwin < psc@vlaw-dc.com> Date: Wednesday, May 31, 2017 at 9:11 AM To: Phil Corwin <psc@vlaw-dc.com>, Greg Shatan <gregshatanipc@gmail.com>, gnso-rpm-wg <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 <(202)%20559-8597>/Direct*
*202-559-8750 <(202)%20559-8750>/Fax*
*202-255-6172 <(202)%20255-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 <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 <(202)%20559-8597>/Direct*
*202-559-8750 <(202)%20559-8750>/Fax*
*202-255-6172 <(202)%20255-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 <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
I think the proposal addendum is very helpful. Some WIPO’s UDRP cases identify additional typical typo-squatting (See the new WIPO Overview 3.0<http://www.wipo.int/amc/en/domains/search/overview3.0/>) (items 1 and 2 below). Items 3-6 are cases I have come across. 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); 2. Digit/Letter substitution (for example, a zero for an “o”); 3. Added-dot typos (for example, www.dom.ain.com<http://www.dom.ain.com>); 4. For the non-Latin character substitution I would add that it should cover IDN’s homographs substitution (for example in Chinese replacing a full form sign for a simple form sign (it also exists in Hebrew, Greek and some other scripts); 5. Country codes – such as US, FR, and so forth (these seem to appear in many UDRP cases, and they are easy to identify automatically); and 6. Hyphen use – such as for example www.dom-ain.com<http://www.dom-ain.com>. I hope this helps. [cid:SANLogSmallNew_485a3de7-c8c5-4ec6-b34d-6de68607f295.png] Jonathan Agmon (胡韩森) Advocate, Director Attorney and Counsellor at Law (admitted in New York) jonathan.agmon@ip-law.legal<mailto:jonathan.agmon@ip-law.legal> www.ip-law.legal<http://www.ip-law.legal> T SG +65 6532 2577 T US +1 212 999 6180 T IL +972 9 950 7000 F IL +972 9 950 5500 Soroker Agmon Nordman Pte Ltd. 133 New Bridge Road, #13-02, 059413 SINGAPORE 8 Hahoshlim Street P.O. Box 12425 4672408 Herzliya, ISRAEL This message is confidential. It may also be privileged or otherwise protected by work product immunity or other legal rules. If you have received it by mistake, please let us know by e-mail reply and delete it from your system; you may not copy this message or disclose its contents to anyone. Please send us by fax any message containing deadlines as incoming e-mails are not screened for response deadlines. The integrity and security of this message cannot be guaranteed on the Internet. From: gnso-rpm-wg-bounces@icann.org [mailto:gnso-rpm-wg-bounces@icann.org] On Behalf Of Greg Shatan Sent: Tuesday, May 30, 2017 10:12 AM To: gnso-rpm-wg <gnso-rpm-wg@icann.org> 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 ************************************************************************************ This footnote confirms that this email message has been scanned by PineApp Mail-SeCure for the presence of malicious code, vandals & computer viruses. ************************************************************************************
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/
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
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
participants (7)
-
George Kirikos -
Greg Shatan -
Jonathan Agmon -
Mike Rodenbaugh -
Paul Keating -
Phil Corwin -
Steve Levy