
37:45
It was the worst of times, it was the even worst of times…

38:06
Hi 2 all!

38:14
staying home is a habit , so it does not count

39:10
Hi Jeff, Cheryl, staff et all - Re RVCs, in the Google doc I added after the phrase about the post-application RVCs being subject to Application Change Request, the following for clarity, "including, but not limited to public comment pursuant to standard ICANN procedures and time frames" .

40:22
Noted thanks @Anne... That is your AI reported then :-)

41:24
Yes

41:57
Thanks Cheryl.

42:39
PDF here to follow along.

42:50
And the red-lines here: https://docs.google.com/document/d/1xXu7gPKiblS3Vh4MCuK6NWfeRmMolXf9VF5sO7OG4VE/edit?usp=sharing

43:00
@Annebeth Yes Zoom Party and other celebrations ( I am doing a monthly luncheon with friends that has been running 35 years now via zoom in April, and attended my 1sr live streamed funeral yesterday evening..

43:13
Though that version has Paul’s edits, so it differs versus the clean version now.

43:34
Well noted @Steve

50:15
+1 Anne - share question

51:56
@Paul when you talk about “community wants predictability” how you define community?

52:05
THank you Paul - saves time for IRT

52:30
Well if you keep the text in " " then keeping reference to s 1.1.2.4 AGB makes sense.

52:52
@Paul thanks

55:02
Those most concerned to secure predictability will, inevitably, be those directly engaged in the application process. And rightly so, I think.

55:46
@Christopher - could we get through the proposals before they are deconstructed?

56:09
Agree Tom

56:10
the last idea is not clear, why the predictability is less important for applicants?

56:38
it might be equally important (from philosophical point of view)

56:59
Agree Tom

57:24
+1 Maxim, Tom

58:07
Is it okay to redline the Google doc rather than doing it in "suggest" mode?

58:19
would be helpful to go through Paul’s suggestions

58:32
I think Paul's changes are just trying to put a 'timeframe' on GAC Advice, he's not ruling out GAC Advice, just putting timing on it, which is important for applicants and predictability.

58:56
I also agree with Christopher Wilkinson that it is very difficult to restrict governments and “put them inside a box”, as he said. Experience shows us that there will be situations where governments will react that are very difficult to predict.

01:00:24
What we hope this time is that the GAC has been involved much earlier than last time, so that we can avoid some of the problems from the last round

01:00:36
+1 Martin. Would be helpful if we could go through these before they are taken apart (and mischaracterized as somehow trying to bind the GAC, when in fact it does the opposite).

01:00:37
The GAC operates more efficiently now than it did during the early days of the last round.

01:00:51
And is more engaged.

01:01:02
I suspect the more softer result might be where we might end up @Greg (personal POV)

01:01:20
Agree @ Greg

01:01:38
@Annebeth and Christopher--this has always been a tension within the MS model, that GAC Advice has elevated importance. However, in the context of a process such as New gTLDs, can we find a way that ensures governments don't come in after the fact to change agreements made during our four year process?

01:01:55
that may be the case today but the GAC turnover ensures we won’t have the same group when the next window opens

01:02:53
@Donna, as Tom says, the governments are more prepared this time, are more effective and more engaged. So I think it should be possible to find a model that works.

01:03:16
@Elaine, GAC turnover should not be an issue as government positions generally stay the same regardless of who the representative is.

01:03:29
+1 Paul... this gets that predictability

01:03:41
+1 Paul

01:04:02
I agree Annebeth

01:05:49
Yes, as the Canadian GAC Rep, I can attest that we are now doing more 'early engagement' with the PDP policy process which will hopefully provide better outcomes for all and for more continuity/predictability. I also suggest that we would need a bit more time to review the suggested text and welcome the collaborative spirit and support the suggestions to reframe proposed changes more positively .

01:06:33
I would prefer retaining "the Working Group urges the GAC to provide this Advice ....."

01:07:19
@Paul, right - your proposal changes it from a "should" to a "must"

01:07:23
Is this intended to supersede the Bylaws?

01:07:40
@Avri - Not in the original clean text

01:07:52
for example imagine now TLD covid .. how GAC would reacted

01:08:05
very concerned about these revisions

01:10:48
@Avri - no. All the mechanisms in the Bylaws remain in place. It changes nothing for the GAC and it provides a basis for how the Board should treat certain GAC Consensus Advice. Since it would be the Board adopting this Recommendation, it would be the Board self-limiting and not the WG limiting the Board - we can't do that. But, we can let the Board know what we want by sending up a Recommendation that provides predictability.

01:10:52
Well there is a lot of effort put into (endlessly) improving Board-GAC working arrangements (special working group etc) so there should be scope for the Board (maybe more so than the GAC) to make any recommendations here work in practice.

01:13:45
+1 Jeff re examining existing GAC Advice on various things with the view of maximizing predictability on what we do know now. But we cannot expect GAC to predict or foresee what will happen in the next round outside of existing GAC Advice.

01:13:54
I can't hear Kathy. Is it me or her?

01:14:01
you

01:14:59
+1 Justine

01:15:01
Sorry you missed my comments, Paul :-(

01:16:01
Categories are just groups of individual applications...

01:17:16
Categories are also helpful.

01:17:33
It makes the advice more consistent...

01:18:31
+1 Jeff

01:18:40
Isn't it a bit odd to suggest that the board shall agree to our proposal where they agree to reject GAC Consensus Advice instead of making a decision depending on the actual circumstances?

01:19:13
Yes, I have difficulty telling GAC and Board what they can or cannot do.

01:19:31
+1 Justine

01:19:31
it might be better to use wording saying that the document should contain something

01:19:52
instead of saying that the body issuing the document must

01:19:57
But the Board can tell itself what to do. Since it would approve the recommendation, it’s their action, not ours.

01:20:02
The wording is important here

01:20:13
offending GAC might not be wise

01:20:14
+1 Anne, exactly why I would prefer to retain "WG urges"

01:21:05
+1 Justine, +1Annebeth

01:21:08
Agree with Katrin about defining circumstances.

01:21:28
That said, I doubt the Board will bind its own hands, absent unanimous support by the Community (and even then...)

01:22:24
It makes us look a bit stupid to say "The ICANN Board must" . They can NEVER agree to this.

01:22:25
in many worlds, a "must except in..." is known as a should.

01:22:31
We could say that the Board should take into account whether the GAC had a clear opportunity to give this advice before the milestone (not deadline), in considering whether to adopt GAC advice.

01:24:15
The Board cannot amend its ByLaws by adopting policy that reverses the effect of the ByLAws. A ByLaws amendment is subject to Accountability mechanisms.

01:24:43
If we can find words that explains a kind of way out if something unexpected happens after the AGB is published

01:25:00
If we stick to "the WG urges the GAC to do something" we can avoid using the words "should" and "must".

01:25:28
+1 Justine. We should also say "urges the ICANN Board"

01:25:49
+ 1 Justine

01:26:34
Heck, yes, @Anne. And if we need, to we can say "The WG STRONGLY urges the GAC or Board ..." (as the case may be)

01:27:08
I think this paragraph serves an important purpose

01:27:13
A recommendation of 'urges' may be more workable than one the tells the Board to go around the Bylaws.

01:27:18
Personlly I am more comfortable with the softer language as mentioned above by either @Greg or @Justine

01:27:48
+1 Avri

01:28:03
+1 Cheryl

01:28:18
indeed @Avri

01:28:44
+ 1 Cheryl

01:29:00
I wonder if we might defer this topic and jump to Applicant Support?

01:29:29
@Justine.....we need to go through the substance of each of these before a deferral

01:31:01
i agree with Christopher's suggestion

01:32:01
I agree with Justine that deferral makes sense given the extent of the changes

01:32:06
Delete FN 18

01:33:01
@Jeff, how does ICANN Org mitigate concerns?

01:33:36
I thought it facilitates mitigation between applicants and the GAC.

01:33:58
Doesn't Paul propose major changes here as well?

01:34:22
Defer: I am not able to take extensive amendments on the fly. CW

01:34:49
Okay, thanks @Jeff

01:35:06
Apologies all, I need to run, I have another call starting now.

01:35:46
Thanks @Kristine

01:37:17
Got confused about which one fo these we were talking about.

01:37:21
Sorry all!

01:37:41
LOTS going on @Paul... NP

01:37:58
I didn't make any changes to rationale 3.

01:38:01
LT and staff is the CLean version

01:38:05
Not Paul @Kathy, Emily

01:38:36
x!

01:38:38
TX!

01:38:50
no edits from me on Rat. 3

01:39:46
If it helps to clarify when your in the redline doc, if you highlight either the text or a Comment the related comment or text will highlight...

01:40:40
Footnote on Bylaws section is in there @Anne

01:42:00
Noted @Anne

01:42:40
Thank you Jeff and Cheryll.

01:42:49
No more recommendations from me on any that we have not already looked at.

01:43:39
My comments were limited to GAC Consensus Advice which are creatures of the Bylaws. I haven't make any comments on GAC Early Warnings which are creatures of the AGB.

01:44:37
+1 Anne. Good catch

01:44:41
Good catch @Anne

01:45:13
Thanks

01:46:50
There is a distinction between Early Warnings and GAC advice. An early warning was generally made by a single government.

01:48:58
So practically speaking, GAC Consensus Advice has to be addressed via Application changes, PICs etc but if GAC EW is not addressed, then the government that issued the GAC EW should rely on the objection process to bring forth its EW?

01:49:56
Dear DONNA ,Nothing prevent the GAC to make a collective early warning. pls advise where such action is prohibited

01:50:07
@Justine, yes only GAC Consensus Advice will likely lead to commitments, unless a registry wants to voluntarily make changes in response to an Early Wanrining

01:50:12
Warning

01:50:54
@Kavouss--agreed, just saying that in 2012 the Early Warnings were generally made by individual governments.

01:52:20
@Justine - i think the idea is, hopefully, avoid GAC Consensus Advice by addressing concerns found in a GAC Early Warning

01:54:09
@Paul, my point is GAC EW does not stop an application from proceeding whereas GAC Consensus would.

01:55:18
@Justine - GAC EW does not stop an application, Neither does GAC CA, unless the Board agrees with the GAC and adopts the GAC CA. Ultimately, it is the Board that stops applications, not the GAC.

01:58:02
@Paul, "might" not "would" I give you that.

01:58:10
N B: some of our language is not current beyond our PDP bubble: e.g. actionable, merit-based etc. CW

01:58:17
Advice of GAC can be deducted from the EW expressed by GAC in the first round.

01:59:37
I Don't think could be a problem for GAC to summarize these views if this could help…. but makes sense only if this is reflected into the AGB...

02:00:17
Repeating myself. +1 Jeff re examining existing GAC Advice on various things with the view of maximizing predictability on what we do know now. And ask GAC members if there might be updates.

02:01:06
leave it to next meeting

02:01:53
My comments was on Rational 3

02:03:12
I was going to send a personal comment to the leadership team

02:03:38
Sending prayers for unity for all people, everywhere, regardless of geography, faith, form of government, or any other factor that tends to drive us apart. Stay safe everyone.

02:03:49
Thanks, Be well!

02:03:59
Bye, thanks a lot.

02:04:08
bye all and stay cool

02:04:11
Stay safe (and sane) people make smart choices and wash your hands!!!

02:04:14
Take care everyone, good bye.

02:04:32
Bye for now...

02:04:38
Bye