Welcome to the New gTLD Subsequent Procedures Working Group call on Thursday, 09 April 2020 at 20:00 UTC.

Hello all

Welcome, Maxim

Hi all

Good Luck!

Thanks Kristine - congrats and good luck!

thanks, it's exciting and sad at the same time!

Good luck Kristine

Are you at liberty to say the new position?

I'm still with Amazon - I'll be doing content policy.

Good luck with your new position, Kristine! We will talk on the NomCom anyway, so I won’t say goodbye

23:00 here

spare a thought for Justine Christopher

Ok just wondered what department you were switching to - sounds ljke heavy respnosibiity!

Well, we will share the unpleasantnies

But is it our finest hour?

we do not switch, and it is 23.07

here

What about Corona Time?

But always at my back I hear time’s winged chariot hurrying near

Winged chariots of fire?

@Greg, it is like submarine, only UTC time

@Cristopher, it is by definition, legal bodies have to obey to local law

and local = place where they established and have HQ

applicable to what?

Yes, to applicable law, not just the applicant's

applicable to where the registrant is based and to where it does busienss

Concept confusion?

Agree with Greg - if we are going to go down this path, Im not sure this is the area to do it. Should be someplace else or a new objection procedure.

I am not sure how to formalize Concept confusion

Standard for String Confusion – String confusion exists wherea string so nearly resembles another visually that it is likely todeceive or cause confusion. For the likelihood of confusionto exist, it must be probable, not merely possible thatconfusion will arise in the mind of the average, reasonableInternet user. Mere association, in the sense that the stringbrings another string to mind, is insufficient to find alikelihood of confusion.

It seems like it is a huge confusion on what kind of confusion we are talking about

I'm empathetic to the plight here, but I'm not sure there is any way to put reasonable guardrails on this.

QUESTION: where are the current rules for GAC on this type of objection -- a Category 1 objection?

@kathy, PICs to apply depending on the string

different regulation in every country for doctors of medicine

@Kathy - this is a new concept. If adopted, then rules would need to be developed. But right now we are just testing the waters to see if this is an avenue the group wants to go down

@Kathy, sorry! I misread your question. Jeff has the correct answer.

happy to wait

@Jeff - I don't feel comfortable this this restriction that is missing many, many guardrails. I think it needs to be much further developed before it is put out for us to approve or disapprove.

@Paul - Perhaps approve/disapprove is too definitive....I just want to see if there is an appetite to work on this further.

Very well put, Kathy

Sensitive String Objection?

Has anyone looked at the morality and public order objection? Is that a better fit?

We’ll miss you Kristine!

(awwww, shucks) Thanks, I'll miss you all too! (Who else would I argue with weekly? - besides my teen)

I am just wondering if "appliying for exemptions" or "negotiating for exemptions" rather than "obtaining exemptions"

would be better

Justine, I think this is a good suggestion

Also to clarify what we mean by "ICANN"

++1 Kristine

You can raise them @Jeff

new hand

and I'll come in if you miss what I mean

I am not convinced that there is ‘rapidly changing marketplace’. Most marketplaces are taking a HIT.

Support ICANN Org clarification

Support "negotiating for"

+1 Paul

+1 Paul

It wasn't included in the Applicant Guidebook

@Kathy, ROs have been trying to deal with the 100 names for 6 years. It's good that RPMs is getting there, but it's a slow process. this suggests something more predictable and structured to solve a problem in the moment.

I support the structure and efficiency method.

Unlimited power to ICANN Org is not clear, structured or efficient.

@Kathy, think of RSEP...Regsitries want to change a service - here is a transparent process.

I do not oppose the intent behind the recommendation but I would advocate for specific mention of ICANN community participation in the process rather than referring just to "ICANN Org".

This could be like that - some part of the contract isn't working for a specific RO - how can we address it?

@ Justine, every RA amendment requires public comment period.

@Krstine, sure I think we should mention that

I think it's already in there somewhere. :)

@Kathy - your point about .brands not being in the guidebook proves the point. Although ICANN knew that .brands were coming down the pike, even if they didn't there still needs to be a method to address changes needed due to new business ideas. ICANN can't insist on stasis while the rest of the world innovates. ICANN needs a method to allow innovation.

Per Justine's comments (and it may not be sufficient), but to move the ball forward: "With Extensive Public Notice and Public Comment."

@Kristine, I mean to mention it here (again)

@Kathy, we probably don't need to add "extensive." If the public doesn't care, they don't comment. If they do, they don't need to be invited to "extensively" comment. LOL

@Justine, it is in RA , search for public comment

in it

@Maxim, I understand, I'm trying to bring attention to this here in attempt to allay concerns of anyone who reads this recommendation.

Oh, got it.

This isn't a change to an application, but to the Registry Agreement.

+1 Jeff, Kristine. I see this a different to Change Request as well.

the whole section is about the base RA

BASE RA

sure

BASE RA for next round

not for current registries

@Kathy, thye might not know yet

they

Add "Base" before "Registry Agreement"

currently there is no such thing, it is just RA

agreed Justine

and with that, I'm off to a conflicting call. It's been a pleasure, folks!

Thanks for joining @Kristine

Don't be a stranger, @Kristine!

