[Gnso-newgtld-wg-wt1] Actions/Discussion Notes: Work Track 1 Sub Team Meeting 31 January

Tue Jan 31 21:10:50 UTC 2017

Dear Sub Team Members,

Please see below the action items and discussion notes captured by staff from the meeting on 31 January.  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+1+Meetings.

Please note also that the slides referenced below are attached and for ease of reference chat excerpts are included below.

Best,

Julie

Julie Hedlund, Policy Director

Notes and Action Items 31 January

1. Recap of outcomes from Jan 10th call

a.  Application Queuing (slide 4)

-- "Lottery" was the way to go.  

-- In the last round in 2012 there was a decision by the Board to prioritize IDN applications (randomized them first).  Then randomized the non-IDN application.  If you wanted to enter the randomization process you paid a fee.  Then randomized those that didn't want to be in the "lottery".  Should talk about whether there should be some priority on IDNs this time or not.

-- Question: IDNs were prioritized to facilitate their entrance in the market -- correct?  Yes.  There was a political desire to have IDNs introduced in the market first.

-- CC2 draft question -- whether or not certain application types should be moved to the front of the queue.

-- What might help that we do have information that could be useful as to whether putting IDNs first was worthwhile -- gather some data on whether those applications who received prioritizatioin took advantage of that.

-- No feedback/objections on the "lottery" ("raffle") approach.

-- No insight/feedback on further discussion questions.  Will recirculate.

>From the Chat: 

Jeff Neuman: We can call it "Randomization Process" for now. 

Kurt Pritz: ICANN called it a "raffle" for important reasons. I think we should adopt that wording if we are indicating that we want to recommend the same process.

b.  Application Submission Period (slide 5)

-- We should talk about the communication period for the first application window as opposed to subsequent communication periods.  Would assume that would be longer and for subsequent ones if there is some sort of regular process (from the drafting team on overarching issues) -- such as 2 windows a year -- that may overlap with other things going on.  Push that off until we get some work product from the drafting team.

-- Also ties into a couple of other topics.

>From the Chat:

Donna Austin, Neustar: Agree with Jeff, that there is a distinction in communication between the first v subsequent window application/

Jim Prendergast: yes - agreed

c.  Application Fees/Variable Fees (Slides 6 and 7)

-- As we move these processes we probably need to have a few fundamental conversations, such as around categories.  Where we end up might influence this conversation and in the legal/regulatory track.

-- Not sure agree that there will be differences in time and effort for different applications, but can't know that without doing the research.  What you need to factor in is what you are applying for is unique and has cost associations.

-- Not sure that we should give any weight to the fact that applicants in the last round paid $185k.  Decide on the core methodology -- cost recovery or cost recovery+.

-- We could get agreement from the group that a registry backend provider would only get evaluated once, which could eliminate the technical evaluation from every other application.

-- Efficiencies could be gained in a bunch of the processes.

>From the chat:

Jim Prendergast: When does cost recovery from previous round stop and cost recovery for this next procedure/round start?

Phil Buckingham: +1 Donna ,   so we have two application fee elements ? a fixed price + variable cost plus   ?  

Jon Nevett: No weight?

Jeff Neuman: Correct, I dont think what groups paid in the first round should have any weight. It didnt have any weight in the 2005 round or the 2012 round.

Jon Nevett: cause it went up.

Donna Austin, Neustar: I think the same applies with regard to what financial information is required, ie. if there is no requirement for a COI.

Jeff Neuman: Technically the first TLDs paid nothing.......but the 2000 round did not argue for parity

Jim Prendergast: I think we need to ask ICANN why they insisted on evaluating RSP over and over and see if those reasons still stand.  We can make all the arguments we want but if ICANN legal says that we did it for liablity prevention reasons, I don think our outcome whill change that.

Jeff Neuman: @Jim - if you read the implementation plan, they did not indicate that they did that for any liability reasons.

Jon Nevett: Agree with Donna that the $185K should have some weight.

Jeff Neuman: In fact, I believe their input was the opposite...sorry I meant the ICANN Implementation review.

Kurt Pritz: One way to think about it: if the cost is $20K, do we agree with cost recovery; if the cost is $50K do we agree with cost recovery; if the cost is $100K do we agree with cost recovery?

d. Invoice Challenges (Slide 7):

-- Do we agree that there should be an invoicing system?  

-- ICANN had challenges on the ability to invoice, which caused some issues for some applicants.  

>From the chat: 

Jeff Neuman: I think all we are saying is that we agree that there should be an invoicing process when applying for TLDs. As opposed to having to get in the money a few weeks before or whatever the process was.  Many big companies have rules that they can only pay after receiving a valid invoice.

