
30:22
Nope I am here in the room as well :-)

30:34
Ah, welcome, Cheryl!

32:01
hello all

32:23
Link: https://docs.google.com/document/d/1xXu7gPKiblS3Vh4MCuK6NWfeRmMolXf9VF5sO7OG4VE/edit?usp=sharing

33:14
page 32

34:32
What does that mean? Who is "a community"? Does that mean the specific community to which the TLD is directed, or does it mean the ICANN community (or subcommunity)?

35:10
Has there been any analysis of all of the community applications that were submitted to determine whether the cause was a difficulty of applicants in answering the community-specific AGB questions, or the cause occurred through scoring?

35:47
If the cause of low numbers is that applicants had difficulty with answering the community criteria, then we need to provide guidance, not 'extra credit'

35:57
Seems like we can tighten "a community" to "the community to which the TLD relates"

36:49
+1 Paul - makes sense

37:59
Can we make it clear that what we are after is innovation, not just "the problem is that all the good domain name real estate is gone" or some of the more garden variety "let's sell more SLDs" use cases.

38:06
The outcome is particularly interesting given the CPE process, which was actually itself supposed to be a sort of 'extra credit'

39:48
yes

39:53
yes

41:06
i have switched and am back

42:01
OK Jeff the steering whell is all yours again (or is this a rudder (being a bohemeth of a ship)

42:13
sounds good

43:08
Better scoring does sound like a better idea than more scoring....

43:09
Yes @Jamie that is a genuine observation

43:59
How well have we evaluated the evaluators?

44:02
I suppose the question could be one of the standardisation (and credibility) of the assessors/evaluators

45:05
*Very valid* point @Jamoe

45:37
Jaime has raised an issue that seems more vital than the one raised in the agenda...

51:00
Sure thing

51:33
Correct

51:33
yes

51:35
correct

52:20
excuse tardiness

53:22
Sorry for joining late

55:47
makes sense, Jeff

57:15
RPM did not look at PICDRP

57:18
Only TM-PDDRP

57:29
No one looks at the PICDRP

57:46
@Griffin - thanks! Its been so long.

58:01
It's an unreviewed process

58:03
As someone who prosecuted a PICDRP complaint, that's not true Kathy.... although it has certainly been less effective than we had hoped

58:06
If it’s expected that the PICDRP would be updated to incorporate RVCs, would be helpful to note this in implementation guidance

58:48
Although ICANN did implement some enhancements to PICDRP (many of which were based on our experience in the process)

59:06
Correct Jeff

59:24
@Jeff, I think we need to note this in implementation guidance. This may need to be sent to RPMs Phase 2, since the PICDRP is a (sort of?) RPM.

59:55
Also agree that if necessary, implementation guidance should say that PICDRP would apply to RVCs

01:00:08
@Paul - would caution against sending PICDRP to RPM Review

01:00:14
Thanks @Karen Noted

01:00:27
@Jeff, what does "and associated processes" refer to?

01:00:28
It seems squarely to be a Sub Pro issue

01:00:45
No harm in bekts and braces IMO

01:00:49
Good idea

01:00:59
so Yes to add for Implementation Guidance

01:01:04
hand up

01:03:09
I am sympathetic to Kathy's comments

01:03:34
See your point, Kathy

01:04:30
+1 Jeff - Council is the right place for that issue

01:05:08
But the Implementation Huidance is also important and going into any new round *is* within our mandate...

01:05:40
The footnote helps close the circle (pun intended) to some extent

01:06:19
Yes, understand. Thinking about it.

01:07:03
Make a note to come back in final drafting to double check this then @Jeff

01:10:56
Rational 6: Just for clarity, what process is meant to apply if the RVCs do not address the underlying concerns?

01:11:28
According to whoever evaluates them,

01:16:10
So the "connection" to "until the "reviewer" is satisfied that the RVC addresses their concern is missing.

01:16:35
So the "connection" to "until the "reviewer" is satisfied that the RVC addresses their concern" is missing

01:17:55
@Jeff, so "adequately" and "usable", etc. aren't gatekeepers to bounce RVCs? Just want to be sure since we are saying "must" instead of "strive" or "really ought to".

01:18:52
We could cross reference here though to be extra sure if that helps @Anne

01:19:17
I mean cross reference to the Application Change Process details

01:19:18
There is a cross-reference to Section xx Application Changes Requests in rationale 4

01:20:27
@Jeff - thanks!

01:22:18
@Kathy, all, the redlines are available in the working document: https://docs.google.com/document/d/1xXu7gPKiblS3Vh4MCuK6NWfeRmMolXf9VF5sO7OG4VE/edit?usp=sharing

01:23:05
Thanks @Steve

01:24:23
Page 7 of the redline completely deletes the previous recommendation xx in the last section related to Rationale 7. That section said all RVCs must be subject ot public comment and also said all RVC post-application must be considered as an application change request. That's why I was looking for a clear statement of these two principles in the redraft.

01:24:30
Among other fixes which I plan to be ready to present on the next call, I think we need to globally change GAC Advice to GAC Consensus Advice, since that is what the Bylaws call it.

01:25:34
@Anne, Jeff said earlier that was moved up. I think.

01:25:58
Captured in a new place was the intent

01:26:09
hand up

01:26:51
I agree with you Jeff

01:27:00
Thanks Elaine

01:30:02
However @Anne if you have sime better drafting to offer here please anyone is welcome to propose that in the Doc

01:30:16
some better...

01:30:30
Ok Cheryl thank you.

01:31:57
bye all, have to drop to be ready for the GNSO councillors call

01:33:32
GAC Communique here: https://gac.icann.org/contentMigrated/icann67-gac-communique

01:34:12
Thanks for joining @Maxime

01:36:36
"DNS Abuse" definition; an elusive thing...

01:38:17
Footnote is good way fwd then...

01:39:40
+1 @CLO

01:40:43
+1 - I like the idea to the Council. This is already on their radar, so they won't be surprised by that. If we try to deal with it, this WG meeting its deadline is doomed.

01:40:58
[letter to the Council]

01:41:19
Agree Jeff/Paul

01:41:20
+1

01:41:20
I support the letter to GNSO Council on this.

01:44:40
@Jeff, can you walk us through the release schedule?

01:46:59
@Jeff, so Batches will be internal to the WG, not releases to the public comment crowd, Correct?

01:47:04
Fill out this slip IF you have any Ï can't live with this"issues

01:47:10
correct @Paul

01:47:24
Yes @Paul internal WG use

01:47:37
Thanks Julie. Thanks Cheryl.

01:48:00
Just wondering how horrible April was going to be. :)

