Page History

Notes/ Action Items

ACTIONS & NOTES:

Actions:

2.6.1.e.2: Line 47, NCSG -- ACTION ITEM: Ask them for clarification as to what data supports their statement.  We have no data the supports a subjective statement. 

Notes:

1.  Update SOI’s: No updates provided.

2.  Discussion of Public Comment on:

a.  2.5.4 – Applicant Support (line 97)

2.5.4.e.6:

Line 99, ALAC -- New Idea: The ALAC suggests that resources be applied to systematically identify and address barriers to applications.

Line 100, Business Constituency -- New Idea: Fostering discussion hubs composed by regional players in which collective strategies can be devised and common concerns gathered.

Line 101, LEMERIT -- New Idea: Creating mailing lists and webinars could be useful.

Line 102, RySG -- New Idea/Concerns: n the 2012 round the ASP was rushed and not well publicized so those that may have benefited from the ASP may have been unable to take part due to time constraints or a lack of knowledge about ICANN and gTLDs in general.

2.5.4.e.7:

Line 104, ALAC -- New Idea

Line 105, RySG -- New Idea/Concerns: t's more likely that attempting to set up a system to root out "gaming" will create additional accountability problems for ICANN and increase the costs of the New gTLD Program.

Line 106, ICANN Org -- New Ideas/Concerns: 2.5.4.e.7 re:  pmt;  2.5.4.e.10 on costs; from 2.5.4.c.3 -- Implications of potential increase in volume in AS - bring to full WG 

2.5.4.e.8:

Line 108, ALAC -- New Idea: On this basis, we propose that an applicant who qualifies for ASP should be given priority in any string contention set, and not be subjected to any further string contention resolution process.

Line 109, Neustar -- New Idea: Consideration could be given to allowing ASP applicants the opportunity to change their string to avoid the contention set; the new string would need to be similar in meaning to the original applied-for string.

Line 110, RySG -- New Idea: The Initial Report discussed the WT's ideas about better outreach to find partners and help for ASP applicants throughout the process, and the RySG believes the WG should recommend that ICANN cultivate a list of resources, organizations, or agencies that would be willing to assist the applicant.

-- Refer to Auctions - in another SG - find section #

From the chat:

Kristine Dorrain: To be clear, the RYSG understood that the list of resources was part of the initial report...we didn't think we were creating anything new there.... 

Line 111, GAC -- Concerns: Auctions of last resort should not be used to resolve contention between commercial and non-commercial applications. As to private auctions, incentives should be created to strongly disincentivise that instrument.

-- Refer to Auctions - in another SG - find section # 

2.5.4.e.9:

Lines 113, 114, 115 -- ALAC, LEMARIT, NCSG

Line 114, LEMARIT -- New Idea: Only if applications just from the category geographic TLDs can be submitted during this specific round.

Line 115, Business Constituency -- Divergence: No

Line 116, RySG -- Divergence: No. RySG opposes this option, considering it would be easily gamed to make applications not really from those countries get preferrence in that round over applicants unwilling to make false representations.

2.5.4.e.10:

Line 119, ALAC -- Agreement/ New Idea: Possible sources of funding for the ASP are (1) the excess application/evaluation fees generated from the 2012 round, and (2) proceeds from the auctions undertaken to resolve contention sets from the 2012 round.

Line 120, RySG -- New Idea/Divergence: The funding for the ASP should be one of the costs included in building the "revenue neutral" budget for the next round. The cost should be reincorporated into the "revenue neutral" budget for subsequent application opportunities rather than rolling over excess funds from one round to pay for the ASP program in a subsequent round.

Line 121, Neustar -- [Does not appear to address the funding aspect, or where the funding should come from]

Line 122, RrSG -- Comment: The RrSG would like to better understand how the Applicant Support Program is funded, or more specifically, where the money comes from for the reduced fee? Added to 2.5.4.e.10; from 2.5.4 #6 

From the chat:

Rubens Kuhl: I think the RrSG could be called a concern ? 

2.5.4.e.11:

Line 124, ALAC -- Agreement 

Line 125, Jamie Baxter of dotgay LLC -- New Idea: Outreach may also look to include information/education that extends beyond just the application process and timelines, with focus on case studies that can help inspire innovation and creativity within populations, initiatives, communities and sectors that may not see a common or productive link to new gTLDs.

Line 126, RySG -- Divergence: ICANN should not single a group out for special treatment without more data.

From the chat:

Justine Chew: Line 126: How would we find data if there is none?

Justine Chew: Or what sort of data RySg referring to?

Kristine Dorrain: @Justine, I think we just don't want the PDP assuming only certain groups were in need. 

Kristine Dorrain: I mean we "think" the Global South, but who else/

Kristine Dorrain: We shouldn't assume we know who should qualify without more info.

Kristine Dorrain: Does that make sense?

Rubens Kuhl: I don't think the initial report has much guidance on that.

Discussion:

-- On applicant support -- what is the full WG thinking about as a next step?  Answer: Next steps could look at what the JAS WG was recommending and the implementation suggestions on how to manage and review. 

b.  2.6.1 – Application Queuing 

2.6.1.c.1:  Summary -- all commenters agreed. 

2.6.1.c.2: Summary -- all commenters agreed.

2.6.1.c.3:

Lines 15, 16,17 -- Business Constituency, Brand Registry Group, RySG -- Agreement

Line 18, ALAC -- Agreement/Concern: The ALAC does not object to the continued use of a system of buying a ticket to participate in a prioritization draw method provided always that the cost of ticket is not prohibitive to some applicants, for example those which apply for Applicant Support. 

