You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 2 Current »

The call for the New gTLD Subsequent Procedures Sub Team – Track 4 – IDNs/Technical & Operations will take place on Wednesday 14 December 2016 at 20:00 UTC. 

12:00 PST, 15:00 EST, 20:00 London, 21:00 CET 

For other times: http://tinyurl.com/hsjzcqf 

Proposed Agenda:

1.     Welcome
2.     SOIs
3.     Hyderabad recap
4.     Consensus call 1: Technical capability to be assessed at contract signing time
5.     Discussion: Technical evaluation of applications to be performed as aggregated as feasible
5.     Discussion: Timing and method for Financial Evaluation

Mp3

AC Chat

Attendance

Apologies: 

Dial outs: Cheryl Langdon-Orr

On audio only: none

Notes/Actions:

1.  Hyderabad recap [slide 5 of the slide deck]

-- Support for IDN 1-character was pictogram (Japanese or Korean), but opposition was not to Latin and Cyrillic, but use a more generic term.

-- Probably would be good to use generic terms for all of them.

-- Only those that represent 1 word.

-- On support for IDN Variant TLDS -- Staff have had preliminary discussions with Sarmad Hussain on staff.  He could provide background or a status update on the program.

From the Chat:

avri doria: idoegraphic cs. non ideographic

2.  Consensus call 1: Technical capability to be assessed at contract signing time [slide 7 in the slide deck]

Possible language: "Applicants must be able to demonstrate their technical capability to run a registry operation for the purpose that the applicant sets out, but will only be required to do so at contract-signing time, after passing other criteria and/or approvals and prevailing in contention set(s), [if any]."

-- If we do a consensus call over email should have the full story documented and presented to be taken into account.

-- Today's discussion is just a temperature taking, not a consensus call.

-- Explaining why the change is being made is important.  Good to lay out those conditions, which will help this make sense.

-- The financial model and testing the technical model are two different things.

From the chat:

avri doria: might want to consider adding ", if any" at the end of the stmt.

Cheryl Langdon-Orr (CLO): good point Avri

avri doria: i think we need two reading, both on calls to close a consensus call.

Cheryl Langdon-Orr (CLO): yes the rationale is important on this proposed recommendation

Phil Buckingham: this is a catch 22 , since the technical costs/ so contractual relationship with the backend provider  will need be incurred and  the costs put in the financial model for evaluation.

Cheryl Langdon-Orr (CLO): thx Avri

3. Discussion: Technical evaluation of applications to be performed as aggregated as feasible [slide 9 from the slide deck]

-- During the evaluation process there wasn't a realization of how the market would evolve with respect to backend providers .

-- It was thought at the outset that individual applications needed to be evaluated in the absense of knowing that the backend marketplace would be established.  Things didn't work out as predicted.

From the Chat:

Steve Chan: If I recall, part of why every application was considered indivudually overall was related to principles of fairness? Kurt would probably be able to fact check that statement.

Phil Buckingham: Totally agree Kurt. and nobody knew who was going to apply , how many portfolio players  would submit multiple applications using the same mode

4. Discussion: Timing and method for Financial Evaluation [slide 10 from the slide deck]

-- Could have speculative applications.  The financial models are going to vary even more if the price goes down.

-- Look at the program implementation report that staff produced.  There were inefficiencies from treating every application individually.

From the chat:

Phil Buckingham: the financial model was templated / standardised .  It wont work for Round 2 . Each applicant's  financial model needs to treat separately , evaluated , due diligence accordingly  Agreed Alan . Alot more .

Steve Chan: @Rubens, I tried to note that the report acknowledges those challenges to some degree, but apparently i made that point ineffectively.  So not just about inefficiency...


 

  • No labels