[Gnso-newgtld-wg] Notes and Action Items - New gTLD Subsequent Procedures PDP WG - 30 March 1500 UTC

[Julie Hedlund]

Dear Working Group members,

Please see below the notes from the meeting on 30 March at 1500 UTC. 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/display/NGSPP/2020-03-30+New+gTLD+Subsequent+Procedures+PDP.

Kind regards,
Julie

Notes and Action Items:

Actions:

2.7.4 String Similarity Evaluation – See:https://docs.google.com/document/d/1kUlmZH8nxWTgfcRluA5FxLheMm4XhhOwkRt7om52aQU/edit?usp=sharing
Recommendation xx:
ACTION ITEM: Change text to “Applications will not automatically be placed in the same contention set because of a single letter difference with another application.”
ACTION ITEM: Add a recommendation that the commitment will be made in a mandatory PIC if two strings could be singulars and plurals but the intent is different, and also make it applicable if the TLD is transferred; also ask GDD to comment.  Also update the section where we say there are no mandatory PICs.
ACTION ITEM: Add an action item of an affirmation on visual similarity.

Section d Dependencies:
ACTION ITEM: Add Accountability Mechanisms to section d on dependencies.

Notes:

1. Updates to Statements of Interest: No updates provided.

2. Discussion of Final Report Topics: 2.7.4 String Similarity Evaluation – See:https://docs.google.com/document/d/1kUlmZH8nxWTgfcRluA5FxLheMm4XhhOwkRt7om52aQU/edit?usp=sharing page 61

“Recommendation xx: The Working Group recommends updating the standards of both (a) confusing similarity to an existing top-level domain or a Reserved Name, and (b) similarity for purposes of determining string contention, to address singular and plural versions of the same word, noting that this was an area where there was insufficient clarity in the 2012 round. Specifically, the Working Group recommends:” etc.

Re: “Using a dictionary to determine the singular and plural version of the string for the specific language or script.”

Discussion:
-- If we use a clarifying question to determine the intended use of a name, but is the enforcement if someone isn’t truthful.  We should be noting that in a recommendation.
-- Proposal for clarification:  (b) similarity for purposes of determining string contention ->  (b) similarity for purposes of determining string contention between current top-level domain applications.
-- We don’t really mean that an existing TLD would be put into a contention set.  It should say “applications will not automatically be placed in the same contention set because of a single letter difference with another application.”
-- Could have a situation where it doesn’t matter what the intention was for an open TLD.
-- Not sure the single character difference has enough clarity.  Trying to point out that we are looking at the intent.
-- Intention of the registry is only meaningful if supported (enforced) via restrictions (e.g. brand or community application). Open strings will be marketed by registrars - and they do not care about the "intentions" of the registry.
-- Something might not be considered plural if it is a .brand because they have strict controls on how that would be used.  Seem to have lost that in this example of .spring and .springs.
-- We are building in that kind of control -- a PIC or another way -- if the two applications want to exist.
-- Enforcement will be the key.
-- One open domain and one restricted (community or PIC), is a WORST case scenario.  The open one can be used to masquerade as the restricted/closed one.

-- Could add a recommendation for enforcement.
-- Must be a mechanism to ensure that the intent is transferred if ownership of the TLD is transferred.
-- If the TLD is sold, would new owner have the ability to change the "intent" and associated PIC?  if yes - Is that an existing process or would something have to be developed? We've seen examples for .brand being sold to new operators who repurpose it for other means.
-- The UDRP is allowed to look at content in making a decision, but not sure ICANN Compliance can enforce on content.
-- We will put in a recommendation for a mandatory PIC that they will commit to not using it as a plural or singular of the other.  If a registry is making a commitment then ICANN can enforce the commitment.
-- Re: “Using a dictionary to determine the singular and plural version of the string for the specific language or script.” See comment from ICANN Org: “Regarding the suggestion to use a dictionary to determine the singular/plural form of a word, it should be noted that a word may be identical in many languages, but generate different plural forms in each of the languages. For example, ‘kitab’ is ‘book’ in Arabic, Persian, Urdu, and many other languages, but the plural form of the word is different in each of the languages. It should also be noted that in many languages, reduplication is used as a means to make words plural where the word is repeated to make its plural form instead of adding a suffix like ‘s’. Additionally, some of these plural forming reduplications also make morpho-phonological changes, which means that the surface form is not just the word repeated by itself but slightly different. Even if the assessment of plural is limited to non-reduplication, it should be noted that pluralization is not limited to just suffixation, but can also include infixes (e.g., in Arabic, KiTaB (sg.) à KuTB (pl.).”

ACTION ITEM: Change text to “Applications will not automatically be placed in the same contention set because of a single letter difference with another application.”
ACTION ITEM: Add a recommendation that the commitment will be made in a mandatory PIC if two strings could be singulars and plurals but the intent is different, and also make it applicable if the TLD is transferred; also ask GDD to comment.  Also update the section where we say there are no mandatory PICs.
ACTION ITEM: Add an action item of an affirmation on visual similarity.

Re: “The Working Group considered a proposal put forward in public comment that homonyms should be included in the String Similarity review. From one perspective, homonyms may cause user confusion, for example in the 2012 round an application for .thai phonetically clashed with existing . ไทย (Thai IDN ccTLD).”

Discussion:
-- Talked about this extensively.
-- Didn’t get enough support in the WG to get a recommendation on it.
-- Seems like homonyms would be in the same contention set since they are the same visually and sound the same, but have different meanings.
-- Definition of homonym From Dictionary.com: 0" a word pronounced the same as another but differing in meaning, whether spelled the same way or not, as heir and air".
-- Question: Why do we care about homonyms? Answer: There were comments that were filed so we want to make sure we address them.
-- Seems like we are getting into a quagmire that will be impossible to enforce uniformly.
-- Question: What was the rule in 2012 on homonyms? Answer: They were not considered visually similar so they did not fail the string similarity evaluation.  One could have filed a string confusion objection and then a panel could have determined if they were confusingly similar, but don’t think we had an example of that.  This came up in the comments because we were talking about plurals and singulars.
-- Seems like there isn’t the willingness to go into homonyms.

Comparison of the way similarity was implemented for ccTLDs and for gTLDs:

-- Similarities in the way this was carried out.
-- Differed in that the CCs have a secondary review: If a TLD is found to be visually similar it would automatically general a panel that would look at it more closely via several factors.  In the gTLD process there isn’t a secondary review, but we are building in an appeals process.
-- Giovanni Seppia: I would suggest this group looks carefully at the scientific studies developed for assessing string similarity in a professional and sound way within the IDN ccTLD Fast Track. Again, it would be beneficial if the IDN ccTLD Fast Track lessons learnt in this area could be taken into account to ensure a consistent string similarity assessment throughout the TLD environment. String similarity panels must be made of true linguist experts that know how people's brain functions when looking at strings. This is one of the key lessons we learnt during the ten years of the IDN ccTLD Fast Track.

-- Could a gTLD appeals process look like the ccTLD secondary review?  Seems like it might be cost-prohibitive to go through a second review or every gTLD.  Incorporate the standards if an applicant wanted to appeal.
-- Consider referencing the ccLTD standards in a footnote and cross-reference to the appeals section.

ACTION ITEM: Add Accountability Mechanisms to Section d on dependencies.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/gnso-newgtld-wg/attachments/20200330/43af22cc/attachment-0001.html>