Line 19, Mark Monitor - Divergence (support for alternative method, one that was referenced in the report): ICANN should re-deploy random prioritization for applications in the next round. 

2.6.1.c.4:

Lines 21-24, Brand Registry Group, Business Constituency, NCSG, RySG -- Agreement. 

Line 25, ICANN Org -- Concerns (as well as suggested considerations).  Raise with the full WG.

From the chat:

Jeff Neuman (Overall Co-chair): Good notes from ICANN Org.  Definiting Portfolio applicants shouldnt be too tough. but the gaming comment is interestes about a secondary market

Kristine Dorrain: ICANN org has good questions...

Justine Chew: Agree. Good questions from ICANN ORg

vanda scartezini: ICANN comments need responses , quite relevant to clarify thoses

Line 26, Mark Monitor -- Divergence: o avoid applicants gaming the system, priority determinations should be non-transferrable among applications.

Line 27, Alexander Schubert -- Divergence: So NO: There is no cherry picking in the queueing process within several applications from one applicant. 

Line 28, RrSG -- Divergence: On the topic of randomized draw, any Applicant with an application in a contention set should not be permitted to reassign a draw number to that contention set application.  Additionally, where a parent company has multiple companies in play during a draw, assignment of numbers between affiliated companies should not be permissible. 

2.6.1.c.5:

Lines 30-33, ALAC, Brand Registry Group, Business Constituency, RySG -- Agreement. 

2.6.1.c.6:

Lines 35, 36, 37, ALAC, Brand Registry Group, Business Constituency -- Agreement

Lines 38 and 39, INTA, Valideus -- Agreement/New Idea.

Line 40, ICANN Org -- Concerns (or rather, request for clarity and suggested considerations). 

-- Add that to the related topic of what it means to have closure.

2.6.1.e.1:

Line 42, RrSG -- New Idea: The RrSG believes ICANN should transition to first-come, first-served by allowing Spec. 13 Brands to proceed on this basis immediately. Spec. 13 Brands should not need to wait for rounds and this would allow ICANN staff to initiate the shift to a first-come, first-serve process more seamlessly after the next application window.

Line 43, NCSG -- Divergence: we believe there must not be a first-come, first-served process, and the SubPro WG early in this report already said that it favors clear, specific, and designated rounds for new gTLDs. 

Line 44, ALAC -- Please refer to our response to Preliminary Recommendation 2.2.3. (Opposition to FCFS). 

From the chat:

Jeff Neuman (Overall Co-chair): No one really answered this question.

Jeff Neuman (Overall Co-chair): 2.6.1.e.1

Jeff Neuman (Overall Co-chair): they just reierated their support or objection to FCFS 

2.6.1.e.2:

New Line 46 (added), ALAC: Agreement: Yes, the ALAC believes that IDNs and community-based string applications should receive priority in processing.

Line 47, Public Interest Registry -- Agreement

Line 48, NCSG -- Agreement Concerns (or rather, suggestion that PDP WG should have done data collection).

-- ACTION: Ask them for clarification as to what data supports their statement.  We have no data the supports a subjective statement.

Line 49, RrSG -- Divergence: The RrSG does not believe that IDNs should get priority in the next round.

Line 50, Neustar -- Divergence: IDNs should not receive priority processing in subsequent evaluation procedures.

Line 51, LEMARIT -- Divergence: No, prioritization of IDN applications is not necessary.

From the chat:

Justine Chew: @Steve,  I think ALAC's comment in missing for Q 2.6.1..e.2 

2.6.1.e.3:

Line 53, NCSG -- Agreement (as in, agrees that FCFS is undesirable): With regards to question 2.6.1.e.3 the NCSG does not agree with the idea of reintroducing first-come, first-served processing

Line 54, RrSG -- New Idea: The RrSG encourages ICANN to utilize or create a randomized system that excludes the "show" that accompanied the last drawing. 

Line 55, Alexander Schubert -- New Idea: Any entity that doesn't wish speedy processing would indicate already at submission of the application.:

*Any entity that doesn't wish speedy processing would indicate already at submission of the application.  

*  Every application will receive a random (many digit long) "queueing number" assigned by the application system (yes: computers can create RANDOM numbers, since decades already) 

*  The applications are then queued by these numbers  

2.6.1.e.4:

Line 57, ALAC -- Agreement (to prioritize community-based).

Line 58, NCSG -- Agreement (to prioritize IDNs).

Line 59, Jamie Baxter, dotgay LLC -- Agreement (to prioritize community-based) New Idea (to prioritize the entire contention set with a community-based applications).

Line 60, Brand Registry Group -- Smaller, more targeted rounds?

Line 61, RrSG -- Agreement (to prioritize Brands) New Idea.

Line 62, Neustar -- Please refer to Neustar’s comments above in 2.2.3 Applications Assessed in Rounds.

Line 63, RySG -- Divergence: RySG believes the default position should be to avoid prioritization of particular categories over others.

Line 64, Alexander Schubert -- Concerns: CAUTION with statements like "those from the Global South should be prioritized". In other words if portfolio applicants use "global south" tax havens (like Seychelles) instead of the Caribbean: they get prioritized? We live in a globalized world: the applicant entities can be positioned ANYWHERE on the globe! 

Other Comments:

Line 66, RySG -- Moved to 2.6.1.c.4.

Line 67, Alexander Schubert -- Moved to 2.6.1.e.3