Dear Working Group members,

Please see below the notes from the meeting on 27 August 2019. These high-level notes are designed to help WG members navigate through the content of the call and are not a substitute for the recording, transcript, or the chat, which will be posted at: https://community.icann.org/x/WKujBg.

Please note that following this call, WG members are encouraged to provide additional input on two topics:

• Should additional time should be provided after the string similarity review to allow potential objectors to consider results of the review and prepare objections?
• Should certain synonyms -- those associated with highly-regulated sectors and those representing verified TLDs -- be included in the String Similarity Review (example: .DOCTOR and .PHYSICIAN)?

Kind regards,

Emily

Notes and Action Items:

Actions:

ACTION ITEM 1: WG members are encouraged to comment on list about whether additional time should be provided after the string similarity review to allow potential objectors to consider results of the review and prepare objections. 

ACTION ITEM 2: WG members are encouraged to comment on list about whether certain synonyms -- those associated with highly-regulated sectors and those representing verified TLDs -- should be included in the String Similarity Review (example: .DOCTOR and .PHYSICIAN).

Notes:

1. Welcome/Agenda Review/SOI Updates

• No SOI updates 

2. Review of summary document – See: https://docs.google.com/document/d/1Q6_DxsCvSA_3B7ArncO2U4tWNY3vH7Wi4nINrouR4AI/edit?usp=sharing

a. String Similarity (page 21)

• Review of Policy Goals
• Review of CCT-RT Recommendation 35
• Review of High Level Agreements
• Review of concerns and suggestions from ICANN Org
• Feedback from ICANN Org -- one challenge is that even though an applicant may suggest a language or label, when the end user is looking at the label, it may also relate to another language. For example, someone applies for a label in English and another applies for a string in Spanish, the two strings might represent a single and a plural in Spanish, which could be confusing for the end user. 
• Comment - The use of the TLDs matter. If the two strings look like a single and a plural but the way they are used does not represent a singular and a plural, this may not be confusing.
• From one perspective, this still not reduce end user confusion. 
• From another perspective, it may be helpful to disambiguate the applications, looking at what the applications state in terms of purpose. That is the only thing we can assess at the point of application. There could be a contractual provision in the case of potential confusion.
• From another perspective, disambiguating the applications may not address the root issue of end user confusion.
• Additional consideration raised by ICANN Org -- there are different forms of inflection beyond singular/plural. Some languages that inflect for gender, person, respect, tense, and others. If singular/plural is considered confusing, the group may want to consider these other forms of inflection as confusingly similar? It may be that in the last round that only the singular/plural issue came up, but that other types might come up in the future.
• Question raised -- how do we boil this down to provide predictability for applicant?
• One suggestion -- use side shows, create an opportunity for applicants to collaborate with other applicants if the strings are variations of one another. Suggestion to look at the .accountant and .accountants example.
• Response -- this is more related to addressing the issue among applicants but does not address the concern about end-user confusion. 
• Question raised -- would “decide” and “decides” be allowed? This example shows an inflection that differentiates between the singular and plural subject for a verb. The only difference is an “s”. We are saying that that the addition of an “s” is important to differentiate in the context of a noun, but potentially not in the case of a verb. Inflections are reasonably well understood in linguistics relative to other morphology.
• Question - Is there an existing source that could be used by evaluators and applications to understand the different forms of inflections?
• Response - Inflections are typically provided in dictionaries. This can vary from language to language, but inflections such as tense are typically also covered in addition to singular/plural. 
• Comment - If it is easily determined and looking at the applications it is clear that one is intended to be an inflection of another, this may be something to consider.
• There seems to be agreement that having the different inflections of the same root, if they are intended to be inflections of the same root, is not good for end-users.
• Another issue raised -- Labels are not necessarily words. Consider the examples car vs. cars and com vs. coms. If one applicant applies for car with the intention of using it in association with the vehicle, but the other applies for cars as an acronym, would this be allowed? What about if someone applies for coms as an abbreviation, not a plural, would this be allowed?
• Suggestion -- If the intention of the application is clearly not singular/plural, then it should go through (for example abbreviations, acronyms, or brands that look like plurals of existing TLDs). 
• Nets basketball team is an example of a brand that is a plural of singular “net.”
• Question - How do you bind an applicant to the intent of the application? 
• Question - How does the stated intent of the applicant solve the issue of consumer confusion in the end?
• Response - We may not be able to completely solve the issue of potential confusion, typos on the part of end users, etc. but it is a step in the right direction.
• Review of comments and concerns from the SSAC. 
• One view on SSAC comment - we also have to look at how domain names have been used historically. SSAC is taking a purely technical view of what a domain name is. They may not have originally been intended this way, but there are now many domains that are semantic representations. 
• Review of comments and concerns from the NCSG.
• Question - should we consider treating string similarity reviews and objections differently than other forms of reviews and objections? Should there be additional time after review to allow for objections? This would allow people to consider cases they expected to be caught in the review. On the downside, it could extend the timeline of the application review process. 

ACTION ITEM 1: WG members are encouraged to comment on list about whether additional time should be provided after the string similarity review to allow potential objectors to consider results of the review and prepare objections. 

• ALAC comment regarding SWORD tool - if eliminated, a replacement is needed.
• Question -- why is there an assumption that an automated tool is needed or wanted?
• Clarification from ALAC -- a replacement solution is needed, not necessarily an automated tool. Something needs to be in place to address issues in the 2012 round.
• Suggestion -- offer a manual submission of the string to ICANN so they can test a string within a few days for a fee. It would only be possible to test against existing TLDs, not other applications.
• Review of comments regarding inclusion of synonyms (for example .DOCTOR and .PHYSICIAN) in the String Similarity Review and a potential dIfferent standard for strings in a highly-regulated sector or verified TLD.
• Discussion can continue on the mailing list on this topic.

ACTION ITEM 2: WG members are encouraged to comment on list about whether certain synonyms -- those associated with highly-regulated sectors and those representing verified TLDs -- should be included in the String Similarity Review (example: .DOCTOR and .PHYSICIAN).

• Review of comment on treatment of homonyms. This may be addressed in the examples we have discussed. 
• Review of comment from the ccNSO on coordination between the GNSO and ccNSO. 
• WG Co-Chairs sent a letter to Council on this issue noting that there are differences between the ways the two SOs treat this issue, the work is concluding in the GNSO, ccNSO members are welcome to participate in GNSO processes, and any outputs of a cross-community effort would still need to go through policy development processes in the respective SOs. Therefore, it may not be logical to combine these efforts. 

b. IDNs (page 26, time permitting)

• This will be covered on the next call.

3. Schedule for ICANN66

Saturday, 02 November

Session 1: 12:15-13:15 -- SubPro WT5 -- but could change to Full WG meeting

Session 2: 13:30-15:00 -- SubPro WT5 -- but could change to Full WG meeting

Monday, 04 November

Session 3:  09:00-10:15 -- SubPro Full WG

Session 4: 15:15-16:45 -- SubPro Full WG