- ALAC - lists.icann.org

Fwd: [Soac-infoalert] Agenda | New gTLD Program Committee | ICANN
by Carlton Samuels Sept. 10, 2013

Sept. 10, 2013

Seems the ALAC has come of age, don't? -Carlton ============================== Carlton A Samuels Mobile: 876-818-1799 *Strategy, Planning, Governance, Assessment & Turnaround* ============================= http://www.icann.org/en/groups/board/documents/agenda-new-gtld-10sep13-en.h… ** 10 September 2013 *Consent Agenda:* - Approval of Minutes *Main Agenda:* - Update on String Similarity - BGC recommendation on Reconsideration Request 13-5 - GAC Communiqué Durban – Comprehensive Review of the Scorecard - GAC Communiqué Beijing – Comprehensive Review of the Scorecard - GAC Communiqué Beijing – Category 1 - ALAC Statement on the Preferential Treatment for Community Applications in String Contention - ALAC Statement on Community Expertise in Community Priority Evaluation - AOB ** -- David A. Olive Vice President, Policy Development Support Internet Corporation for Assigned Names and Numbers (ICANN) General Manager, ICANN Regional Headquarters -Istanbul Hakki Yeten Cad. Selenium Plaza No:10/C K:5&6 34349 Fulya, Besiktas, Istanbul, Turkey Tel: +90.212.381.8727 Fax: +90.212.381.8731 Mobile: +1. 202.341.3611 ****

1 0

Re: [ALAC] Fwd: NCSG Appeal of ICANN Secrecy Claim Over Information Shaping ICANN Staff Policy Decision to Create New Rights for Trademark Holders in DNS
by Alan Greenberg Sept. 9, 2013

Sept. 9, 2013

At 09/09/2013 05:44 PM, Evan Leibovitch wrote: >Is there any interest in supporting this -- or at least understanding the >issues better? > >This could be seen as a significan A&T issue. Regardless of one's view of >the merits of the trandmark claims mechanism, the lack of transparency in >developing this serious implementation issue is potentially a serious point >of concern. > >- Evan I have not gone over the request or response in any detail, but on the surface, the response may be pretty close to being in line with the policy. Perhaps more subject to the issue of A&T is whether the terms of the DIDP as quoted in the response (and in the policy at http://www.icann.org/en/about/transparency/didp) are reasonable, and if it is reasonable to expect staff to quote WHICH reason is used in each denial. Even just using the exclusions of "if disclosed [...] likely to compromise [...] ICANN's deliberative process by inhibiting the candid exchange of ideas and communications..." and "Information requests that are [...] overly burdensome...", you cover a pretty large swath of internal documents. And lots of room for judgement calls. I can sympathize with all of those rationales, but at the same time, have to ask if the end-result is what was intended when this policy was put in place; or perhaps more to the point, what the community THOUGHT this policy was all about when it was put in place. Alan

1 0

Fwd: NCSG Appeal of ICANN Secrecy Claim Over Information Shaping ICANN Staff Policy Decision to Create New Rights for Trademark Holders in DNS
by Evan Leibovitch Sept. 9, 2013

Sept. 9, 2013

