Dear Sub Team Members, Please see below the action items and discussion notes captured by staff from the meeting on 21 February. These high-level notes are designed to help Work Track Sub Team members navigate through the content of the call and are not a substitute for the recording. Please also see the recording on the meetings page at: https://community.icann.org/display/NGSPP/Work+Track+3+Meetings. In addition, the referenced slides are attached along with excerpts from the chat room are included below for ease of reference. Best regards, Julie Julie Hedlund, Policy Director Action Items/Discussion Notes 21 February 2017 1. Update from PDP Full Group -- two full group meetings will be held prior to ICANN58 to allow the group time to finalize CC2 questions. 2. Review of CC2 Questions from WT3 -- Full reading of the questions will take place in plenary on Monday. -- No additional feedback from the group. -- WT members are encouraged to provide feedback directly in the document or on the mailing list before the end of the week. 3. Confusing Similarity Objections and String Similarity Final Issue Report Sec.4.4.3  AGB Module 2.2.1   AGB Module 3.2.2.1  AGB Module 3.5.1  AGB Module 4.1 -- Background provided by staff -- There is a little bit of miscommunication.  We don't have slides on string similarity.  This is the excerpt from the Issue Report (4.4.2 String Similarity). -- Standard -- so nearly resembles another visually that it is likely to deceive or cause confusion. -- Panel looked at a few things and the outcomes were different depending on what they were looking at. -- 4 sets of circumstances. -- Took into account the sort algorithm -- informed by not determinative. -- Questions and Concerns: treatment of singular and plurals (touched on in the email Jeff circulated).  Also relating to timing to release the results of the review. String Confusion Objections (SCOs) (see slides): Background: -- One of the four objections grounds (slide 2). -- Standing to file limited to existing TL operator -- between an applied-for TLD and TLD that it currently operates. -- Outcome is both applications are placed in an objection set. -- Carried out by ICDR. -- Applicant Guidebook language (slide 3) -- Statistics 67 total SCOs. Perceived inconsistent SCO Expert Determinations (slide 4): -- Many have perceived that SCO outcomes have been inconsistent. -- 11 Feb 2014 published Proposed Review Mechanism to Address Perceived Inconsistent Expert Determinations on SCOs: Defined inconsistency.  Discussion of  principles. -- Proposal: ICDR would be a panel of last resort and "Could the Expert Panel have reasonably come to the decision reached on the underlying SCO through an appropriate application of the standard of review as set forth in the AGB procedural rules?" Public Comment (slide 5): -- 8 said do not adopt the proposed mechanism. -- 2 said adopt -- 5 said adopt with expanded scope -- 3 said do not adopt or expand scope -- All should be reviewed or do not adopt -- Recommend modifications if adopted Board Resolution (slide 6): -- NGPC laid out a couple of sets CAM/COM and Commercial Connect/Amazon reversed.  (Car/Cars self-resolved.) Singular/Plurals (Slide 7): -- Also an NGPC Resolution -- no changes to the existing mechanism in the AGB. Questions/Issues for Consideration (Slide 8): -- As there is evidence of inconsistent SCO determinations 1) do policy recommendations need to be revised 2) does the standard of String Confusion in the ABG need to be revised? 3) Does there need to be a method to challenge/appeal decisions? -- Although NGPC determined that singular/plurals did not meet the definitioin of inconsistent expert determinations, should guidance be developed? Discussion: -- The reason to include String Similarity as well as Confusion is that they should be two sides if the same coin.  The standard in String Similarity was very limited -- visual similarity.  The SCO process had a broader scope to challenge.  But we found that strings that were similar/plurals would naturally fall in the same review.  No findings of similarity in an existing TLD because no one thought to apply for a plural of an existing TLD as these would be ruled similar. -- A group of registries were working on trying to come up with recommendations to pass on to this group.  See this in the next few weeks as a proposal.  Things that are plurals or singular of an existing string they should not proceed. -- Question: Essentially the recommendation is to expand string similarity review to encompass meaning as well (new vs news)?  Answer: Yes, only with relation to singular and plurals.  Not for the string similarity panels to look at meaning.  No, not really looking at meaning, but whether something is a plural or singular.  Such as cake or cakes.  We are asking for there to be a short appeal-type mechanism. -- Conversation on the list that seems to go to Cool vs .kühl   Also the chat relating to linguists. -- Experiences from the last round:  (Karen Bernstein)  1) if there is a plural of an existing string it should not be allowed. 2) on linguists: when someone is registry a domain name in an extension they will be confused because of collision and phishing. -- Confusingly similar was something ALAC spent a lot of time on.  There is enough subtle difference between the confusingly similar evaluation and the objection process.  Objection was a much more nuanced and wider scope -- would a user likely get confused.  We need to do a much better job on what is clearly not allowed, but we have to do a much better job outlining what the panelists are supposed to be comparing. -- One clearly doesn't want to make it easier for phishers, but users are undiscriminating so it doesn't really matter. -- If it a plural of an existing string then it gets thrown out.  Not advocating for a huge broadening of the standard.  Add visually similar for plurals.  The objection process would still be much broader. -- Question: Would not want to say adding an "s" is visually similar.  Are there other ways of indicating plural or singular other than adding an "s"? Answer: Could use a dictionary as a tool because there would be applied-for strings where simply adding an "s" is not how you would make the plural.  It was meant to be intra-language.  In the applicable language. -- Registry group said "plural", which could mean many different things depending on the language. Next Steps: Take the proposal from the registries group and put it in a Google doc to start to consider it; also, consolidate what we have discussed to fine tune it off line in a Google doc.