Steve Chan: Or make it available on request? I recall, maybe incorrectly, someone saying that having an invoice is actually problematic?

Yasmin Omer - Amazon Registry Services: Applicants that needed a statement/invoice (generally larger companies and governments) had to request such from ICANN for the 185k and ICANN eventually provided something.

2. Systems (Slide 9)

Our task:  WG may want to consider providing implementation guidance, such as a minimum set of security and infrastructure standards, for consideration by ICANN during implementation of subsequent procedures (https://community.icann.org/display/NGSPP/4.2.9+Systems?preview=/58735915/58737114/Section%204.2.9.pdf ).

-- Context (from the Issue Report): No guidance in the 2007 final report, so this is a new topic.  We are talking about applicant-facing systems: (from slide 9)  TLD 

application System (TAS), Customer Portal, additional support solutions -- Digital Archery, Centralized Zone Data Service, Application Comments Forum.  See: https://www.icann.org/en/system/files/files/program-review-29jan16-en.pdf.

-- Take into consideration that we have moved on quite a bit from this.  The best we can do is some high-level recommendations that go to a better user experience.

-- If we get the summary from staff and agree that would be a good thing.

-- We need to balance that with the needs of those that have to evaluate the applications at the end of the day.

>From the chat:

Jeff Neuman: all of these topics were referred to us by the GNSO whether considered policy or implementation.  IF we want to provide guidance, we should.....if not, that is fine too.  The systems issue is not really policy either, but more implementation...but it is part of the subsequent procedures

Jon Nevett: if get into that level of detail on every issue, 2020 will be optimistic

Jeff Neuman: I am not sure we are getting too deep.  We are just recommending that an invoicing process be made available.

Jon Nevett: Systems should be safe and secure -- avoiding glitches and data breaches that we have had in the past.

Jeff Neuman: For systems, we may recommend better usability........ability to copy applications....ability to do non-ASCII.

Jon Nevett: ok and better user experience.

Jeff Neuman: Perhaps for the next call, we can summarize the ICANN staff recommendations...and if they make sense, just sign off on them

Donna Austin, Neustar 2: The recommendations on this should be high level and not in the weeds.

Phil Buckingham: we require changes to the CZDS . For starters -  not to  have to reapply every 90 days to every single Registry  ! 

Jeff Neuman: @Phil...I am not sure that CZDS falls within our mandate.   The requirement to provide a zone file as a requirement would be, but not sure that that system is for us.

Phil Buckingham: @ jeff , I agree CZDS is outside our mandate , but Registry reporting  of  their zone file data is  ?

3. Communications (Slide 10)

Our task: Consider suggesting targeted groups or sectors, communication methods, as well as metrics to help identify if the communications plan was effective.  A PDP-WG may also want to consider what themes should be conveyed and to what parties, as it may be beneficial to customize messaging based on the needs of the particular demeographic…consider providing implementation guidance related to communication methods, goals for communications, success criteria and other elements. (https://community.icann.org/display/NGSPP/4.2.11+Communications?preview=/58735919/58737118/Section%204.2.11.pdf).

2011 Communications Plan: See: http://newgtlds.icann.org/en/about/historical- documentation/matrix-plans.  The program implementation review document discusses Communications on pg 189.  https://www.icann.org/en/system/files/files/program-review-29jan16-en.pdf 

-- Concerns: Whether communications were enough, adequate, and timely.  Lack of outreach to developing countries.

-- Could provide guidance on methods, goals, measuring success, groups to target, etc.

-- Touched on having a database that is easily searchable.  Could be part of the applications process discussion.

-- This another area where things improved over time.  Things are now running a lot smoother.  Registry Stakeholder Group had a running dialogue with the GDD.

-- Staff can provide a summary of recommendations on the next call.

-- Agree that after applications were submitted they improved communications.  ICANN posted advisories but not everyone knew to look for them.  Look at a better mechanism, such as a subscription.

>From the Chat:

Jeff Neuman: Agree with Donna on communications after applications were submitted.  But someone needs to go through the application knowledge database and clean that up.

4. Accreditation (Slide 11)

-- Call for volunteers from ICANN.  Not sure there will be a group.  Trying to find out if there is a group and what we should take on.  Will give an update on the next call.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/gnso-newgtld-wg-wt1/attachments/20170131/3ecb4eb1/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: OneDriveSub Pro Track 1Sub Pro Track 1 20170131v4-FINAL.pdf
Type: application/pdf
Size: 742634 bytes
Desc: not available
URL: <http://mm.icann.org/pipermail/gnso-newgtld-wg-wt1/attachments/20170131/3ecb4eb1/OneDriveSubProTrack1SubProTrack120170131v4-FINAL-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-wt1/attachments/20170131/3ecb4eb1/smime-0001.p7s>