[Gnso-newgtld-wg-wt3] Actions/Discussion Notes: Work Track 3 Sub Team Meeting 10 October

Tue Oct 10 21:07:06 UTC 2017

Dear Work Track members,

Please find below the action items and discussion notes from the call on 10 October.  These high-level notes are designed to help Work Track members navigate through the content of the call and are not a substitute for the chat transcript or the recording.

The document referenced on the call is attached and excerpts from the chat room are included below.

Kind regards,

Emily

--------------------------------------------------------------------------

Action Items and Discussion Notes: 10 October 2017

1. Updates to SOI:  None.

2. Plenary Update:

-- Meeting on 09 October.  After going through the work tracks had a discussion on work track 5 in terms of the co-leaders.  Decision among the co-chairs and work track leaders: Martin Sutton.  Took the decision to the GNSO Council.

-- Went through the predictability track.  Almost ready for a first reading in the full meeting.  Time to bring the three issues to a close to produce draft recommendations.

-- Planning for Abu Dhabi.

-- Check to see if the full PDP WG meeting is still on for 23 October.

3. Meeting before ICANN#60?  Move to week of 17 Oct.?

-- Move up the meeting from the week of the 24th to the week of the 16th?  Move to the same time 1500 UTC on 17 October?

-- With all that we have to cover we need to hold another meeting with whomever is available on the 17th.

-- Saving for the face-to-face the topic of communities -- evaluation and priority.  Have a dedicated session with the GAC at 10:30-11:00 on Sunday, 29 October on community applications and applicant support. Consider using 17 October meeting to prep -- get guidance from PDP WG Leadership.

Steve Chan: After the 30 minute GAC meeting with WT1 and WT3, the GAC will be talking amongst themselves, though it's an open session for anyone to attend.

-- No meetings the week of the 23rd as people will be traveling.

4. CC2 — String Similarity — Q 3.4.4 - 3.4.6:

3.4.4 -- Do you believe that there should be some sort of mechanism to allow for a change of applied-for TLD when it is determined to be in contention with one or more other strings?

-- ALAC, RySG, BRG, and Afilias opposed allowing applicants to change an applied-for TLD on the basis of contention.

-- Valideus supported allowing applicants to name an alternative string at the time of application.

Discussion:

-- If you were going to allow something like that it would have to be done before any of the string swere made public.  The rules would have to be pretty tight.  Could see more problems than possible positive outcomes.

-- In limited circumstance should consider allowing string to be changed to something similar or applied for.  Example: If BC was found similar to BBC -- should allow one or both of them to change to something else.  Better example if something applied for is similar to an existing string.  Would need some tight rules.

-- Wonder if it could be done at the time of application -- choices to be listed.  If 1 was in contention fall back to 2.  Would it work for the applicant name three or four options?

-- Offering the ability to change offers massive opportunities for gaming. At best it should be a very limited set -- a preset list.  We would have to think about ways to avoid gaming.

-- Where brands might have similar looking names, even if they aren't in contention, if both couldn't go forward maybe one of them or both could have a very limited right to change their strings.

-- Having a second choice in your application that you can opt to for avoiding string contention is a legitimate reason to have a backup.

-- If it is to resolve string contention, but if you are in string contention and your second choice also is in string contention and that was a weaker contention set that could allow gaming.  There needs to be guidance.

-- In the policy the intention was that if there was contention those in contention should converse and pick other names in order to proceed.  But this was not carried over into implementation.

-- There was discussion earlier about gaming but all of the examples are where there is a string similarity problem, which would be initiated by ICANN.

-- Two different things: 1) string similarity 2) string contention.  At the string similarity stage: if a string was confusingly similar to another string already existing then it dies.  If it is to another application then it is put into a contention set.  If a company wants something different (instead of dying) it should be allowed.  

-- Example: .born -- under existing rules .born would not be allowed to exist.  If that company could have .borne to be not so similar you coudl go ahead with that.  Not talking about trying to avoid an auction, or contention.

>From the chat:

Donna Austin, Neustar: Given Jeff's examples, I think opening this up will create more problems then its worth.

Phil Buckingham: That would be a great idea , Anne

Jim Prendergast: if as Jeff said it can be gamed too easily - I think we need to be very very cautious. 

Roger Carney: @jeff @Jim, talking that one step further, I am not sure the benefits outwiegh the risks/costs

Jim Prendergast: they way round 1 went - I would have loved to applied for a bunch of contended tlds.  Would have made huge $$$ in private auctions.

jeff neuman: @Jim - I know, but in the brands situation I can see areas where changing a string should be allowed

Donna Austin, Neustar: @Roger, I don't think any benefit would outweigh the risk/cost.

jeff neuman: Lets say a string is found to be "geographic" when no one thought it would be and the GAC objected.  I think rather than the Board refusing to delegate anything, perhaps an alternative could be selected

Donna Austin, Neustar: @Roger, I meant to say I agree with you.

jeff neuman: I think we should separate String Similarity from String contention

jeff neuman: They are 2 different things

Anne Aikman-Scalese: Don't think you should be able to opt out of one string contention set into another.  It would have to be an option to go to a clear string that was contemplated by your initial application as a fallback.

jeff neuman: The first part is String Similarity (a check against existing strings)

jeff neuman: if it is judged to be too similar to an existing string, the application dies