Is there any interest in supporting this -- or at least understanding the issues better? This could be seen as a significan A&T issue. Regardless of one's view of the merits of the trandmark claims mechanism, the lack of transparency in developing this serious implementation issue is potentially a serious point of concern. - Evan ---------- Forwarded message ---------- From: Robin Gross <robin(a)ipjustice.org> Date: 9 September 2013 14:51 Subject: NCSG Appeal of ICANN Secrecy Claim Over Information Shaping ICANN Staff Policy Decision to Create New Rights for Trademark Holders in DNS To: NCSG-DISCUSS(a)listserv.syr.edu With great thanks to NCSG member Ed Morris, NCSG filed an appeal (attached) of ICANN staff's decision to not release any new information to NCSG in response to our DIDP request for information about staff's decision to adopt a policy creating new rights for trademark holders in the DNS. The DIDP process is supposed be be part of ICANN's "accountability" process (sort of like a Freedom of Information Act (FOIA) request for information) intended to ensure transparency in the development of public policies. But if staff can just blow those DIDP requests off too and claim the info is either secret or too burdensome to release, ICANN's claim of "accountability and transparency" is nothing more than self-serving PR that lacks any basis in reality. NCSG's appeal is attached and I'm keeping track of the filings in this tragedy here: https://community.icann.org/display/gnsononcomstake/ICANN+Unaccountability *Is ICANN Accountable, Transparent, and "Bottom-Up" in its Governance?* - *NCSG Reconsideration Request of ICANN staff's decision to impose the "trademark + 50" policy for new GTLDS <https://community.icann.org/download/attachments/42730712/request-ncsg-19ap…>(Request 13-3 on 19 April 2013)<https://community.icann.org/download/attachments/42730712/request-ncsg-19ap…> * - Attachments to NCSG Reconsideration Request 13-3<https://community.icann.org/download/attachments/42730712/request-ncsg-19ap…> - ICANN's 1st Response (what ICANN's lawyers hoped they could get away with)<https://community.icann.org/download/attachments/42730712/recommendation-nc…> 16 May 2013 - NCSG Letter to Board of Directors Regarding ICANN's 1st Response <https://community.icann.org/display/gnsononcomstake/2013-06-17-NCSG-Request…> 17 June 2013 - GNSO Council discussion on impact of 1st response on bottom-up multi-stakeholder model of governance<https://soundcloud.com/ip_justice/icann-gnso-debate-on-bgc> 13 June 2013 - ICANN's 2nd Response (revised response following community-wide outrage to 1st response)<https://community.icann.org/download/attachments/42730712/recommendation-nc…> 25 June 2013 - ICANN Board New GTLD Program Committee Approves 2nd Response<http://www.icann.org/en/groups/board/documents/resolutions-new-gtld-02jul13…> 2 July 2013 - *NCSG DIDP request for info surrounding ICANN staff's decision to create new rights for large trademark holders after Guidebook published<https://community.icann.org/download/attachments/42730712/ncsg-request-24ju…> * 24 July 2013 - ICANN "Response"<https://community.icann.org/download/attachments/42730712/ncsg-response-24a…> 24 August 2013 - NCSG Appeal of ICANN's secrecy claims over most information surrounding ICANN staff's decision to create new rights for trademark holders in DNS<https://community.icann.org/download/attachments/42730712/NCSG+RECONSIDERAT…> 8 September 2013 -- Evan Leibovitch Toronto Canada Em: evan at telly dot org Sk: evanleibovitch Tw: el56

1 0

Fwd: Philosophical Foundation for ICANN
by Evan Leibovitch Sept. 6, 2013

Sept. 6, 2013

http://icannwiki.com/index.**php/Philosophy<http://icannwiki.com/index.php/Philosophy> A very interesting project. The author, Marc Perkel <marc(a)churchofreality.org> is looking for feedback. - Evan

1 0

Singular/Plural in new gTLDs
by Alan Greenberg Sept. 6, 2013

Sept. 6, 2013

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.…. 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

6 10

Re: [ALAC] Singular/Plural in new gTLDs
by Alan Greenberg Sept. 5, 2013

Sept. 5, 2013

At 04/09/2013 12:53 PM, Carlton Samuels 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. Indeed! That is what regional folks on the ALAC list are supposed to do if there is interest. > 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. I"m sure that users will survive most things. But we are supposed to be here to make things better. The fact that we cannot always do that should not eliminate our need to do so if we can (at least that is my take). Alan >-Carlton > > >============================== >Carlton A Samuels >Mobile: 876-818-1799 >Strategy, Planning, Governance, Assessment & Turnaround >============================= > > >On Tue, Sep 3, 2013 at 9:02 PM, Alan Greenberg ><<mailto:alan.greenberg@mcgill.ca>alan.greenberg(a)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.…>http://www.icann.org/en/groups/board/documents/minutes-new-gtld-25jun13-en.…. >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 ><mailto:ALAC@atlarge-lists.icann.org>ALAC(a)atlarge-lists.icann.org >https://atlarge-lists.icann.org/mailman/listinfo/alac > >At-Large Online: <http://www.atlarge.icann.org>http://www.atlarge.icann.org >ALAC Working Wiki: ><https://community.icann.org/display/atlarge/At-Large+Advisory+Committee+(AL…>https://community.icann.org/display/atlarge/At-Large+Advisory+Committee+(AL… >