keeping my hand up, but I won't duplicate what Martin is saying,just +1 him

It should be difficult...

suggest we replace "requirements of" with "provisions of" or "obligations under"

Noted @Anne

Do we make it unnecessary complicated?

Agree on public comment period

When all registries of 2012 applied there were no restriction for RAA 2013

The issue of vertical integration in relation to registrars is a policy issue, isn't it?

and some local registrars just quit instead of changing RAA 2009 to RAA 2013

@Jeff, correct.

@Jeff, hopefully...

is there a guard against sudden shift to RA 2022 ?

Please add "subject to 30 day public comment"

Karen Lentz has her hand up.

Yes to 30 day; no to pressuring applicants to have to put these in their applications

@Paul, no pressure but encourage should be fine, no?

I agree with Karen - it seems unbounded.

agree with Paul -a known change that an applicant wants to make - it makes sense for them to flag it in the application. But experience shows that things aren't always known at the time of application. We have also built in an expectation of the possibility to amend an agreement to address objections and clearly, on the face of it, this isn't known at application

Why didn’t you just go for <.brand> TLD, in which case the whole of this debate would take place at the Second Level?

JEFF - would it be helpful for us to refer to the Predictability Framework here?

@Paul yes

.FEEDBACK PICDRP

What is the governing law in the RA?

It probably should be a Rep/Warranty in the base contract, perhaps with the ability for third parties to file compliance complaints but not via thr PICDRP

No real governing law

just venue

adding third parties to an RA is the way to mass extortion

Agree with Griffin

The governing law is the law that applies to the parties... California/US law and wherever the registry is located

Although to be clear, if a PICDRP panel found a fraudulent or deceptive practices then ICANN Org needs to be able to do something about it.

@Griffin - right

so maybe add "under applicable law" and let everyone argue about what law applies if there is a problem?

@Griffin, this is the way I interpret it too.

private attorney general is illegal here :)

So the issue here is that Spec 11 already requires ROs to require in their RRAs that registrars prohibit fraudulent and deceptive practices (hence the PIC hook) but such provision was found not to apply to the RO itself

So if "fraudulent and deceptive practices" is specific enough in the existing Spec 11 language it should be specific enough to apply to the RO itself

quite an "adventure" @Greg

@Griffin - Good point....I will bring that up after Greg

And sorry I can't dial in to speak, juggling a few concurrent matters

what ICANN did was almost there - changing RA after accepting payments

Yup, agree with Griffin yet again

@Greg, ha!

Spec 11 Section 3(a) specifically

appreciate that @Griffin glad of all the contributions you can make :-)

Griffin - excellent point

panelists to do jurisdiction shopping is too strong

We can mirror the language already in Spec 11 3(a) which is already bound by applicable law

Just make it clear that the prohibited activities apply to the RO itself, not just downstream

+1 Maxim. "applicable law" without saying what it is provides no certainty

Except it does provide a pretty limited universe of what law applies - that of ICANN and that of the RO

@Jeff - that is a reasonable middle ground.

We did have some recommendations about governing law coming out of the Jurisdiction Subgroup. But of course, it’s not yet the time to implement the work of Work Stream 2. :-(

@Jeff, I agree, a good compromise

example : REgistry = country A, ICANN = US, complaint from country B , which is not A and not US … and panelist suddenly claims that there are laws of country B in power this time

Well then that's a problem of the panelist applying wrong choice of law and should be appealable on that basis

are there any kind of protection from the rouge panelists?

No, but maybe the mauve ones

That is a color joke

:-)

In seriousness, I'm not sure off top of head what the appeal mechanism would be, say in a PICDRP...ICANN Complaints Office perhaps?

Would need to look into that

Griffin, was that an off-color joke?

on- and off-color

Not surprising from the governmental side, Jeff. They need time.

it is a weird way to address GNSO PDP, should be done via the GNSO Council

extension of the current timeline might lead to a termination of a PDP , and is extremely dangerous

QUESTION: What does the GAC mean by its reference to the need for "discussion at ICANN68"?

we do can not prevent GAC from having a discussion

Anne I believe they were planning on furthering their work at the next meeting

@Anne - i think it means they expected to react to this in their Communique from that meeting

to arrange timly input

@Christopher — Jeff has posted the letter to the list.

we have not been there

We launch them in 2 to 3 years

@Alexander, announcing is not equal to launching

Maybe the concern arises from "having draft final report ready by ICANN 68" being obscured by the "public comment period being 23 July to 1 Septermber (with possible extension)"? We are not bringing forward the public comment period are we?

@Justine - Yes we would

Kuiala Lumpur will not be a F2F meeting, so that is what we have to plan for

+1 , it is going to be even more virtual than 67

Timezone for ICANN68 not yet clear.

NEXT CALL:Tuesday, 14 April 2020 at 03:00 UTC for 90 minutes.

no central team this time

bye all

Tuesday, 14 April at 0300 UTC

Thursday, 16 April 2020 at 20:00 UTC for 120 minutes.

good night

@Jeff, can you please explain in the next call about bringiing forward the PC period? Thanks.

Thanks Jeff, all

Bye all

Exactly @Annebeth

My 11 pm call is next..

Chag pesach sameach!

bye