
42:44
@Jeff, thanks. I'm sure the notice will also include a deadline for response. Just confirming the same.

44:25
Thanks

44:40
Document here: https://docs.google.com/document/d/1kUlmZH8nxWTgfcRluA5FxLheMm4XhhOwkRt7om52aQU/edit?usp=sharing

46:24
Do we know how many ROs are in this position?

46:40
What is the current standard for seeking a Code of Conduct exemption?

47:19
Support. Innovation should not die on the vine because the business model doesn't fit in the vintage second level domain name sales model.

48:15
Code of conduct exemption page here: https://newgtlds.icann.org/en/applicants/agb/base-agreement-contracting/ccer

49:04
It seems that if we are recommending they be able to seek exemption, we would have to specify standards. How do we know how hard they tried to get aaccredited registrars?

49:05
I'd support a question being asked in the draft Final Report, then examine the responses against the "anectodal evidence" to see if action is necessary.

49:08
It is going to be fixrd in the future @Jeff

49:20
it is a temp measure for security updates

49:20
Not just you!

49:37
But wouldn't due diligence, especially after the 2012 round issues a small handful experienced, require ensuring you have a distribution channel? Need to do your research ahead to make sure a or a few registrar will carry your TLD.

51:37
I think Justines approach works for this

51:44
yes

54:19
What if the registry just doesn't like the financial terms offered by the accredited registrar?

55:47
This is a marketplace issue Anne, in that registrars largely prefer to onboard registries that are vanilla. there are costs to the registrar to onboard a registry that has requirements that are unique in some way, so it may not always make economic sense for the registrar and that limits the options available for the registry.

58:08
Thank you Donna. That may be a good reason for the second part of the question.

58:13
Thanks Jeff.

59:08
The Report should make it clear that this is about the Registry opening its own registrar. The current paragraph is very cryptic.

59:30
+1 Greg

59:31
Just as an FYI, this was something that I raised in a presentation I provided to the board on the registry/registrar marketplace in Montreal.

01:00:07
@Anne, I would exclude in the question any reference to "standard"; instead, I think it's sufficient to simply ask for rationale.

01:04:45
@Anne, yes, we need to add that stuff from the other sections into here

01:06:19
Hand up

01:06:29
I get the feeling that we need to actually stipulate what WOULD NOT require posting for public comment

01:07:07
Your approach works too @Jeff

01:07:14
we should be explicit where we can

01:08:00
Sure, that's fine too

01:08:00
indeed!

01:09:24
I tried to raise my hand earlier, but I can’t :)

01:09:46
I just thought since we have that "Do Not Require" list, anything that falls outside would require public comment. Perhaps we need to look at adjusting the "Do Not Require" list.

01:10:01
+1 Steve

01:11:37
The page I’m on now is here: https://newgtlds.icann.org/en/applicants/global-support/change-requests#statistics

01:13:12
We really need to specify those items that were discussed specifically in our deliberations where we were assured that references to Application Change Request included public comment. For example, settling Objections,

01:13:48
Agree with Justine - Do Not Require makes sense, has a track record, and it’s preferable to have a false positive (comment period where one wasn

01:14:04
t really imperative.)

01:15:49
It’s Steve btw :)

01:16:10
Hello all, sorry for being late

01:19:43
I am back, but Cheryl is doing great..... :)

01:21:28
Ergh

01:21:43
always one end or another with beasties :-)

01:23:03
There are items that are not just Implementation Guidance on Application Change Requests. Some of these are Recommendations for public comment. eg RVCs as stated above.

01:23:51
Ok thank you - look forward to new draft.

01:25:40
Change in a string was another area where deliberations reflected a need for public comment. For example, a settlement could involve a payment from one party to another which does not take into account the public interest.

01:31:07
Ok thank you.

01:31:38
If I recall correctly, the ALAC did comment that there should be guardrails for changes to applied-for strings.

01:31:54
@Justine - absolutely

01:31:58
+1 Justine

01:32:07
I think the last paragraph has those guard rails

01:32:45
Yes, indeed.

01:32:55
And some of the concerns are raised in the second paragraph of course.

01:33:41
a decade later?

01:34:54
@Maxim, but who’s counting? :-)

01:35:41
The proposal in the third para is eminently reasonable.

01:37:08
@Jeff, use .brand as example, and ask if other circumstances could be considered?

01:37:28
@Jeff, look at ALAC's suggested guardrails.

01:37:56
Thanks @Justine....Steve can we bring that up

01:38:17
One sec…

01:38:20
If I can sum up ....