3 2

Re: [ALAC] Singular/Plural in new gTLDs
by Alan Greenberg Sept. 5, 2013

Sept. 5, 2013

The confusingly similar objection results are interesting. Although I have not gone through them carefully, there are already cases where plural is deemed to be confusingly similar to singular, and I think also the opposite. And a case where .shop won an objection over a Chinese string meaning "online shopping" because the meaning was similar and someone who reads both English and Chinese could be confused. A real grab-bag. See <http://images.go.adr.org/Web/AmericanArbitrationAssociation/%7B3d7531bb-c0b…>http://images.go.adr.org/Web/AmericanArbitrationAssociation/%7B3d7531bb-c0b…. Alan At 05/09/2013 05:52 PM, Dev Anand Teelucksingh wrote: >Some thoughts: > >The AGB process should have empowered the String Similarity Panel >during the Initial Evaluation to consider similarity as how a legal >rights objection panel hearing a legal rights objection by an >intergovernmental organization (IGO) would have to consider similarity >"Whether the applied-for gTLD is identical or similar, including in >appearance, phonetic sound or meaning, to the name or acronym of the >objecting IGO" (Page 167 of the AGB, Section 3.5.2) and place such >string applications in Non-Exact Match Contention Sets. > >And given the objective of the String Similiarity as cited in 2.2.1.1 >("to prevent user confusion and loss of confidence in the DNS >resulting from delegation of many similiar strings" ; "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"), the ALAC >(and the IO) should have also been given standing (and funding!) to >object to file String Confusion Objections ("The applied-for gTLD >string is confusingly similar to an existing TLD or to another >applied-for gTLD string in the same round of applications"), instead >of just existing TLD operators and gTLD applicants in the gTLD >application round. > >And the publishing of the String Similiarity Review a mere two weeks >before the end of the objection period was extremely late and should >have been published much earlier for the community to deal with this >issue. > >Section 2.2.1.1.2 "Review Methodology" on page 58 of the AGB says this: > >The [String Similarity] panel will examine all the algorithm data and >perform its own review of similarities between strings and whether >they rise to the level of string confusion. In cases of strings in >scripts not yet supported by the algorithm >(https://icann.sword-group.com/algorithm/) the panels assessment >process is entirely manual. > >The [String Similarity] panel will use a common standard to test for >whether string confusion exists, as follows: > >Standard for String Confusion String confusion exists where a string >so nearly resembles another visually that it is likely to deceive or >cause confusion. For the likelihood of confusion to exist, it must be >probable, not merely possible that confusion will arise in the mind of >the average, reasonable Internet user. Mere association, in the sense >that the string brings another string to mind, is insufficient to find >a likelihood of confusion." > >This suggests that applied for strings that are of singular and plural >forms ("mere association") are insufficient to find for similarity >between such string applications. > >However, in section 2.2.1.1.3, "Outcomes of the String Similarity >Review", there is this: > >"An application that passes the String Similarity review is still >subject to objection by an existing TLD operator or by another gTLD >applicant in the current application round. >That process requires that a string confusion objection be filed by an >objector having the standing to make such an objection. Such category >of objection is not limited to visual similarity. Rather, confusion >based on any type of similarity (including visual, aural, or >similarity of meaning) may be claimed by an objector." > >Yet, the mandate of the DRSP hearing string confusion objections in >page 165 of the AGB "3.5.1 String Confusion Objection" repeats only >the standard for string confusion in 2.2.1.1.2 : >"A DRSP panel hearing a string confusion objection will consider >whether the applied-for gTLD string is likely to result in string >confusion. String confusion exists where a string so >nearly resembles another that it is likely to deceive or cause >confusion. For a likelihood of confusion to exist, it must be >probable, not merely possible that confusion will arise in the >mind of the average, reasonable Internet user. Mere association, in >the sense that the string brings another string to mind, is >insufficient to find a likelihood of confusion." > >and not the the advice in 2.2.1.1.3. This is inconsistent and should >be noted in a statement. Mention could also be made to note the >ongoing confusion of the string confusion objections where certain >singular and plural pairs are judged to be similar and others pairs >are not. > >- >Dev Anand > > >On Wed, Sep 4, 2013 at 3:18 PM, Alan Greenberg ><alan.greenberg(a)mcgill.ca> wrote: > > At 04/09/2013 12:53 PM, Carlton Samuels 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. > > > > > > Indeed! That is what regional folks on the ALAC list are supposed to do if > > there is interest. > > > > > > > >> 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. > > > > > > I"m sure that users will survive most things. > But we are supposed to be here > > to make things better. The fact that we cannot always do that should not > > eliminate our need to do so if we can (at least that is my take). > > > > Alan > > > > > >> -Carlton > >> > >> > >> ============================== > >> Carlton A Samuels > >> Mobile: 876-818-1799 > >> Strategy, Planning, Governance, Assessment & Turnaround > >> ============================= > >> > >> > >> On Tue, Sep 3, 2013 at 9:02 PM, Alan Greenberg > >> <<mailto:alan.greenberg@mcgill.ca>alan.greenberg(a)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.…>http://www.icann.org/en/groups/board/documents/minutes-new-gtld-25jun13-en.…. > >> 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 > >> <mailto:ALAC@atlarge-lists.icann.org>ALAC(a)atlarge-lists.icann.org > >> https://atlarge-lists.icann.org/mailman/listinfo/alac > >> > >> At-Large Online: > >> <http://www.atlarge.icann.org>http://www.atlarge.icann.org > >> ALAC Working Wiki: > >> > <https://community.icann.org/display/atlarge/At-Large+Advisory+Committee+(AL…>https://community.icann.org/display/atlarge/At-Large+Advisory+Committee+(AL… > >> > > _______________________________________________ > > ALAC mailing list > > ALAC(a)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+(AL… >_______________________________________________ >ALAC mailing list >ALAC(a)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+(AL…