01:50:25
wow

01:50:31
:)

01:50:35
Mazel

01:51:21
I feel I've been in turmoil since 2017 with hurricane Maria a Cat5, then a 6.4 Richter quake beginning of 2019 and now viral pandemics. Feels kind of normal now.

01:52:23
Let's be committed to both moving ahead expeditiously and also baking in necessary flexibility. I think we can do it! If we didn't have a high tolerance for ambiguity, we wouldn't be anywhere near this kind of work.

01:52:26
This is volunteer work for many people... and that time may be taken by other obligations and aid.

01:52:58
Understood Kathy. I think a longer period for RPM may also be necessary

01:53:24
Agreed Jeff -- a longer period for everything!

01:53:27
+1 @Paul!

01:53:36
We should be prepared to entertain individual requests for more time on the upcoming documents.

01:54:16
@Everyone - please stay safe and healthy. Sending prayers for your friends and families during this time.

01:54:18
it gives some of us more time - can / would like to help to speed up the process ! I no longer have a day job .

01:55:24
Next call is Monday, 23 March at 2000 UTC

01:55:44
THank you Jeff, Cheryl, staff et al. Stay separately safe!

01:55:53
Thanks, good work! Bye, and take care

01:55:55
Thx all - keep well

01:55:58
@Everybody, stay safe. Stay home!

01:56:00
thanks. be well all.

01:56:01
cio

01:56:03
Stay safe stay sane!

01:56:05
Thank you all! Take care!

01:56:09
+1 Jeff

01:56:09
Bye

01:56:11
Thanks all

01:56:12
Thanks, Jeff and all, bye!