Welcome to the New gTLD Subsequent Procedures Working Group call on Thursday, 26 March 2020 at 03:00 UTC.

Red-line is here: https://docs.google.com/document/d/1xXu7gPKiblS3Vh4MCuK6NWfeRmMolXf9VF5sO7OG4VE/edit?usp=sharing

And the clean PDF is here

Don’t worry, just sharing both for completeness Jeff!

its too late now but id suggest that if we're to discuss scheduling and other working methods for the WG, those should be at the beginning of a call as opposed to being in AOB. especially if proposed by one of the co-chairs. Probably should be included as part of the agenda when circulated. thx

WHy @Jim? it is informational for next meetings o=panning But I am easy either way

planing

Could staff pull up the rationale for Kristine's / RySG's opposition?

@clo co-chairs set the agenda and determine the pace of the meetings and how they run. Not something that occurs on the fly. So those issues that Jeff mentioned are known ahead of time. I usually look at AOB as something on the fly or from the members of the WG.

+1

does sound better

+1 Donna - having financially dependent registries puts registrants at risk.

FYI, the language in the Initial Report was: 2.5.4.c.7: Additionally, financial support should go beyond the application fee, such as including application writing fees, related attorney fees, and ICANN registry-level fees.

i

agree with Donna and Paul

But this support also gives such a registry a warranted, better chance in succeeding.

I sort of recall this being discussed at the subteam level too and agree with what Cheryl is saying.

How so Justine?

@Justine, here is the RySG comment about support beyond financial: The RySG believes that ICANN's support should be limited to financial support for the application fee. Further involvement in the operational, technical and business aspects of a registry/registrar will only serve to unnecessarily involve ICANN in the operations of a registry/registrar and will serve as a de facto endorsement of certain registries/registrars and set a negative precedent for future entities that want to enter the registry/registrar business.

I think there is a huge conceptual difference between Applicant support and this new proposed category of Registry support.

has ICANN ever agreed to fee reductions?

It was in thos consider adding it'conversations as a possible startup period issue as well, but did not emolliate the sustainability issues

In fairness we should go back and have a look the level of "support" and "opposition" to this question from the public comments.

it is stability and sustainability that counts ans YES @Jeff we did also ocinsider probono or inkind services here in earlier discussion

I absolutely agree with Jeff.

“Applicant Support” should not be confused with “Registry Support.”

Link referenced by Jeff: https://newgtlds.icann.org/en/applicants/candidate-support/non-financial-support

The matters of sustainability and security *is * of course a concern @Paul The In-Kind Support is a key factor here

3rd parties @Paul

But ICANN should also have an interest in ASP registries succeeding beyond the application process.

My concern here is for registrants who may invest in second level domain names and then get EBERO'd and eventually lose their SLDs.

That is (Ihope) well understood @Paul, and certainly *was* considered even right back in the original JAS-WG report

But ASP registries should be an exceptional group. I understand the concerns against. In a spirit of compromise would folks in opposition find the suggestion of limiting this support to a SPECIFIED period amenable?

NTAG could be viewed as a source of non financial support. (new gTLD applicant Group) I don't belive there was a fee to join

The revenue doesn’t start until the TLD is delegated + x months

noted @Jim

Greg not always—“pioneer programs “ can happen after contract signing

Applicant support should end at contracting.

ICANN is in the business of providing opportunity not guaranteeing success....

@Elaine - many pioneer programs were non-fee based

@jim, I don't believe anyone can guarantee success, including ICANN.

No one can guarantee success, but hopefully quite a number of people can forecast a reasonable probability of success or failure.

Thank you @Jeff, exactly my point about going back to the public comments received.

In light of the public comment on the Initial Report and prior work of the Subgroup, you are right Jeff - we have to ask the question and summarize prior comments and prior subgroup work.

We can get the EIU to decide which registries get ongoing support. That’ll work....

Call it out one way or the other

The opposite could also be true @greg

i think my real concern is the 'ongoing' . Maybe i could live with a waiver of fees for the first year of operation, but that's a personal rather than RySG perspective.

that may trigger the data points of support or otherwise that we would need to then consider

c.6 and c.7 are both related I believe.

It would help to hear (persuasive) justifications for ongoing support as a concept.

understood @Greg

Rather than justifications based on the process of staying in or out.

that I believe is where we are now tring to head

Comment analysis here: https://docs.google.com/spreadsheets/d/133WbhWYB4M4kT6DqSfiCR2-ij7jxNkLj5EWZL-NA95M/edit#gid=1627799531

Thx @STve I was hoping you would find that link

This says to e we need to call this out

I support the language as is

so perhaps we can remove the brackets?

yes - support it

Yes, I support keeping the bracketed language.

@Jeff, @Steve, @Emily, could you remind us when is the start of the Communication Period?

Thanks

It’s something to the effect of at least 4 months, or as commensurate with the requirements of the program…based on my poor memory at least.

perhaps we need to have a flow chart diagram for communications and outreach and link to it here as well

What's a middle applicant?

Are there any boundaries on that? Or is it self-identified?

@Jeff, thanks. I look at the deliberations section.

I'll

@Steve, please (re-)confirm through notes of this call.+1 Cheryl, for a flowchart.

Does that encourage inflated application fees?

Doesn't ICANN dictate the fee?

PAul, can you elaborate?

That is my personal assumption as well @Jeff

@Paul, my thought, no.

We should all monitor this.

Exactly, @Jeff

Thanks Jeff. Not trying to cause trouble, but want to make sure we do create all kinds of pots of discretionary money (we already have that as a result of auctions).

we do not create

@Paul, I call asking for a safeguard regarding fee excess -- that it must not be used for anything outside the program.

@jeff, on the issue of thinking about a mechanism to handle "over demand" on ASP funds, even if we do not come up with a recommendation, could we suggest that IRT consider this somehow?

I'd rather have us say something rather than be silent. Yes, IG would be good if no one objects.

Time for our AOB

But were also not trying to help people plan better (especially with time zone rotation)

Yes NOT *all of them!*

this shows us less need for that

Thanks for considering the time zones, Cheryl

so just a couple of 2 hrs ones as @Jeff is outlining

Jeff - where in the work plan do you anticipate consensus calls?

Dec at this stage

but YOU can all see the space avaioable that we 8Can* use

in a perfect world (don't jinx things @Jeff!*

Looking forward to receiving this updated workplan through the mail list.

and it will be more than the 5 days currently in the plan?

aspirational only !

but yes we should pitch to that pre ICANN 69 :-)

@Staff, could you scroll up so that I can see the rest of March please?

@Paul, sure, and here’s the link: https://docs.google.com/spreadsheets/d/1SN8GX1nVER30p_VmX1fAEJUTRLByXhrI96kpdGw8VYk/edit#gid=839727774

Thanks!!

Will finalizing GAC Consensus Advice be put back on the calendar? My small drafting team on that is getting underway soon.

exactly!

Thanks!

:ots done indeed!

Next call: Monday, 30 March 2020 at 15:00 UTC for 90 minutes.

can you circulate some background fr people o the ccTLD process ahead of the call?

thx

Thanks everyone Bye for now...

thanks, bye, be well.

Good work, Jeff, keeping us all on schedule

Bye all