Please review ICANN Expected Standards of Behavior here: https://www.icann.org/resources/pages/expected-standards-2016-06-28-en

Good morning everyone

@Jeff - haha, I mean congratulations!

continuing in the role yes

the leadership column just Jeff and CLO? or did it involved others?

@Jim we plan to run the proposed comments to the columns through the future Leadership Team Meetings held weekly and now extended to allow 90 mins of time to do so * Triage*

Nothing to do, but put on a smile and slog through it.

nope

I think well covered

Correct! Link here: https://docs.google.com/spreadsheets/d/11HrbnRk2Sf5FvdOuynJyXfkLrzQAD1jkYpRyaAE1ctI/edit#gid=1688811020

Sorry for being late.

NP @Alan

That makes sense Jeff

+1 Alan. Exactly

until its sold.

@Jim, not if the answer form part of the contract.

Obligations on intended use should remain with transfer / sale of TLD

@Jim, is the assumption you can change the intent if the TLD is sold at some point?

@Jim - Apple could get a private agreement that follows to any assignee. That is one of the benefit of ICANN not being in the middle of all of the disputes.

but does it? We've already had .brands selling and the TLDs being repurposed so I wonder if that does hold true

@Jim - what private agreements have been violated?

Sorry, I can't help on this one.

How are you going to prevent that?

If you are relying on "intended use" and that use changes, doesn't change the initial determination?

@Jeff - doesn't #2 handle #3? Why would there be any need to file both?

@Jim - under the scenario, Apple Growers file for .apples and confirm computer/phone sales out of scope of intended use. Apple reaches out to Growers, gets a written undertaking that the scope won't change and that the obligations follows to any assignee. Problem solved by private resolution. No need for ICANN to enforce anything. Apple can if there is a breach.

@Jeff - that belt with our suspenders makes sense.

@Paul/Jim: is it the case that the RA will include a clause that states the 'intent of use' for the TLD?

I think we should be cautious in casting potentially in contention applications aside

Will not proceed status had a specific definition. They can be in Will Not Proceed from a program perspective and still be in CEP

@Donna - I'm not sure. Seems like a representation in the application would be sufficient to alert an interested party to reach out and do a private settlement deal which could be enforced privately without including ICANN.

The applicant clearly does not have the ultimate say....

@Paul, at what point in the process are you referring? Is it prior to contracting?

@Donna - yes. It would be an application question with a public answer made public on reveal day so that third parties can react (either by filing an objection or reaching a private resolution).

I think there are such a small number of applications affected by this, that we should not spend a lot of time on this. I am not sure we can determine how the the process for settling the dispute can be settled by us

@Paul--thanks for the clarification.

For reference, application status definitions used are here: https://newgtlds.icann.org/en/applicants/advisories/application-contention-set-14mar14-en

Is there an expectation from ICANN that we will change our language so it is consistent with the ICANN use of the terms?

I agree with Alan.

And it may enhance our product.

I'm worried that we don't have time to rewrite all our work. This distinction would have been nice to have in hand 4 years ago...

@Paul. Indeed!

yup

Generically, a procedure is a prescribed way of undertaking a part of a process. Process is "what," while procedure is "how."

I'd prefer that we sort this out now rather than having it up for debate during the IRT.

+1 Donna

Policy vs. Implementation, Part Deux!!

Can we ask Karen if this is a significant issue?

From a def"n:

• A process is about what we doand• A procedure is about how we do something.

We can do a word search....

It then goes on to say that it is not that simple...

@Jeff, yes but this blanket statements worries me

Fine with your opinion.

The process has to be expressed with enough detail so that the procedures can be developed without ambiguity.

But not so much detail that it describes the procedure....

@Greg, no, I think whatever procedures that needs to go into the AGB should go into the AGB -- what Jeff said.

Justine, I agree with you (and Jeff) -- even if the generic process vs. procedure definition might indicate otherwise.

@Paul, isn't RPM PDP a review?

But, what kind of review is the question? Is it the process, is it the decisions; what would be the purpose of the review, to review efficiency, to review decisions?

Correct, it’s captured in the CPIF

CPIF = Consensus Policy Implement Framework

@Jeff - all of that is very helpful

We could say review is desirable and make it subject to the CPIF?

The Transfer Policy Issue Report is as a result of Policy Status Review, conducted by ICANN org. Which was then followed by an GNSO Council scoping team to review that status report.

I almost agree with Alan - I think any review should be while rounds are going, not "before" a round in going. It shouldn't stop the ongoing process, or else we will have another 10 years between rounds.

The CSC has had two reviews: one of the charter; and one related to its efficiency. These were lean reviews conducted by a small team for both efforts. If the Council does have 'control' of the SPIRT then a small group of councilors could undertake a focused review to be done in a reasonably short timeframe.

Lean and focused review is a great point, @Donna.

All, you may want to consider whether the framework should also be reviewed, not just the SPIRT?

Nope

We need to distinguish from the "big" Reviews, that take years to complete....

+1 Steve, SPIRT and Predictability Framework

Should be separate reviews.

They could be interconnected though

Ugh.

Oy.

Exactly @Paul

x2

A Goldilocks review

They could be two phases of a review process, procedurally.

+1 Jeff.

Is this framework/SPIRT better at predictability than what we had before?

An exhaustive review is not "lean," methinks.

if you look at the NCSG comment: should be annually reviewed by the GNSO Council for compliance with the rules the WG has sought to create.

@Paul, that's unpredictable.

Take precedent in the event of a conflict?

@Jeff - makes sens

sense

yep!

@Alan - right. This is just making all of that clear.

Don't know about same mind: just as equally confused as Alan.

topic 2

Oops, sorry, wrong screen

Topic 2 right back at you Steve. :-)

Awww, thanks Paul!

@Jeff, if we kick this to the IRT then whatever the IRT comes up with will be still subject to comment, right?

Yes, usually IRT posts for public comment

I think it would be. We commented the heck out of all of the implementation work from the last round.

Good practive = does

looking

Yhx @Kareen

@Jeff - should we brainstorm qualifications on the list?

CPIF: GDD staff, in consultation with the IRT (if applicable), will determine whether the proposed implementation should be posted for public comment (there is a strong presumption that items will be posted for public comment). If so, the proposed consensus policy language and/or details of the new service as well as the implementation plan will be posted for public comment.

Hmmm.

Sounds like folks want to spell things out. I personally would be happy to punt to the IRT, but I think I am in the minority.

Agree Jeff. Lots of points of entry for the GAC without reopening this up.

And delay too, @Donna, I suppose

@Donna, GAC will never agree to give up the second bite at the apple, which is why we shouldn't set them up as a funnel into the SPIRT and result in folks lobbying the GAC

Time check

would it have to be consensus in going to SPirit? or could sub groups of GAC members petition the SPIRT

Treat all AC's the same IMO

It is going to get out of control and all predictability we hoped for will be gone

Not necessarily Paul.

I agree Alan, about GAC advice.

Where we need to be clear is the parameters or scope of what falls within the purview of the SPIRT.

Thanks everyone! more on the list please.... until next meeting Thursday, 29 October 2020 at 15:00 UTC for 90 minutes.

GAC Issue Statement?

The next New gTLD Subsequent Procedures Working Group call is scheduled on Thursday, 29 October 2020 at 15:00 UTC for 90 minutes.

Yes we should allow it provided it falls within the purview/scope of the SPIRT.

I think we do need to go over the Org comments.

and treat *all* AC's the same ;-)

See you all on the slippery slope on the list. :-)

Chat later all, thanks.