From the chat:

Kristina Rosette (Amazon Registry): New/News was not a good example. Kristina Rosette (Amazon Registry): yes Kristina Rosette (Amazon Registry): or, cake and cakes (as used in the doc) Jon Nevett: .child and .children too? Jeff Neuman: Yes. Jon Nevett: how about ING? Jeff Neuman: Covered under the SCO process. Kristina Rosette (Amazon Registry): not covered. Jon Nevett: conduct and conducting?  should we expand? Rubens Kuhl: .cool x .kühl ? Jeff Neuman: Not sure they are plural or singular of each other. Kristina Rosette (Amazon Registry): @Jon:  Up to this group.  RySG sub team decided not to go beyond singular and plural Jon Nevett: right -- think and thinking is no more or less confusing than child and children Jeff Neuman: potentially.....but what about .book and .booking?  There are more examples where adding an “ing” is not necessarily confusing.  As long as there is a short appeals process for someone to challenge the string similarity review as well, I think we are covered Kristina Rosette (Amazon Registry): @Rubens:  My recollection from the RySG subteam discussion was that we didn't want to cross languages/scripts because of the potential disadvantage to IDNs. Jeff Neuman: @Kristina - correct Rubens Kuhl: Most phishing activity does not require support from the TLD. Unfortunately firstbank.tk is as effective as first.bank. Hopefully that might change in the future, but the current situation of phishing is not much affected by TLD. avri doria: when we say we don't support plurals, do we mean they go into a contention seet?  someone may prefer the plural. Rubens Kuhl: @Avri, I believe it would be contention set if similar to applicant, denied if similar to existent TLD. Kristina Rosette (Amazon Registry): @Avri:  Yes, they go into a contention set avri doria: ot it. just checking.  the phrase don't accept threw me. Jon Nevett: but new and news ok Rubens Kuhl: .campus x .campi Kristina Rosette (Amazon Registry): @Alan:  Yes, that's why we referenced using a dictionary to determine the plural. Jon Nevett: forum and fora would be in the same set avri doria: does the rule apply across all languages? Annebeth Lange, ccNSO 2: In Norwegian it is another way - adding "en" for singular and "ene" for plural. But I suppose not many Norwegian years will be applied for Kristina Rosette (Amazon Registry): i can answer this . . . avri doria: both inter-language and intra-language Rubens Kuhl: Straß, Stras·se avri doria: ok only intra-language avri doria: any lnaguage for which tere is a dictionary? Kristina Rosette: Presumably yes. Greg Shatan: Was cross-language but not cross script considered?  That would avoid the IDN issue. Kristina Rosette: Focusing on the language rather than the script. Rubens Kuhl: @Avri, I think languages without written form are already excluded from the domain name system. Like Tupi-Guarani. avri doria: just lookiing for a generalizable rule