Singular/Plural in new gTLDs
On 24 June 2013 as requested by the GAC, the Board New gTLD Program Committee (NGPC) considered the issue of singular and plural stings being confusingly similar and decided to let the original process stand (subject to individual objections). The record of the decision can be found at http://www.icann.org/en/groups/board/documents/minutes-new-gtld-25jun13-en.h.... Of particular note is a statement issued by three Board members (George Sadowsky, Olga Madruga-Forti and Cherine Chalaby) who supported the decision but regretted that, based on the Applicant Guidebook wording, they did not believe that they had the leeway to vote against it. One Board member (Mike Silber) did oppose the decision. A central issue is that "confusingly similar" test relies purely on visual similarity and in the eyes of most (who were involved in the decision), adding an "S" makes it a recognizably different string. The salient part of the Applicant Guidebook (http://newgtlds.icann.org/en/applicants/agb/guidebook-full-04jun12-en.pdf) is section 2.2.1.1 of Module 2.
This review involves a preliminary comparison of each applied-for gTLD string against existing TLDs, Reserved Names (see subsection 2.2.1.2), and other applied-for strings. The objective of this review is to prevent user confusion and loss of confidence in the DNS resulting from delegation of many similar strings.
Note: In this Applicant Guidebook, "similar" means strings so similar that they create a probability of user confusion if more than one of the strings is delegated into the root zone.
The visual similarity check that occurs during Initial Evaluation is intended to augment the objection and dispute resolution process (see Module 3, Dispute Resolution Procedures) that addresses all types of similarity.
I believe that the NGPC decision was incorrect. The problem is the belief that "visual similarity" relies purely on what, in computer terminology, would be called "pattern matching". Pattern matching is certainly part of human perception, but it is not limited to that. At issue is whether two strings will be PERCEIVED as being equivalent, and perception is a far more complex (and less understood) issue. The real issue is that if you earlier found something at hilton.hotel, or had decided that the reviews at sheraton.hotel were something you trusted, will you later remember if it was really those sites or hilton.hotels or sheraton.hotels? At best, this could be considered a means of forcing anyone who registers a domain with .hotel or .hotels to register both, and map both of them to the same site. If that were to happen, the predictions of the Intellectual Property Constituency would be borne out, and all of those using these TLDs would have to make double the investment in domain names (presuming this is even possible with differing rules for each TLD). But the impact on users would be minimal. But since we cannot guarantee that both TLDs will remain forever in sync, we do have a user problem. Once cannot expect the typical Internet user to be able to differentiate between two such name spaces, and therefore I believe that we have a genuine case of "confusingly similar". And one that will arguably have as much or more impact on real Internet users, the ones that we are supposed to be here to defend, than any other case I can recall in my 7 year involvement with ICANN At-Large. If others on the ALAC agree, I would be happy to create a statement reflecting what I have said here, that we can, in our formal Advisory Committee role, forward as Advice to the Board. Alan
Dear Alan, Thank you for monitoring this space. I would suggest opening the discussions within the broader At Large to solicit views and feedback, preferably if the discussions could ensue on both the mailing list as well as the wiki before a statement is drafted. Kind Regards, Sala Sent from my iPad On Sep 4, 2013, at 2:02 PM, Alan Greenberg <alan.greenberg@mcgill.ca> wrote:
On 24 June 2013 as requested by the GAC, the Board New gTLD Program Committee (NGPC) considered the issue of singular and plural stings being confusingly similar and decided to let the original process stand (subject to individual objections). The record of the decision can be found at http://www.icann.org/en/groups/board/documents/minutes-new-gtld-25jun13-en.h.... Of particular note is a statement issued by three Board members (George Sadowsky, Olga Madruga-Forti and Cherine Chalaby) who supported the decision but regretted that, based on the Applicant Guidebook wording, they did not believe that they had the leeway to vote against it. One Board member (Mike Silber) did oppose the decision.
A central issue is that "confusingly similar" test relies purely on visual similarity and in the eyes of most (who were involved in the decision), adding an "S" makes it a recognizably different string.
The salient part of the Applicant Guidebook (http://newgtlds.icann.org/en/applicants/agb/guidebook-full-04jun12-en.pdf) is section 2.2.1.1 of Module 2.
This review involves a preliminary comparison of each applied-for gTLD string against existing TLDs, Reserved Names (see subsection 2.2.1.2), and other applied-for strings. The objective of this review is to prevent user confusion and loss of confidence in the DNS resulting from delegation of many similar strings.
Note: In this Applicant Guidebook, "similar" means strings so similar that they create a probability of user confusion if more than one of the strings is delegated into the root zone.
The visual similarity check that occurs during Initial Evaluation is intended to augment the objection and dispute resolution process (see Module 3, Dispute Resolution Procedures) that addresses all types of similarity.
I believe that the NGPC decision was incorrect. The problem is the belief that "visual similarity" relies purely on what, in computer terminology, would be called "pattern matching". Pattern matching is certainly part of human perception, but it is not limited to that. At issue is whether two strings will be PERCEIVED as being equivalent, and perception is a far more complex (and less understood) issue.
The real issue is that if you earlier found something at hilton.hotel, or had decided that the reviews at sheraton.hotel were something you trusted, will you later remember if it was really those sites or hilton.hotels or sheraton.hotels?
At best, this could be considered a means of forcing anyone who registers a domain with .hotel or .hotels to register both, and map both of them to the same site. If that were to happen, the predictions of the Intellectual Property Constituency would be borne out, and all of those using these TLDs would have to make double the investment in domain names (presuming this is even possible with differing rules for each TLD). But the impact on users would be minimal.
But since we cannot guarantee that both TLDs will remain forever in sync, we do have a user problem. Once cannot expect the typical Internet user to be able to differentiate between two such name spaces, and therefore I believe that we have a genuine case of "confusingly similar". And one that will arguably have as much or more impact on real Internet users, the ones that we are supposed to be here to defend, than any other case I can recall in my 7 year involvement with ICANN At-Large.
If others on the ALAC agree, I would be happy to create a statement reflecting what I have said here, that we can, in our formal Advisory Committee role, forward as Advice to the Board.
Alan
_______________________________________________ ALAC mailing list ALAC@atlarge-lists.icann.org https://atlarge-lists.icann.org/mailman/listinfo/alac
At-Large Online: http://www.atlarge.icann.org ALAC Working Wiki: https://community.icann.org/display/atlarge/At-Large+Advisory+Committee+(ALA...)
That could be done. But first I wanted to find out if there was any interest within the ALAC. If there is little interest, I will do something on my own, but with far less impact than if it is advice from the ALAC. Also note that this is an issue that is extremely time-sensitive, since if the issue is to be re-opened, it will have to be done very quickly. Alan At 03/09/2013 11:58 PM, Salanieta Tamanikaiwaimaro wrote:
Dear Alan,
Thank you for monitoring this space. I would suggest opening the discussions within the broader At Large to solicit views and feedback, preferably if the discussions could ensue on both the mailing list as well as the wiki before a statement is drafted.
Kind Regards, Sala
Sent from my iPad
On Sep 4, 2013, at 2:02 PM, Alan Greenberg <alan.greenberg@mcgill.ca> wrote:
On 24 June 2013 as requested by the GAC, the Board New gTLD Program Committee (NGPC) considered the issue of singular and plural stings being confusingly similar and decided to let the original process stand (subject to individual objections). The record of the decision can be found at http://www.icann.org/en/groups/board/documents/minutes-new-gtld-25jun13-en.h.... Of particular note is a statement issued by three Board members (George Sadowsky, Olga Madruga-Forti and Cherine Chalaby) who supported the decision but regretted that, based on the Applicant Guidebook wording, they did not believe that they had the leeway to vote against it. One Board member (Mike Silber) did oppose the decision.
A central issue is that "confusingly similar" test relies purely on visual similarity and in the eyes of most (who were involved in the decision), adding an "S" makes it a recognizably different string.
The salient part of the Applicant Guidebook (http://newgtlds.icann.org/en/applicants/agb/guidebook-full-04jun12-en.pdf) is section 2.2.1.1 of Module 2.
This review involves a preliminary comparison of each applied-for gTLD string against existing TLDs, Reserved Names (see subsection 2.2.1.2), and other applied-for strings. The objective of this review is to prevent user confusion and loss of confidence in the DNS resulting from delegation of many similar strings.
Note: In this Applicant Guidebook, "similar" means strings so similar that they create a probability of user confusion if more than one of the strings is delegated into the root zone.
The visual similarity check that occurs during Initial Evaluation is intended to augment the objection and dispute resolution process (see Module 3, Dispute Resolution Procedures) that addresses all types of similarity.
I believe that the NGPC decision was incorrect. The problem is the belief that "visual similarity" relies purely on what, in computer terminology, would be called "pattern matching". Pattern matching is certainly part of human perception, but it is not limited to that. At issue is whether two strings will be PERCEIVED as being equivalent, and perception is a far more complex (and less understood) issue.
The real issue is that if you earlier found something at hilton.hotel, or had decided that the reviews at sheraton.hotel were something you trusted, will you later remember if it was really those sites or hilton.hotels or sheraton.hotels?
At best, this could be considered a means of forcing anyone who registers a domain with .hotel or .hotels to register both, and map both of them to the same site. If that were to happen, the predictions of the Intellectual Property Constituency would be borne out, and all of those using these TLDs would have to make double the investment in domain names (presuming this is even possible with differing rules for each TLD). But the impact on users would be minimal.
But since we cannot guarantee that both TLDs will remain forever in sync, we do have a user problem. Once cannot expect the typical Internet user to be able to differentiate between two such name spaces, and therefore I believe that we have a genuine case of "confusingly similar". And one that will arguably have as much or more impact on real Internet users, the ones that we are supposed to be here to defend, than any other case I can recall in my 7 year involvement with ICANN At-Large.
If others on the ALAC agree, I would be happy to create a statement reflecting what I have said here, that we can, in our formal Advisory Committee role, forward as Advice to the Board.
Alan
_______________________________________________ ALAC mailing list ALAC@atlarge-lists.icann.org https://atlarge-lists.icann.org/mailman/listinfo/alac
At-Large Online: http://www.atlarge.icann.org ALAC Working Wiki: https://community.icann.org/display/atlarge/At-Large+Advisory+Committee+(ALA...)
Dear Alan, I support doing something about this. 2 thoughts: 1. A positive result of intervention on this matter where singular and plural strings are deemed similarly confusing (and thus not allowed) will result in the strings implicated to be in contention. This will no doubt heat up the string contention and objection resolution process. No valued judgment in this, just stating an observation of what to expect. 2. There is a practice in IDN variant management that can theoretically be applied to avoid applicants from having to "buy" two confusingly similar names (if the policy is not to allow singular and plural names). This is the practice/rule of allocating both names to an applicant and then blocking one of those names or allowing both names (perhaps for the price of one - need to check on whether they charge for the "variants" - I suspect not). And yes, the IP-interested folks might have something to say about it depending on whether they are in favor of over-protection or less. Best regards, Rinalia On Sep 4, 2013 12:29 PM, "Alan Greenberg" <alan.greenberg@mcgill.ca> wrote:
That could be done. But first I wanted to find out if there was any interest within the ALAC. If there is little interest, I will do something on my own, but with far less impact than if it is advice from the ALAC.
Also note that this is an issue that is extremely time-sensitive, since if the issue is to be re-opened, it will have to be done very quickly.
Alan
At 03/09/2013 11:58 PM, Salanieta Tamanikaiwaimaro wrote:
Dear Alan,
Thank you for monitoring this space. I would suggest opening the discussions within the broader At Large to solicit views and feedback, preferably if the discussions could ensue on both the mailing list as well as the wiki before a statement is drafted.
Kind Regards, Sala
Sent from my iPad
On Sep 4, 2013, at 2:02 PM, Alan Greenberg <alan.greenberg@mcgill.ca> wrote:
On 24 June 2013 as requested by the GAC, the Board New gTLD Program Committee (NGPC) considered the issue of singular and plural stings being confusingly similar and decided to let the original process stand (subject to individual objections). The record of the decision can be found at http://www.icann.org/en/**groups/board/documents/** minutes-new-gtld-25jun13-en.**htm#2.d<http://www.icann.org/en/groups/board/documents/minutes-new-gtld-25jun13-en.h...>. Of particular note is a statement issued by three Board members (George Sadowsky, Olga Madruga-Forti and Cherine Chalaby) who supported the decision but regretted that, based on the Applicant Guidebook wording, they did not believe that they had the leeway to vote against it. One Board member (Mike Silber) did oppose the decision.
A central issue is that "confusingly similar" test relies purely on visual similarity and in the eyes of most (who were involved in the decision), adding an "S" makes it a recognizably different string.
The salient part of the Applicant Guidebook ( http://newgtlds.icann.org/en/**applicants/agb/guidebook-full-** 04jun12-en.pdf<http://newgtlds.icann.org/en/applicants/agb/guidebook-full-04jun12-en.pdf>) is section 2.2.1.1 of Module 2.
This review involves a preliminary comparison of each applied-for gTLD string against existing TLDs, Reserved Names (see subsection 2.2.1.2), and other applied-for strings. The objective of this review is to prevent user confusion and loss of confidence in the DNS resulting from delegation of many similar strings.
Note: In this Applicant Guidebook, "similar" means strings so similar that they create a probability of user confusion if more than one of the strings is delegated into the root zone.
The visual similarity check that occurs during Initial Evaluation is intended to augment the objection and dispute resolution process (see Module 3, Dispute Resolution Procedures) that addresses all types of similarity.
I believe that the NGPC decision was incorrect. The problem is the belief that "visual similarity" relies purely on what, in computer terminology, would be called "pattern matching". Pattern matching is certainly part of human perception, but it is not limited to that. At issue is whether two strings will be PERCEIVED as being equivalent, and perception is a far more complex (and less understood) issue.
The real issue is that if you earlier found something at hilton.hotel, or had decided that the reviews at sheraton.hotel were something you trusted, will you later remember if it was really those sites or hilton.hotels or sheraton.hotels?
At best, this could be considered a means of forcing anyone who registers a domain with .hotel or .hotels to register both, and map both of them to the same site. If that were to happen, the predictions of the Intellectual Property Constituency would be borne out, and all of those using these TLDs would have to make double the investment in domain names (presuming this is even possible with differing rules for each TLD). But the impact on users would be minimal.
But since we cannot guarantee that both TLDs will remain forever in sync, we do have a user problem. Once cannot expect the typical Internet user to be able to differentiate between two such name spaces, and therefore I believe that we have a genuine case of "confusingly similar". And one that will arguably have as much or more impact on real Internet users, the ones that we are supposed to be here to defend, than any other case I can recall in my 7 year involvement with ICANN At-Large.
If others on the ALAC agree, I would be happy to create a statement reflecting what I have said here, that we can, in our formal Advisory Committee role, forward as Advice to the Board.
Alan
______________________________**_________________ ALAC mailing list ALAC@atlarge-lists.icann.org https://atlarge-lists.icann.**org/mailman/listinfo/alac<https://atlarge-lists.icann.org/mailman/listinfo/alac>
At-Large Online: http://www.atlarge.icann.org ALAC Working Wiki: https://community.icann.org/** display/atlarge/At-Large+**Advisory+Committee+(ALAC)<https://community.icann.org/display/atlarge/At-Large+Advisory+Committee+(ALA...>
______________________________**_________________ ALAC mailing list ALAC@atlarge-lists.icann.org https://atlarge-lists.icann.**org/mailman/listinfo/alac<https://atlarge-lists.icann.org/mailman/listinfo/alac>
At-Large Online: http://www.atlarge.icann.org ALAC Working Wiki: https://community.icann.org/**display/atlarge/At-Large+ **Advisory+Committee+(ALAC)<https://community.icann.org/display/atlarge/At-Large+Advisory+Committee+(ALA...>
Hi Alan. Thanks for posting the Board activity. My comments: - This is not an issue that has taken anyone by surprise. It seems that the Board's reluctance to overrule the existing AGB indicates a fear of legal action from applicants who made good-faith applications and will argue that they should be entitled to do as they please within existing limits. - The nature of the Board respond also indicates that this issue is way too late to properly debate now, and that any remedy now would be tacked-on as opposed to designed-in. - Like dotless domains, public interest clauses, closed generics and proper community evaluation, this is just one of dozens -- maybe hundreds -- of significant public-trust-related TLD matters that were either deliberately considered and bypassed/deferred, or ignored in the hope they would be forgotten. Certainly at least some of the many conspiracy theories in this regard are probably accurate. - The public is reluctantly getting used to such confusion anyway; witness the *deliberate* marketing of Columbia's .co ccTLD as a cheeky lookalike for dot-com. Now, you and I know that ICANN has no authority over this; but such subtlety is lost on the public. (ICANN's cowardice in not asserting standards for those ccTLDs acting as international generics has IMO already damaged public confidence in the DNS.) As a result, there will be no end-user outcry if ".hotel" exists alongside ".hotels", even though we know this to be confusing. Since expectations of ICANN's competence at DNS stewardship are already so low, more such incidents will be simply acknowledged, complained about and worked around, probably resulting in accelerated end-user reliance on search engines rather domain names(1). I agree that the acceptance of plurals, and the dependence of only computer matching to determine string similarity, is wrong. But I also believe that this discussion is many years too late, probably by design. If even sensible people on the Board believe their hands are tied by the current status of the AGB guidelines, our calling for change will accomplish very little except to make us feel like we at least tried. For that reason I would support such a statement but would not put much effort into it; a nice expression of principle that will be binned the moment it is published. At this point, IMO, were ALAC wish to be courageous and honest in its end-user advocacy role regarding the new gTLD expansion, it would call for an immediate freeze on all applications that are not IDNs or closed dot-brands, pending: 1. Evaluating the rollout of the IDNs and closed dot-brands, paying special attention on unintended consequences as well as the scalability of ICANN's compliance and other infrastructure components; 2. Sorting out the MANY identified loose ends in the AGB, with an explicit role in the resulting consensus for the GAC and ALAC Such advice would also probably be ignored, and would likely keep ICANN in court for a while should it be heeded. But IMO the alternative for ICANN in the medium term is either expropriation (at the hands of governments) or irrelevance (at the hands of end users), or both. - Evan (1) Indeed, now that the public is increasingly turning away from domain names, there is revived competition and innovation happening in search engines -- Bing, Baidu, and my current, privacy-friendly, search engine of choice <https://duckduckgo.com/>. On 4 September 2013 00:53, Rinalia Abdul Rahim <rinalia.abdulrahim@gmail.com
wrote:
Dear Alan,
I support doing something about this.
2 thoughts: 1. A positive result of intervention on this matter where singular and plural strings are deemed similarly confusing (and thus not allowed) will result in the strings implicated to be in contention. This will no doubt heat up the string contention and objection resolution process. No valued judgment in this, just stating an observation of what to expect.
2. There is a practice in IDN variant management that can theoretically be applied to avoid applicants from having to "buy" two confusingly similar names (if the policy is not to allow singular and plural names). This is the practice/rule of allocating both names to an applicant and then blocking one of those names or allowing both names (perhaps for the price of one - need to check on whether they charge for the "variants" - I suspect not). And yes, the IP-interested folks might have something to say about it depending on whether they are in favor of over-protection or less.
Best regards,
Rinalia On Sep 4, 2013 12:29 PM, "Alan Greenberg" <alan.greenberg@mcgill.ca> wrote:
That could be done. But first I wanted to find out if there was any interest within the ALAC. If there is little interest, I will do something on my own, but with far less impact than if it is advice from the ALAC.
Also note that this is an issue that is extremely time-sensitive, since if the issue is to be re-opened, it will have to be done very quickly.
Alan
At 03/09/2013 11:58 PM, Salanieta Tamanikaiwaimaro wrote:
Dear Alan,
Thank you for monitoring this space. I would suggest opening the discussions within the broader At Large to solicit views and feedback, preferably if the discussions could ensue on both the mailing list as well as the wiki before a statement is drafted.
Kind Regards, Sala
Sent from my iPad
On Sep 4, 2013, at 2:02 PM, Alan Greenberg <alan.greenberg@mcgill.ca> wrote:
On 24 June 2013 as requested by the GAC, the Board New gTLD Program Committee (NGPC) considered the issue of singular and plural stings being confusingly similar and decided to let the original process stand (subject to individual objections). The record of the decision can be found at http://www.icann.org/en/**groups/board/documents/** minutes-new-gtld-25jun13-en.**htm#2.d< http://www.icann.org/en/groups/board/documents/minutes-new-gtld-25jun13-en.h... . Of particular note is a statement issued by three Board members (George Sadowsky, Olga Madruga-Forti and Cherine Chalaby) who supported the decision but regretted that, based on the Applicant Guidebook wording, they did not believe that they had the leeway to vote against it. One Board member (Mike Silber) did oppose the decision.
A central issue is that "confusingly similar" test relies purely on visual similarity and in the eyes of most (who were involved in the decision), adding an "S" makes it a recognizably different string.
The salient part of the Applicant Guidebook ( http://newgtlds.icann.org/en/**applicants/agb/guidebook-full-** 04jun12-en.pdf< http://newgtlds.icann.org/en/applicants/agb/guidebook-full-04jun12-en.pdf ) is section 2.2.1.1 of Module 2.
This review involves a preliminary comparison of each applied-for gTLD string against existing TLDs, Reserved Names (see subsection 2.2.1.2), and other applied-for strings. The objective of this review is to prevent user confusion and loss of confidence in the DNS resulting from delegation of many similar strings.
Note: In this Applicant Guidebook, "similar" means strings so similar that they create a probability of user confusion if more than one of the strings is delegated into the root zone.
The visual similarity check that occurs during Initial Evaluation is intended to augment the objection and dispute resolution process (see Module 3, Dispute Resolution Procedures) that addresses all types of similarity.
I believe that the NGPC decision was incorrect. The problem is the belief that "visual similarity" relies purely on what, in computer terminology, would be called "pattern matching". Pattern matching is certainly part of human perception, but it is not limited to that. At issue is whether two strings will be PERCEIVED as being equivalent, and perception is a far more complex (and less understood) issue.
The real issue is that if you earlier found something at hilton.hotel, or had decided that the reviews at sheraton.hotel were something you trusted, will you later remember if it was really those sites or hilton.hotels or sheraton.hotels?
At best, this could be considered a means of forcing anyone who registers a domain with .hotel or .hotels to register both, and map both of them to the same site. If that were to happen, the predictions of the Intellectual Property Constituency would be borne out, and all of those using these TLDs would have to make double the investment in domain names (presuming this is even possible with differing rules for each TLD). But the impact on users would be minimal.
But since we cannot guarantee that both TLDs will remain forever in sync, we do have a user problem. Once cannot expect the typical Internet user to be able to differentiate between two such name spaces, and therefore I believe that we have a genuine case of "confusingly similar". And one that will arguably have as much or more impact on real Internet users, the ones that we are supposed to be here to defend, than any other case I can recall in my 7 year involvement with ICANN At-Large.
If others on the ALAC agree, I would be happy to create a statement reflecting what I have said here, that we can, in our formal Advisory Committee role, forward as Advice to the Board.
Alan
______________________________**_________________ ALAC mailing list ALAC@atlarge-lists.icann.org https://atlarge-lists.icann.**org/mailman/listinfo/alac<; https://atlarge-lists.icann.org/mailman/listinfo/alac>
At-Large Online: http://www.atlarge.icann.org ALAC Working Wiki: https://community.icann.org/** display/atlarge/At-Large+**Advisory+Committee+(ALAC)< https://community.icann.org/display/atlarge/At-Large+Advisory+Committee+(ALA...)
______________________________**_________________ ALAC mailing list ALAC@atlarge-lists.icann.org https://atlarge-lists.icann.**org/mailman/listinfo/alac<; https://atlarge-lists.icann.org/mailman/listinfo/alac>
At-Large Online: http://www.atlarge.icann.org ALAC Working Wiki: https://community.icann.org/**display/atlarge/At-Large+ **Advisory+Committee+(ALAC)< https://community.icann.org/display/atlarge/At-Large+Advisory+Committee+(ALA...)
_______________________________________________ ALAC mailing list ALAC@atlarge-lists.icann.org https://atlarge-lists.icann.org/mailman/listinfo/alac
At-Large Online: http://www.atlarge.icann.org ALAC Working Wiki: https://community.icann.org/display/atlarge/At-Large+Advisory+Committee+(ALA...)
-- Evan Leibovitch Toronto Canada Em: evan at telly dot org Sk: evanleibovitch Tw: el56
2. seems to be a dangerous discussion as it is framed... I understand that Rinalia, you are not confusing the two, but those who are not particularly fond of IDN Variants often use these discussions to confuse the matter. There has been discussions about the issue not just on plurals but also IDN versions of an English TLD. I think they are important discussions to be had, especially as we prepare for 2nd round of new gTLDs in the future. Nevertheless, it will need to be a rather separate discussion and must not be confused with the IDN Variant TLD issue. Edmon
-----Original Message----- From: alac-bounces@atlarge-lists.icann.org [mailto:alac-bounces@atlarge- lists.icann.org] On Behalf Of Rinalia Abdul Rahim Sent: Wednesday, September 4, 2013 12:53 PM To: Alan Greenberg Cc: ALAC Working List Subject: Re: [ALAC] Singular/Plural in new gTLDs
Dear Alan,
I support doing something about this.
2 thoughts: 1. A positive result of intervention on this matter where singular and plural strings are deemed similarly confusing (and thus not allowed) will result in the strings implicated to be in contention. This will no doubt heat up the string contention and objection resolution process. No valued judgment in this, just stating an observation of what to expect.
2. There is a practice in IDN variant management that can theoretically be applied to avoid applicants from having to "buy" two confusingly similar names (if the policy is not to allow singular and plural names). This is the practice/rule of allocating both names to an applicant and then blocking one of those names or allowing both names (perhaps for the price of one - need to check on whether they charge for the "variants" - I suspect not). And yes, the IP-interested folks might have something to say about it depending on whether they are in favor of over-protection or less.
Best regards,
Rinalia On Sep 4, 2013 12:29 PM, "Alan Greenberg" <alan.greenberg@mcgill.ca> wrote:
That could be done. But first I wanted to find out if there was any interest within the ALAC. If there is little interest, I will do something on my own, but with far less impact than if it is advice from the ALAC.
Also note that this is an issue that is extremely time-sensitive, since if the issue is to be re-opened, it will have to be done very quickly.
Alan
At 03/09/2013 11:58 PM, Salanieta Tamanikaiwaimaro wrote:
Dear Alan,
Thank you for monitoring this space. I would suggest opening the discussions within the broader At Large to solicit views and feedback, preferably if the discussions could ensue on both the mailing list as well as the wiki before a statement is drafted.
Kind Regards, Sala
Sent from my iPad
On Sep 4, 2013, at 2:02 PM, Alan Greenberg <alan.greenberg@mcgill.ca> wrote:
On 24 June 2013 as requested by the GAC, the Board New gTLD Program Committee (NGPC) considered the issue of singular and plural stings being confusingly similar and decided to let the original process stand (subject to individual objections). The record of the decision can be found at http://www.icann.org/en/**groups/board/documents/** minutes-new-gtld-25jun13-
en.**htm#2.d<http://www.icann.org/en/groups/board/documents/minutes-new-gtld -
25jun13-en.htm#2.d>.
Of particular note is a statement issued by three Board members (George Sadowsky, Olga Madruga-Forti and Cherine Chalaby) who supported the decision but regretted that, based on the Applicant Guidebook wording, they did not believe that they had the leeway to vote against it. One Board member (Mike Silber) did oppose the decision.
A central issue is that "confusingly similar" test relies purely on
visual similarity and in the eyes of most (who were involved in the decision), adding an "S" makes it a recognizably different string.
The salient part of the Applicant Guidebook (
http://newgtlds.icann.org/en/**applicants/agb/guidebook-full-**
04jun12-en.pdf<http://newgtlds.icann.org/en/applicants/agb/guidebook-full- 04jun12-en.pdf>)
is section 2.2.1.1 of Module 2.
This review involves a preliminary comparison of each applied-for
gTLD string against existing TLDs, Reserved Names (see subsection 2.2.1.2), and other applied-for strings. The objective of this review is to prevent user confusion and loss of confidence in the DNS resulting from delegation of many similar strings.
Note: In this Applicant Guidebook, "similar" means strings so
similar that they create a probability of user confusion if more than one of the strings is delegated into the root zone.
The visual similarity check that occurs during Initial Evaluation is
intended to augment the objection and dispute resolution process (see Module 3, Dispute Resolution Procedures) that addresses all types of similarity.
I believe that the NGPC decision was incorrect. The problem is the belief that "visual similarity" relies purely on what, in computer terminology, would be called "pattern matching". Pattern matching is certainly part of human perception, but it is not limited to that. At issue is whether two strings will be PERCEIVED as being equivalent, and perception is a far more complex (and less understood) issue.
The real issue is that if you earlier found something at hilton.hotel, or had decided that the reviews at sheraton.hotel were something you trusted, will you later remember if it was really those sites or hilton.hotels or sheraton.hotels?
At best, this could be considered a means of forcing anyone who registers a domain with .hotel or .hotels to register both, and map both of them to the same site. If that were to happen, the predictions of the Intellectual Property Constituency would be borne out, and all of those using these TLDs would have to make double the investment in domain names (presuming this is even possible with differing rules for each TLD). But the impact on users would be minimal.
But since we cannot guarantee that both TLDs will remain forever in sync, we do have a user problem. Once cannot expect the typical Internet user to be able to differentiate between two such name spaces, and therefore I believe that we have a genuine case of "confusingly similar". And one that will arguably have as much or more impact on real Internet users, the ones that we are supposed to be here to defend, than any other case I can recall in my 7 year involvement with ICANN At-Large.
If others on the ALAC agree, I would be happy to create a statement reflecting what I have said here, that we can, in our formal Advisory Committee role, forward as Advice to the Board.
Alan
______________________________**_________________ ALAC mailing list ALAC@atlarge-lists.icann.org
https://atlarge-lists.icann.**org/mailman/listinfo/alac<https://atlarge- lists.icann.org/mailman/listinfo/alac>
At-Large Online: http://www.atlarge.icann.org ALAC Working Wiki: https://community.icann.org/**
display/atlarge/At-
Large+**Advisory+Committee+(ALAC)<https://community.icann.org/display/atlarg e/
At-Large+Advisory+Committee+(ALAC)>
______________________________**_________________ ALAC mailing list ALAC@atlarge-lists.icann.org https://atlarge-lists.icann.**org/mailman/listinfo/alac<https://atlarge- lists.icann.org/mailman/listinfo/alac>
At-Large Online: http://www.atlarge.icann.org ALAC Working Wiki: https://community.icann.org/**display/atlarge/At-Large+
**Advisory+Committee+(ALAC)<https://community.icann.org/display/atlarge/At- Large+Advisory+Committee+(ALAC)>
_______________________________________________ ALAC mailing list ALAC@atlarge-lists.icann.org https://atlarge-lists.icann.org/mailman/listinfo/alac
At-Large Online: http://www.atlarge.icann.org ALAC Working Wiki: https://community.icann.org/display/atlarge/At- Large+Advisory+Committee+(ALAC) ----- No virus found in this message. Checked by AVG - www.avg.com Version: 2013.0.3392 / Virus Database: 3222/6632 - Release Date: 09/02/13
Hi Edmon. You are right. I am not confused. I looked at it in terms of theoretical applicability (I.e., if you have a similar problem between case A and case B, could the method of solving the problem of case A be applied to case B). One must let the imagination soar to explore all possibilities and then narrow it down when it comes down to brass tacks. Hmm. I am starting to sound like Carlton. Speaking in metaphors. Anyways, Alan: let's see a draft so that we can be more concrete and constructive. Rinalia On Sep 6, 2013 7:11 AM, "Edmon" <edmon@isoc.hk> wrote:
2. seems to be a dangerous discussion as it is framed... I understand that Rinalia, you are not confusing the two, but those who are not particularly fond of IDN Variants often use these discussions to confuse the matter.
There has been discussions about the issue not just on plurals but also IDN versions of an English TLD. I think they are important discussions to be had, especially as we prepare for 2nd round of new gTLDs in the future. Nevertheless, it will need to be a rather separate discussion and must not be confused with the IDN Variant TLD issue.
Edmon
-----Original Message----- From: alac-bounces@atlarge-lists.icann.org [mailto:alac-bounces@atlarge- lists.icann.org] On Behalf Of Rinalia Abdul Rahim Sent: Wednesday, September 4, 2013 12:53 PM To: Alan Greenberg Cc: ALAC Working List Subject: Re: [ALAC] Singular/Plural in new gTLDs
Dear Alan,
I support doing something about this.
2 thoughts: 1. A positive result of intervention on this matter where singular and plural strings are deemed similarly confusing (and thus not allowed) will result in the strings implicated to be in contention. This will no doubt heat up the string contention and objection resolution process. No valued judgment in this, just stating an observation of what to expect.
2. There is a practice in IDN variant management that can theoretically be applied to avoid applicants from having to "buy" two confusingly similar names (if the policy is not to allow singular and plural names). This is the practice/rule of allocating both names to an applicant and then blocking one of those names or allowing both names (perhaps for the price of one - need to check on whether they charge for the "variants" - I suspect not). And yes, the IP-interested folks might have something to say about it depending on whether they are in favor of over-protection or less.
Best regards,
Rinalia On Sep 4, 2013 12:29 PM, "Alan Greenberg" <alan.greenberg@mcgill.ca> wrote:
That could be done. But first I wanted to find out if there was any interest within the ALAC. If there is little interest, I will do something on my own, but with far less impact than if it is advice from the ALAC.
Also note that this is an issue that is extremely time-sensitive, since if the issue is to be re-opened, it will have to be done very quickly.
Alan
At 03/09/2013 11:58 PM, Salanieta Tamanikaiwaimaro wrote:
Dear Alan,
Thank you for monitoring this space. I would suggest opening the discussions within the broader At Large to solicit views and feedback, preferably if the discussions could ensue on both the mailing list as well as the wiki before a statement is drafted.
Kind Regards, Sala
Sent from my iPad
On Sep 4, 2013, at 2:02 PM, Alan Greenberg <alan.greenberg@mcgill.ca> wrote:
On 24 June 2013 as requested by the GAC, the Board New gTLD Program Committee (NGPC) considered the issue of singular and plural stings being confusingly similar and decided to let the original process stand (subject to individual objections). The record of the decision can be found at http://www.icann.org/en/**groups/board/documents/** minutes-new-gtld-25jun13-
en.**htm#2.d< http://www.icann.org/en/groups/board/documents/minutes-new-gtld -
25jun13-en.htm#2.d>.
Of particular note is a statement issued by three Board members (George Sadowsky, Olga Madruga-Forti and Cherine Chalaby) who supported the decision but regretted that, based on the Applicant Guidebook wording, they did not believe that they had the leeway to vote against it. One Board member (Mike Silber) did oppose the decision.
A central issue is that "confusingly similar" test relies purely on
visual similarity and in the eyes of most (who were involved in the decision), adding an "S" makes it a recognizably different string.
The salient part of the Applicant Guidebook (
http://newgtlds.icann.org/en/**applicants/agb/guidebook-full-**
04jun12-en.pdf<http://newgtlds.icann.org/en/applicants/agb/guidebook-full- 04jun12-en.pdf>)
is section 2.2.1.1 of Module 2.
This review involves a preliminary comparison of each applied-for
gTLD string against existing TLDs, Reserved Names (see subsection 2.2.1.2), and other applied-for strings. The objective of this review is to prevent user confusion and loss of confidence in the DNS resulting from delegation of many similar strings.
Note: In this Applicant Guidebook, "similar" means strings so
similar that they create a probability of user confusion if more than one of the strings is delegated into the root zone.
The visual similarity check that occurs during Initial Evaluation
is intended to augment the objection and dispute resolution process (see Module 3, Dispute Resolution Procedures) that addresses all types of similarity.
I believe that the NGPC decision was incorrect. The problem is the belief that "visual similarity" relies purely on what, in computer terminology, would be called "pattern matching". Pattern matching is certainly part of human perception, but it is not limited to that. At issue is whether two strings will be PERCEIVED as being equivalent, and perception is a far more complex (and less understood) issue.
The real issue is that if you earlier found something at hilton.hotel, or had decided that the reviews at sheraton.hotel were something you trusted, will you later remember if it was really those sites or hilton.hotels or sheraton.hotels?
At best, this could be considered a means of forcing anyone who registers a domain with .hotel or .hotels to register both, and map both of them to the same site. If that were to happen, the predictions of the Intellectual Property Constituency would be borne out, and all of those using these TLDs would have to make double the investment in domain names (presuming this is even possible with differing rules for each TLD). But the impact on users would be minimal.
But since we cannot guarantee that both TLDs will remain forever in sync, we do have a user problem. Once cannot expect the typical Internet user to be able to differentiate between two such name spaces, and therefore I believe that we have a genuine case of "confusingly similar". And one that will arguably have as much or more impact on real Internet users, the ones that we are supposed to be here to defend, than any other case I can recall in my 7 year involvement with ICANN At-Large.
If others on the ALAC agree, I would be happy to create a statement reflecting what I have said here, that we can, in our formal Advisory Committee role, forward as Advice to the Board.
Alan
______________________________**_________________ ALAC mailing list ALAC@atlarge-lists.icann.org
https://atlarge-lists.icann.**org/mailman/listinfo/alac<https://atlarge- lists.icann.org/mailman/listinfo/alac>
At-Large Online: http://www.atlarge.icann.org ALAC Working Wiki: https://community.icann.org/**
display/atlarge/At-
Large+**Advisory+Committee+(ALAC)< https://community.icann.org/display/atlarg e/
At-Large+Advisory+Committee+(ALAC)>
______________________________**_________________ ALAC mailing list ALAC@atlarge-lists.icann.org https://atlarge-lists.icann.**org/mailman/listinfo/alac<; https://atlarge- lists.icann.org/mailman/listinfo/alac>
At-Large Online: http://www.atlarge.icann.org ALAC Working Wiki: https://community.icann.org/**display/atlarge/At-Large+
**Advisory+Committee+(ALAC)< https://community.icann.org/display/atlarge/At- Large+Advisory+Committee+(ALAC)>
_______________________________________________ ALAC mailing list ALAC@atlarge-lists.icann.org https://atlarge-lists.icann.org/mailman/listinfo/alac
At-Large Online: http://www.atlarge.icann.org ALAC Working Wiki: https://community.icann.org/display/atlarge/At- Large+Advisory+Committee+(ALAC) ----- No virus found in this message. Checked by AVG - www.avg.com Version: 2013.0.3392 / Virus Database: 3222/6632 - Release Date: 09/02/13
........ see, in some quarters an IDN variant is the very definition of an " *organic claim to 'similarity'*". I believe there was a conscious decision to contain, if not frustrate, that view; I used the term 'ring fence' as shorthand for that objective. Contortions that make their way into the consciousness via use of language, especially for folks that don't belong to the mouth breathing set, is always purposeful. Give the man a prize. -Carlton ============================== Carlton A Samuels Mobile: 876-818-1799 *Strategy, Planning, Governance, Assessment & Turnaround* ============================= On Thu, Sep 5, 2013 at 6:11 PM, Edmon <edmon@isoc.hk> wrote:
2. seems to be a dangerous discussion as it is framed... I understand that Rinalia, you are not confusing the two, but those who are not particularly fond of IDN Variants often use these discussions to confuse the matter.
There has been discussions about the issue not just on plurals but also IDN versions of an English TLD. I think they are important discussions to be had, especially as we prepare for 2nd round of new gTLDs in the future. Nevertheless, it will need to be a rather separate discussion and must not be confused with the IDN Variant TLD issue.
Edmon
-----Original Message----- From: alac-bounces@atlarge-lists.icann.org [mailto:alac-bounces@atlarge- lists.icann.org] On Behalf Of Rinalia Abdul Rahim Sent: Wednesday, September 4, 2013 12:53 PM To: Alan Greenberg Cc: ALAC Working List Subject: Re: [ALAC] Singular/Plural in new gTLDs
Dear Alan,
I support doing something about this.
2 thoughts: 1. A positive result of intervention on this matter where singular and plural strings are deemed similarly confusing (and thus not allowed) will result in the strings implicated to be in contention. This will no doubt heat up the string contention and objection resolution process. No valued judgment in this, just stating an observation of what to expect.
2. There is a practice in IDN variant management that can theoretically be applied to avoid applicants from having to "buy" two confusingly similar names (if the policy is not to allow singular and plural names). This is the practice/rule of allocating both names to an applicant and then blocking one of those names or allowing both names (perhaps for the price of one - need to check on whether they charge for the "variants" - I suspect not). And yes, the IP-interested folks might have something to say about it depending on whether they are in favor of over-protection or less.
Best regards,
Rinalia On Sep 4, 2013 12:29 PM, "Alan Greenberg" <alan.greenberg@mcgill.ca> wrote:
That could be done. But first I wanted to find out if there was any interest within the ALAC. If there is little interest, I will do something on my own, but with far less impact than if it is advice from the ALAC.
Also note that this is an issue that is extremely time-sensitive, since if the issue is to be re-opened, it will have to be done very quickly.
Alan
At 03/09/2013 11:58 PM, Salanieta Tamanikaiwaimaro wrote:
Dear Alan,
Thank you for monitoring this space. I would suggest opening the discussions within the broader At Large to solicit views and feedback, preferably if the discussions could ensue on both the mailing list as well as the wiki before a statement is drafted.
Kind Regards, Sala
Sent from my iPad
On Sep 4, 2013, at 2:02 PM, Alan Greenberg <alan.greenberg@mcgill.ca> wrote:
On 24 June 2013 as requested by the GAC, the Board New gTLD Program Committee (NGPC) considered the issue of singular and plural stings being confusingly similar and decided to let the original process stand (subject to individual objections). The record of the decision can be found at http://www.icann.org/en/**groups/board/documents/** minutes-new-gtld-25jun13-
en.**htm#2.d< http://www.icann.org/en/groups/board/documents/minutes-new-gtld -
25jun13-en.htm#2.d>.
Of particular note is a statement issued by three Board members (George Sadowsky, Olga Madruga-Forti and Cherine Chalaby) who supported the decision but regretted that, based on the Applicant Guidebook wording, they did not believe that they had the leeway to vote against it. One Board member (Mike Silber) did oppose the decision.
A central issue is that "confusingly similar" test relies purely on
visual similarity and in the eyes of most (who were involved in the decision), adding an "S" makes it a recognizably different string.
The salient part of the Applicant Guidebook (
http://newgtlds.icann.org/en/**applicants/agb/guidebook-full-**
04jun12-en.pdf<http://newgtlds.icann.org/en/applicants/agb/guidebook-full- 04jun12-en.pdf>)
is section 2.2.1.1 of Module 2.
This review involves a preliminary comparison of each applied-for
gTLD string against existing TLDs, Reserved Names (see subsection 2.2.1.2), and other applied-for strings. The objective of this review is to prevent user confusion and loss of confidence in the DNS resulting from delegation of many similar strings.
Note: In this Applicant Guidebook, "similar" means strings so
similar that they create a probability of user confusion if more than one of the strings is delegated into the root zone.
The visual similarity check that occurs during Initial Evaluation
is intended to augment the objection and dispute resolution process (see Module 3, Dispute Resolution Procedures) that addresses all types of similarity.
I believe that the NGPC decision was incorrect. The problem is the belief that "visual similarity" relies purely on what, in computer terminology, would be called "pattern matching". Pattern matching is certainly part of human perception, but it is not limited to that. At issue is whether two strings will be PERCEIVED as being equivalent, and perception is a far more complex (and less understood) issue.
The real issue is that if you earlier found something at hilton.hotel, or had decided that the reviews at sheraton.hotel were something you trusted, will you later remember if it was really those sites or hilton.hotels or sheraton.hotels?
At best, this could be considered a means of forcing anyone who registers a domain with .hotel or .hotels to register both, and map both of them to the same site. If that were to happen, the predictions of the Intellectual Property Constituency would be borne out, and all of those using these TLDs would have to make double the investment in domain names (presuming this is even possible with differing rules for each TLD). But the impact on users would be minimal.
But since we cannot guarantee that both TLDs will remain forever in sync, we do have a user problem. Once cannot expect the typical Internet user to be able to differentiate between two such name spaces, and therefore I believe that we have a genuine case of "confusingly similar". And one that will arguably have as much or more impact on real Internet users, the ones that we are supposed to be here to defend, than any other case I can recall in my 7 year involvement with ICANN At-Large.
If others on the ALAC agree, I would be happy to create a statement reflecting what I have said here, that we can, in our formal Advisory Committee role, forward as Advice to the Board.
Alan
______________________________**_________________ ALAC mailing list ALAC@atlarge-lists.icann.org
https://atlarge-lists.icann.**org/mailman/listinfo/alac<https://atlarge- lists.icann.org/mailman/listinfo/alac>
At-Large Online: http://www.atlarge.icann.org ALAC Working Wiki: https://community.icann.org/**
display/atlarge/At-
Large+**Advisory+Committee+(ALAC)< https://community.icann.org/display/atlarg e/
At-Large+Advisory+Committee+(ALAC)>
______________________________**_________________ ALAC mailing list ALAC@atlarge-lists.icann.org https://atlarge-lists.icann.**org/mailman/listinfo/alac<; https://atlarge- lists.icann.org/mailman/listinfo/alac>
At-Large Online: http://www.atlarge.icann.org ALAC Working Wiki: https://community.icann.org/**display/atlarge/At-Large+
**Advisory+Committee+(ALAC)< https://community.icann.org/display/atlarge/At- Large+Advisory+Committee+(ALAC)>
_______________________________________________ ALAC mailing list ALAC@atlarge-lists.icann.org https://atlarge-lists.icann.org/mailman/listinfo/alac
At-Large Online: http://www.atlarge.icann.org ALAC Working Wiki: https://community.icann.org/display/atlarge/At- Large+Advisory+Committee+(ALAC) ----- No virus found in this message. Checked by AVG - www.avg.com Version: 2013.0.3392 / Virus Database: 3222/6632 - Release Date: 09/02/13
_______________________________________________ ALAC mailing list ALAC@atlarge-lists.icann.org https://atlarge-lists.icann.org/mailman/listinfo/alac
At-Large Online: http://www.atlarge.icann.org ALAC Working Wiki: https://community.icann.org/display/atlarge/At-Large+Advisory+Committee+(ALA...)
Thanks for bringing this forth, Alan. Yes to instigating the discussion in the community, ALAC included, as well; we can always just forward Alan's note to the regional lists. I can agree that the accepted definition of 'confusingly similar' narrows the understanding of how perception works. But all handwringing aside, the end result is likely negative impact on the end user. So, what do we do? I read Evan's intervention closely and quite frankly, cannot find fault with his analysis, including his take on the likely result of any ALAC statement. The good thing is as Evan says; users will find alternatives to mitigate the slight. So I will not bounce the rubble. But I would support a statement in abundant surety it is for 'political correctness' rather than any expectation of meaningful change of course. -Carlton ============================== Carlton A Samuels Mobile: 876-818-1799 *Strategy, Planning, Governance, Assessment & Turnaround* ============================= On Tue, Sep 3, 2013 at 9:02 PM, Alan Greenberg <alan.greenberg@mcgill.ca>wrote:
On 24 June 2013 as requested by the GAC, the Board New gTLD Program Committee (NGPC) considered the issue of singular and plural stings being confusingly similar and decided to let the original process stand (subject to individual objections). The record of the decision can be found at http://www.icann.org/en/**groups/board/documents/** minutes-new-gtld-25jun13-en.**htm#2.d<http://www.icann.org/en/groups/board/documents/minutes-new-gtld-25jun13-en.h...>. Of particular note is a statement issued by three Board members (George Sadowsky, Olga Madruga-Forti and Cherine Chalaby) who supported the decision but regretted that, based on the Applicant Guidebook wording, they did not believe that they had the leeway to vote against it. One Board member (Mike Silber) did oppose the decision.
A central issue is that "confusingly similar" test relies purely on visual similarity and in the eyes of most (who were involved in the decision), adding an "S" makes it a recognizably different string.
The salient part of the Applicant Guidebook (http://newgtlds.icann.org/en/ **applicants/agb/guidebook-full-**04jun12-en.pdf<http://newgtlds.icann.org/en/applicants/agb/guidebook-full-04jun12-en.pdf>) is section 2.2.1.1 of Module 2.
This review involves a preliminary comparison of each applied-for gTLD
string against existing TLDs, Reserved Names (see subsection 2.2.1.2), and other applied-for strings. The objective of this review is to prevent user confusion and loss of confidence in the DNS resulting from delegation of many similar strings.
Note: In this Applicant Guidebook, "similar" means strings so similar that they create a probability of user confusion if more than one of the strings is delegated into the root zone.
The visual similarity check that occurs during Initial Evaluation is intended to augment the objection and dispute resolution process (see Module 3, Dispute Resolution Procedures) that addresses all types of similarity.
I believe that the NGPC decision was incorrect. The problem is the belief that "visual similarity" relies purely on what, in computer terminology, would be called "pattern matching". Pattern matching is certainly part of human perception, but it is not limited to that. At issue is whether two strings will be PERCEIVED as being equivalent, and perception is a far more complex (and less understood) issue.
The real issue is that if you earlier found something at hilton.hotel, or had decided that the reviews at sheraton.hotel were something you trusted, will you later remember if it was really those sites or hilton.hotels or sheraton.hotels?
At best, this could be considered a means of forcing anyone who registers a domain with .hotel or .hotels to register both, and map both of them to the same site. If that were to happen, the predictions of the Intellectual Property Constituency would be borne out, and all of those using these TLDs would have to make double the investment in domain names (presuming this is even possible with differing rules for each TLD). But the impact on users would be minimal.
But since we cannot guarantee that both TLDs will remain forever in sync, we do have a user problem. Once cannot expect the typical Internet user to be able to differentiate between two such name spaces, and therefore I believe that we have a genuine case of "confusingly similar". And one that will arguably have as much or more impact on real Internet users, the ones that we are supposed to be here to defend, than any other case I can recall in my 7 year involvement with ICANN At-Large.
If others on the ALAC agree, I would be happy to create a statement reflecting what I have said here, that we can, in our formal Advisory Committee role, forward as Advice to the Board.
Alan
______________________________**_________________ ALAC mailing list ALAC@atlarge-lists.icann.org https://atlarge-lists.icann.**org/mailman/listinfo/alac<https://atlarge-lists.icann.org/mailman/listinfo/alac>
At-Large Online: http://www.atlarge.icann.org ALAC Working Wiki: https://community.icann.org/**display/atlarge/At-Large+ **Advisory+Committee+(ALAC)<https://community.icann.org/display/atlarge/At-Large+Advisory+Committee+(ALA...>
I would note, again, that consumers are already used to endless near-collisions in DNS namespace, based on experience at the second level. As one of many examples. "car.com" and "cars.com" point to directly-competing entities both marketing primarily on their domain names. It's one thing when a typo gets you to a squatter's park page, quite another when it goes to a completely different website offering the *exact same thing* as you were looking for, and there's no attempt to mislead. Consumers are used to that. By now, I'm fairly certain that end-users would NOT trust "genericword.com" to be a definitive source of information -- let alone sales -- regarding that word. (Of course, having research regarding such trust levels would be EXTREMELY useful in guiding future outcomes, yet ICANN refuses to do such research. I suspect it is terrified of the likely results) - Evan On 4 September 2013 12:53, Carlton Samuels <carlton.samuels@gmail.com>wrote:
Thanks for bringing this forth, Alan. Yes to instigating the discussion in the community, ALAC included, as well; we can always just forward Alan's note to the regional lists.
I can agree that the accepted definition of 'confusingly similar' narrows the understanding of how perception works. But all handwringing aside, the end result is likely negative impact on the end user. So, what do we do?
I read Evan's intervention closely and quite frankly, cannot find fault with his analysis, including his take on the likely result of any ALAC statement. The good thing is as Evan says; users will find alternatives to mitigate the slight. So I will not bounce the rubble. But I would support a statement in abundant surety it is for 'political correctness' rather than any expectation of meaningful change of course.
-Carlton
============================== Carlton A Samuels Mobile: 876-818-1799 *Strategy, Planning, Governance, Assessment & Turnaround* =============================
On Tue, Sep 3, 2013 at 9:02 PM, Alan Greenberg <alan.greenberg@mcgill.ca
wrote:
On 24 June 2013 as requested by the GAC, the Board New gTLD Program Committee (NGPC) considered the issue of singular and plural stings being confusingly similar and decided to let the original process stand (subject to individual objections). The record of the decision can be found at http://www.icann.org/en/**groups/board/documents/** minutes-new-gtld-25jun13-en.**htm#2.d< http://www.icann.org/en/groups/board/documents/minutes-new-gtld-25jun13-en.h... . Of particular note is a statement issued by three Board members (George Sadowsky, Olga Madruga-Forti and Cherine Chalaby) who supported the decision but regretted that, based on the Applicant Guidebook wording, they did not believe that they had the leeway to vote against it. One Board member (Mike Silber) did oppose the decision.
A central issue is that "confusingly similar" test relies purely on visual similarity and in the eyes of most (who were involved in the decision), adding an "S" makes it a recognizably different string.
The salient part of the Applicant Guidebook ( http://newgtlds.icann.org/en/ **applicants/agb/guidebook-full-**04jun12-en.pdf< http://newgtlds.icann.org/en/applicants/agb/guidebook-full-04jun12-en.pdf ) is section 2.2.1.1 of Module 2.
This review involves a preliminary comparison of each applied-for gTLD
string against existing TLDs, Reserved Names (see subsection 2.2.1.2), and other applied-for strings. The objective of this review is to prevent user confusion and loss of confidence in the DNS resulting from delegation of many similar strings.
Note: In this Applicant Guidebook, "similar" means strings so similar that they create a probability of user confusion if more than one of the strings is delegated into the root zone.
The visual similarity check that occurs during Initial Evaluation is intended to augment the objection and dispute resolution process (see Module 3, Dispute Resolution Procedures) that addresses all types of similarity.
I believe that the NGPC decision was incorrect. The problem is the belief that "visual similarity" relies purely on what, in computer terminology, would be called "pattern matching". Pattern matching is certainly part of human perception, but it is not limited to that. At issue is whether two strings will be PERCEIVED as being equivalent, and perception is a far more complex (and less understood) issue.
The real issue is that if you earlier found something at hilton.hotel, or had decided that the reviews at sheraton.hotel were something you trusted, will you later remember if it was really those sites or hilton.hotels or sheraton.hotels?
At best, this could be considered a means of forcing anyone who registers a domain with .hotel or .hotels to register both, and map both of them to the same site. If that were to happen, the predictions of the Intellectual Property Constituency would be borne out, and all of those using these TLDs would have to make double the investment in domain names (presuming this is even possible with differing rules for each TLD). But the impact on users would be minimal.
But since we cannot guarantee that both TLDs will remain forever in sync, we do have a user problem. Once cannot expect the typical Internet user to be able to differentiate between two such name spaces, and therefore I believe that we have a genuine case of "confusingly similar". And one that will arguably have as much or more impact on real Internet users, the ones that we are supposed to be here to defend, than any other case I can recall in my 7 year involvement with ICANN At-Large.
If others on the ALAC agree, I would be happy to create a statement reflecting what I have said here, that we can, in our formal Advisory Committee role, forward as Advice to the Board.
Alan
______________________________**_________________ ALAC mailing list ALAC@atlarge-lists.icann.org https://atlarge-lists.icann.**org/mailman/listinfo/alac<; https://atlarge-lists.icann.org/mailman/listinfo/alac>
At-Large Online: http://www.atlarge.icann.org ALAC Working Wiki: https://community.icann.org/**display/atlarge/At-Large+ **Advisory+Committee+(ALAC)< https://community.icann.org/display/atlarge/At-Large+Advisory+Committee+(ALA...)
_______________________________________________ ALAC mailing list ALAC@atlarge-lists.icann.org https://atlarge-lists.icann.org/mailman/listinfo/alac
At-Large Online: http://www.atlarge.icann.org ALAC Working Wiki: https://community.icann.org/display/atlarge/At-Large+Advisory+Committee+(ALA...)
-- Evan Leibovitch Toronto Canada Em: evan at telly dot org Sk: evanleibovitch Tw: el56
Political correctness is exactly why this intervention needs to be done. We have a responsibility to raise the concern. Best, Rinalia On Sep 5, 2013 12:55 AM, "Carlton Samuels" <carlton.samuels@gmail.com> wrote:
Thanks for bringing this forth, Alan. Yes to instigating the discussion in the community, ALAC included, as well; we can always just forward Alan's note to the regional lists.
I can agree that the accepted definition of 'confusingly similar' narrows the understanding of how perception works. But all handwringing aside, the end result is likely negative impact on the end user. So, what do we do?
I read Evan's intervention closely and quite frankly, cannot find fault with his analysis, including his take on the likely result of any ALAC statement. The good thing is as Evan says; users will find alternatives to mitigate the slight. So I will not bounce the rubble. But I would support a statement in abundant surety it is for 'political correctness' rather than any expectation of meaningful change of course.
-Carlton
============================== Carlton A Samuels Mobile: 876-818-1799 *Strategy, Planning, Governance, Assessment & Turnaround* =============================
On Tue, Sep 3, 2013 at 9:02 PM, Alan Greenberg <alan.greenberg@mcgill.ca
wrote:
On 24 June 2013 as requested by the GAC, the Board New gTLD Program Committee (NGPC) considered the issue of singular and plural stings being confusingly similar and decided to let the original process stand (subject to individual objections). The record of the decision can be found at http://www.icann.org/en/**groups/board/documents/** minutes-new-gtld-25jun13-en.**htm#2.d< http://www.icann.org/en/groups/board/documents/minutes-new-gtld-25jun13-en.h... . Of particular note is a statement issued by three Board members (George Sadowsky, Olga Madruga-Forti and Cherine Chalaby) who supported the decision but regretted that, based on the Applicant Guidebook wording, they did not believe that they had the leeway to vote against it. One Board member (Mike Silber) did oppose the decision.
A central issue is that "confusingly similar" test relies purely on visual similarity and in the eyes of most (who were involved in the decision), adding an "S" makes it a recognizably different string.
The salient part of the Applicant Guidebook ( http://newgtlds.icann.org/en/ **applicants/agb/guidebook-full-**04jun12-en.pdf< http://newgtlds.icann.org/en/applicants/agb/guidebook-full-04jun12-en.pdf ) is section 2.2.1.1 of Module 2.
This review involves a preliminary comparison of each applied-for gTLD
string against existing TLDs, Reserved Names (see subsection 2.2.1.2), and other applied-for strings. The objective of this review is to prevent user confusion and loss of confidence in the DNS resulting from delegation of many similar strings.
Note: In this Applicant Guidebook, "similar" means strings so similar that they create a probability of user confusion if more than one of the strings is delegated into the root zone.
The visual similarity check that occurs during Initial Evaluation is intended to augment the objection and dispute resolution process (see Module 3, Dispute Resolution Procedures) that addresses all types of similarity.
I believe that the NGPC decision was incorrect. The problem is the belief that "visual similarity" relies purely on what, in computer terminology, would be called "pattern matching". Pattern matching is certainly part of human perception, but it is not limited to that. At issue is whether two strings will be PERCEIVED as being equivalent, and perception is a far more complex (and less understood) issue.
The real issue is that if you earlier found something at hilton.hotel, or had decided that the reviews at sheraton.hotel were something you trusted, will you later remember if it was really those sites or hilton.hotels or sheraton.hotels?
At best, this could be considered a means of forcing anyone who registers a domain with .hotel or .hotels to register both, and map both of them to the same site. If that were to happen, the predictions of the Intellectual Property Constituency would be borne out, and all of those using these TLDs would have to make double the investment in domain names (presuming this is even possible with differing rules for each TLD). But the impact on users would be minimal.
But since we cannot guarantee that both TLDs will remain forever in sync, we do have a user problem. Once cannot expect the typical Internet user to be able to differentiate between two such name spaces, and therefore I believe that we have a genuine case of "confusingly similar". And one that will arguably have as much or more impact on real Internet users, the ones that we are supposed to be here to defend, than any other case I can recall in my 7 year involvement with ICANN At-Large.
If others on the ALAC agree, I would be happy to create a statement reflecting what I have said here, that we can, in our formal Advisory Committee role, forward as Advice to the Board.
Alan
______________________________**_________________ ALAC mailing list ALAC@atlarge-lists.icann.org https://atlarge-lists.icann.**org/mailman/listinfo/alac<; https://atlarge-lists.icann.org/mailman/listinfo/alac>
At-Large Online: http://www.atlarge.icann.org ALAC Working Wiki: https://community.icann.org/**display/atlarge/At-Large+ **Advisory+Committee+(ALAC)< https://community.icann.org/display/atlarge/At-Large+Advisory+Committee+(ALA...)
_______________________________________________ ALAC mailing list ALAC@atlarge-lists.icann.org https://atlarge-lists.icann.org/mailman/listinfo/alac
At-Large Online: http://www.atlarge.icann.org ALAC Working Wiki: https://community.icann.org/display/atlarge/At-Large+Advisory+Committee+(ALA...)
participants (6)
-
Alan Greenberg -
Carlton Samuels -
Edmon -
Evan Leibovitch -
Rinalia Abdul Rahim -
Salanieta Tamanikaiwaimaro