Phil Buckingham: Anne , I think we could apply that ( a second choice )  to a closed brand , but would be more difficult , in terms  of potential gaming for an open TLD 

jeff neuman: I am talking about at this stage that a string should be allowed to be changed as opposed to at the "Contention phase"

Jon Nevett: what if more than one party wanted to swtich to the same alternative TLD?  Would that create another contention set?

Anne Aikman-Scalese: Rules:  1.  you have to specify your alternates up front - max 4 total.  You cannot opt into another contention set.  (3) There should still be a reasonable relationship between the TLD name and the stated Question 18 purpose of the TLD.

avri doria: Jon, I think they would need to agree among themselves with a rule of  no new contention produced.

Donna Austin, Neustar: @Jon, I think it would create another contention set.

Alan Greenberg: @Jeff, I did understand and I was (I thought) agreeing with you.

3.4.5 - Do you feel that the contention resolution mechanisms from the 2012 round (i.e. CPE and last-resort auctions) meet the needs of the community in a sufficient manner?

-- BRG, RySG, Afilias, and ALAC felt that CPE and last resort auctions are generally a reasonable approach.

>From the chat:

jeff neuman: I am not sure people are happy...but not sure what the alternatives are

Jamie Baxter | dotgay: the notion .. yes, the implementation .. no

Jim Prendergast: arent we still waiting for CPE review by board?

Donna Austin, Neustar: yes we are Jim

Jamie Baxter | dotgay: @Jim .. yes. we are now a year into the CPE investigation with no clear sight on a result

3.4.6 -- Do you believe that private auctions (i.e., NOT the auctions of last resort provided by ICANN) resulted from any harm?

-- Jim Prendergast, RySG, Afilias, and ALAC stated that private auctions resulted in speculative applications.  ALAC favored prohibiting private auctions, while RySG and Afilias preferred other narrowly tailored mechanisms to address speculation.

Discussion:

-- Not sure how we prevent private auctions.  Perhaps you can prevent the overt marketing of private auctions.

-- May not be in a position to prevent them, but might be ways to disincentivise them.

>From the chat:

avri doria: i think they may provide a form of gaming.

avri doria: i mean private auctions - personal view

jeff neuman: how do we prevent private auctions?

avri doria: hard to prevent

Jon Nevett: private auctions is just one form of contention resolution -- policy question is whether we should support private resolution or not.

Jim Prendergast: you could allow for other resolutions - forming JVs wa prohibited last round

Phil Buckingham: exactly Jeff . so do we make ALL  auctions public ?  But what happens to the proceeds in that case ? 

jeff neuman: Are there ideas on how we could stop private contention resolution

avri doria: never understood the preventon of partnerships and joint ventures

jeff neuman: The only other option for contention resolution is subjective evaluation.....

avri doria: as a contention resolution mechansim

Jon Nevett: JVs were permitted by the way -- just couldn't replace an applicant with a JV

jeff neuman: @Jon - right....hence why you all created so many new entities

Jon Nevett: "It is understood that applicants may seek to establish joint ventures in their efforts to resolve string contention"

3.4 General Feedback: The GAC submitted an excerpt from the GAC Chair to the ccNSO on 28 September 2016:

-- What about the discussion of IDNs from Work Track 4 about certain IDN rights going to a registry that has an English version of a word?

-- Was there any context with this general feedback?  The overall point is that there are certain IDN characters that could look a lot like ASCII characters.  

-- There was a situation that took a long time to resolve with an IDN ccTLD.  

-- There has been a recent disagreement between the ccNSO and SSAC and there were discussion about ways to get around it.  An agreement has been reached.  We may want to look at that.

>From the chat:

Donna Austin, Neustar: Was there any context to the GAC input? I think the comments are expressly related to IDN ccTLD Policy. What is the EPSRP?

EPSRP?

Steve Chan:  Extended Process Similarity Review Panel, though I can't speak to the substance of the process: https://www.icann.org/resources/pages/epsrp-reports-2014-10-14-en

Cheryl Langdon-Orr: there is some supposed confusability with some scripts lettering. yes Jeff 

jeff neuman: it looked like .br not be

jeff neuman: the cyrillic version of Bulgaria two characters

Alan Greenberg: Yes, it was .br

jeff neuman: I thought it looked more like 6r

Emily Barabas: @Donna, the full text of the GAC comment is here: http://mm.icann.org/pipermail/comments-subsequent-procedures-22mar17/attachments/20170521/3b44e88f/SubProCC2DraftGACResponse22May2017.pdf

jeff neuman: https://www.icann.org/en/system/files/files/epsrp-bulgaria-30sep14-en.pdf

Donna Austin, Neustar: thanks Alan, so its a decision relating to confusability that may be relevant/applicable to our discussions.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/gnso-newgtld-wg-wt3/attachments/20171010/20f0d412/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: CC2 Themes  Work Track 3 - String Similarity.pdf
Type: application/pdf
Size: 80508 bytes
Desc: not available
URL: <http://mm.icann.org/pipermail/gnso-newgtld-wg-wt3/attachments/20171010/20f0d412/CC2ThemesWorkTrack3-StringSimilarity-0001.pdf>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4630 bytes
Desc: not available
URL: <http://mm.icann.org/pipermail/gnso-newgtld-wg-wt3/attachments/20171010/20f0d412/smime-0001.p7s>