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

23:49
Hello all

24:59
Welcome, Maxim

25:27
Hi all

26:17
Good Luck!

26:31
Thanks Kristine - congrats and good luck!

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

27:04
Good luck Kristine

27:09
Are you at liberty to say the new position?

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

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

28:30
23:00 here

28:30
spare a thought for Justine Christopher

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

28:55
Well, we will share the unpleasantnies

29:24
But is it our finest hour?

29:28
we do not switch, and it is 23.07

29:35
here

31:07
What about Corona Time?

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

33:22
Winged chariots of fire?

33:52
@Greg, it is like submarine, only UTC time

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

39:29
and local = place where they established and have HQ

40:41
applicable to what?

40:53
Yes, to applicable law, not just the applicant's

41:35
applicable to where the registrant is based and to where it does busienss

42:16
Concept confusion?

42:27
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.

42:36
I am not sure how to formalize Concept confusion

43:48
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.

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

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

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

46:04
@kathy, PICs to apply depending on the string

46:41
different regulation in every country for doctors of medicine

46:47
@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

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

48:31
happy to wait

49:20
@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.

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

51:31
Very well put, Kathy

52:20
Sensitive String Objection?

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

54:09
We’ll miss you Kristine!

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

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

59:30
would be better

01:00:14
Justine, I think this is a good suggestion

01:00:32
Also to clarify what we mean by "ICANN"

01:02:14
++1 Kristine

01:04:02
You can raise them @Jeff

01:04:06
new hand

01:04:19
and I'll come in if you miss what I mean

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

01:05:17
Support ICANN Org clarification

01:05:34
Support "negotiating for"

01:05:54
+1 Paul

01:06:05
+1 Paul

01:07:23
It wasn't included in the Applicant Guidebook

01:07:34
@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.

01:07:52
I support the structure and efficiency method.

01:08:07
Unlimited power to ICANN Org is not clear, structured or efficient.

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

01:09:13
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".

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

01:09:43
@ Justine, every RA amendment requires public comment period.

01:10:19
@Krstine, sure I think we should mention that

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

01:10:51
@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.

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

01:11:27
@Kristine, I mean to mention it here (again)

01:12:11
@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

01:12:13
@Justine, it is in RA , search for public comment

01:12:20
in it

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

01:13:40
Oh, got it.

01:15:26
This isn't a change to an application, but to the Registry Agreement.

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

01:16:44
the whole section is about the base RA

01:17:05
BASE RA

01:17:24
sure

01:17:28
BASE RA for next round

01:17:38
not for current registries

01:18:12
@Kathy, thye might not know yet

01:18:15
they

01:18:30
Add "Base" before "Registry Agreement"

01:19:07
currently there is no such thing, it is just RA

01:19:07
agreed Justine

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

01:20:20
Thanks for joining @Kristine

01:20:40
Don't be a stranger, @Kristine!

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

01:21:56
It should be difficult...

01:22:47
suggest we replace "requirements of" with "provisions of" or "obligations under"

01:23:15
Noted @Anne

01:23:29
Do we make it unnecessary complicated?

01:23:51
Agree on public comment period

01:25:27
When all registries of 2012 applied there were no restriction for RAA 2013

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

01:25:51
and some local registrars just quit instead of changing RAA 2009 to RAA 2013

01:25:52
@Jeff, correct.

01:26:10
@Jeff, hopefully...

01:26:26
is there a guard against sudden shift to RA 2022 ?

01:26:42
Please add "subject to 30 day public comment"

01:27:37
Karen Lentz has her hand up.

01:27:47
Yes to 30 day; no to pressuring applicants to have to put these in their applications

01:29:17
@Paul, no pressure but encourage should be fine, no?

01:29:21
I agree with Karen - it seems unbounded.

01:29:49
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

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

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

01:30:34
@Paul yes

01:32:33
.FEEDBACK PICDRP

01:34:59
What is the governing law in the RA?

01:35:32
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

01:35:34
No real governing law

01:35:38
just venue

01:36:00
adding third parties to an RA is the way to mass extortion

01:36:03
Agree with Griffin

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

01:38:09
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.

01:38:12
@Griffin - right

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

01:38:41
@Griffin, this is the way I interpret it too.

01:39:02
private attorney general is illegal here :)

01:40:04
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

01:41:11
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

01:41:26
quite an "adventure" @Greg

01:41:33
@Griffin - Good point....I will bring that up after Greg

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

01:42:02
what ICANN did was almost there - changing RA after accepting payments

01:42:18
Yup, agree with Griffin yet again

01:42:21
@Greg, ha!

01:42:47
Spec 11 Section 3(a) specifically

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

01:43:19
Griffin - excellent point

01:44:11
panelists to do jurisdiction shopping is too strong

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

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

01:44:39
+1 Maxim. "applicable law" without saying what it is provides no certainty

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

01:45:09
@Jeff - that is a reasonable middle ground.

01:45:16
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. :-(

01:45:27
@Jeff, I agree, a good compromise

01:45:48
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

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

01:46:48
are there any kind of protection from the rouge panelists?

01:46:56
No, but maybe the mauve ones

01:46:59
That is a color joke

01:47:38
:-)

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

01:48:02
Would need to look into that

01:48:22
Griffin, was that an off-color joke?

01:48:30
on- and off-color

01:48:31
Not surprising from the governmental side, Jeff. They need time.

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

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

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

01:52:06
we do can not prevent GAC from having a discussion

01:52:33
Anne I believe they were planning on furthering their work at the next meeting

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

01:52:45
to arrange timly input

01:54:17
@Christopher — Jeff has posted the letter to the list.

01:54:58
we have not been there

01:55:09
We launch them in 2 to 3 years

01:55:32
@Alexander, announcing is not equal to launching

01:55:32
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?

01:56:30
@Justine - Yes we would

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

01:56:53
+1 , it is going to be even more virtual than 67

01:56:55
Timezone for ICANN68 not yet clear.

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

01:57:01
no central team this time

01:57:14
bye all

01:57:14
Tuesday, 14 April at 0300 UTC

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

01:57:19
good night

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

01:57:23
Thanks Jeff, all

01:57:24
Bye all

01:57:24
Exactly @Annebeth

01:57:32
My 11 pm call is next..

01:57:36
Chag pesach sameach!

01:57:40
bye