1 0

Re: [ALAC] Singular/Plural in new gTLDs
by Alan Greenberg Sept. 4, 2013

Sept. 4, 2013

Thanks Rinalia. Regarding 1, yes, is the decision were revered, it would establish some new (or larger) contenction sets. On blocking a name so that it is only one of the TLDs (or alternatively bundling them together), a bit problematic if the two TLDs are operated by different registries. Alan At 04/09/2013 12:53 AM, Rinalia Abdul Rahim 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" ><<mailto:alan.greenberg@mcgill.ca>alan.greenberg(a)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 ><<mailto:alan.greenberg@mcgill.ca>alan.greenberg(a)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.…>http://www.icann.org/en/groups/board/documents/minutes-new-gtld-25jun13-en.…. > 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 > > <mailto:ALAC@atlarge-lists.icann.org>ALAC(a)atlarge-lists.icann.org > > https://atlarge-lists.icann.org/mailman/listinfo/alac > > > > At-Large Online: <http://www.atlarge.icann.org>http://www.atlarge.icann.org > > ALAC Working Wiki: > <https://community.icann.org/display/atlarge/At-Large+Advisory+Committee+(AL…>https://community.icann.org/display/atlarge/At-Large+Advisory+Committee+(AL… > > >_______________________________________________ >ALAC mailing list ><mailto:ALAC@atlarge-lists.icann.org>ALAC(a)atlarge-lists.icann.org >https://atlarge-lists.icann.org/mailman/listinfo/alac > >At-Large Online: <http://www.atlarge.icann.org>http://www.atlarge.icann.org >ALAC Working Wiki: ><https://community.icann.org/display/atlarge/At-Large+Advisory+Committee+(AL…>https://community.icann.org/display/atlarge/At-Large+Advisory+Committee+(AL…

4 3