01:39:47
NO to (1) causing name collision risk (2) new string not closely related to original string as determined by expert/community input (3) new string is exact match or is an IDN variant of an already applied-for string (4) new string is an IDN variant of a delegated string

01:40:24
Doc is here: https://docs.google.com/spreadsheets/d/1Ea-CjtL-heQjEwTesr7MYC_8gFEvmhY8XBCWTvoan6g/edit?usp=sharing

01:40:35
Thanks Justine - very helpful in addition to public comment and open for objections

01:42:10
if it is a variant of the string applied by the same entity?

01:42:49
I don't think it needs to be just brands, but I don't recall what Kathy said.

01:42:58
I mean IDN variant to something, applied for by the same applicant , or to some TLD, run by the same entity?

01:44:48
if we specify too much, then we might miss something new

01:44:52
The AGB would double in size if we relist the rules here

01:45:15
The general reference should include examples. We can specify the listed guardrails from the chat for the broader category - we can list these as compliance with the other rules, e.g. Justine's list and then also public comment, and Objections etc

01:45:20
I hope this time it is going to be less than 500 pages

01:45:36
+1 Maxim, a good goal

01:45:44
Hooray Maxim

01:45:48
We're making this very complicated

01:45:51
@Maxim - I doubrt that - we are adding appeals

01:46:01
No Guaruntees Maxim ;-)

01:46:37
You start pushing out timelines and messing with evaluation processes.

01:46:52
@Karen- thanks for raising that!

01:47:09
Good point Karen! Because there are timing issues with when the trademark was registered, right?

01:52:31
Maybe we should make the definition of .brand more practical, e.g. eact match of mark or exact match of mark + relevant industry term

01:52:34
Should point (d) include GAC EW/Advice specifically? And should point (d) apply to joint ventures?

01:53:02
Good point, Paul - all of these guardrails link directly to what we define brand as, ie, what we allow brands to apply for

01:53:37
we can't apply a guardrail standard that is wildly different from what we allowed .brands to apply for in the first place

01:54:18
GAC sending requests for delay to PDPs directly , instead of GNSO Council seems to be a wrong vehicle

01:54:49
it is like GNSO sending letters to some GAC subgroups

01:54:58
not really Maxim. Jeff and Cheryl have actively engaged with the GAC

01:55:24
To Anne's point, we are going inevitably to have issues with GAC participation in remote meetings. APAC was completely unable to participate in Cancun. Which GAC region will be unable to participate in ICANN68?

01:56:22
I meant that PDP itself can not seriously extend it’s timeline without a Council in reality

01:56:38
+1 Jeff. Means we need to get creative, outside of the ICANN68 replacement (whatever that is), in seeking GAC input.

01:56:42
and let's remember that this effort has been going for 4 years, so as Jeff's says ample opportunity has been afforded the GAC along the way.

01:57:42
Heather, in New York, we’ll be starting at 8 pm and finishing at 6 am, since we are 12 hours behind KL....

01:57:53
Running public comment periods create a lot of overhead for the community, the WG, and staff. It’s good to consider the impact from running two public comment periods.

01:58:51
I understand the time zone (and there may be more than one) for ICANN68 has not yet been decided.

01:59:13
+1 Cheryl

02:00:51
I think we have the opportunity to offer some specific GAC input on the 5 comments

02:01:36
+1 Cheryl - let's not forget that the GAC had the opportunity to participate in the previous public comment period, and will have the same opportunity in relation to the Final Report, irrespective of location/time zone of ICANN68.

02:02:32
The goal under current run times on the topics as we see it was to allow ICANN68 to be in the PC period to allow faciliataion and discussion *OF* our Report during and beyond ICANN 86

02:02:41
maybe 68 ;-)

02:04:59
I know we’re over time, but is there time for a quick comment from me?

02:05:38
@steve...no....just kidding....of course

02:06:46
YES that's true but they emphasized that they had lower participation due to last minute issues.

02:07:11
If we are contemplating running ahead of time, I would love it if we could consider dropping back down to 1 call per week, but hey, wishful thinking.

02:07:44
or at least backing the 2 hour marathon to the 90 minute marathon...

02:08:50
Time check

02:09:06
Perhaps put a stake in automatically extending the public comment period?

02:10:25
Particularly in relation to a Final Report, there is a big difference between participation versus - available for public comment.

02:11:20
we went for 100 tonight so give us 10 min back on Thrusday ;)

02:11:23
Thursday, 16 April 2020 at 20:00 UTC for 120 minutes

02:11:30
Lots done today people THANKS to you all we continue to progress MORE to come of course! :-) Bye for now...

02:11:53
bye, thanks, be well all.

02:11:57
Bye

02:12:00
bye all

02:12:00
Thanks Jeff