Fwd: Re: [ALAC-Announce] VOTE ANNOUNCEMENT: ALAC Statement on the Community Priority Evaluation (CPE) Guidelines Update from ICANN
by Olivier MJ Crepin-Leblond Sept. 4, 2013

Sept. 4, 2013

Dear ALAC members, please note that this and the vote on "ALAC Statement on the Explore the Draft Next Generation gTLD Directory Services Model" are very short 3 day votes due to technical reasons, so please make sure you vote early in this. Thanks, Olivier On 04/09/2013 01:49, ICANN At-Large Staff wrote: > Dear All, > > Olivier Crépin-Leblond, Chair of the ALAC, has asked that a vote be held by the ALAC on the proposed "ALAC Statement on the Community Priority Evaluation (CPE) Guidelines Update from ICANN<https://community.icann.org/x/1wGMAg>" for communication to the relevant parties. > > ***** > Question: Do you support the ratification of the "ALAC Statement on the Community Priority Evaluation (CPE) Guidelines Update from ICANN<https://community.icann.org/x/1wGMAg>" for communication to the relevant parties? > ***** > > Additional information on this Statement can be found on the At-Large Community Priority Evaluation (CPE) Guidelines Update from ICANN Workspace<https://community.icann.org/x/1wGMAg>. > > Please note that the poll will be open from 3-September-2013 23:59 UTC to 6-September-2013 12:00 UTC. > > Regards, > > Heidi Ullrich, Silvia Vivanco, Matt Ashtiani, Gisella Gruber, Nathalie Peregrine and Julia Charvolen > ICANN Policy Staff in support of ALAC > E-mail: staff(a)atlarge.icann.org<mailto:staff@atlarge.icann.org> > _______________________________________________ > ALAC-Announce mailing list > ALAC-Announce(a)atlarge-lists.icann.org > https://atlarge-lists.icann.org/mailman/listinfo/alac-announce > > At-Large Official Site: http://www.atlarge.icann.org > -- Olivier MJ Crépin-Leblond, PhD http://www.gih.com/ocl.html

1 0

Fwd: Re: [ALAC-Announce] VOTE ANNOUNCEMENT: ALAC Statement on the Explore the Draft Next Generation gTLD Directory Services Model
by Olivier MJ Crepin-Leblond Sept. 4, 2013

Sept. 4, 2013

Dear ALAC members, please note that this and the vote on "ALAC Statement on the Community Priority Evaluation (CPE) Guidelines Update from ICANN" are very short 3 day votes due to technical reasons, so please make sure you vote early in this. Thanks, Olivier On 04/09/2013 01:49, ICANN At-Large Staff wrote: > Dear All, > > Olivier Crépin-Leblond, Chair of the ALAC, has asked that a vote be held by the ALAC on the proposed "ALAC Statement on the Explore the Draft Next Generation gTLD Directory Services Model<https://community.icann.org/x/Xz5-Ag>" for communication to the relevant parties. > > ***** > Question: Do you support the ratification of the "ALAC Statement on the Explore the Draft Next Generation gTLD Directory Services Model<https://community.icann.org/x/Xz5-Ag>" for communication to the relevant parties? > ***** > > Additional information on this Statement can be found on the At-Large Explore the Draft Next Generation gTLD Directory Services Model Workspace<https://community.icann.org/x/Xz5-Ag>. > > Please note that the poll will be open from 3-September-2013 23:59 UTC to 6-September-2013 12:00 UTC. > > Regards, > > Heidi Ullrich, Silvia Vivanco, Matt Ashtiani, Gisella Gruber, Nathalie Peregrine and Julia Charvolen > ICANN Policy Staff in support of ALAC > E-mail: staff(a)atlarge.icann.org<mailto:staff@atlarge.icann.org> > _______________________________________________ > ALAC-Announce mailing list > ALAC-Announce(a)atlarge-lists.icann.org > https://atlarge-lists.icann.org/mailman/listinfo/alac-announce > > At-Large Official Site: http://www.atlarge.icann.org > -- Olivier MJ Crépin-Leblond, PhD http://www.gih.com/ocl.html

1 0