
32:29
@Annebeth, all, SubPro is scheduled to meet on Sat the 7th, from 15:15-16:45 and 17:00-18:30 and also Monday the 9th from 10:30-12:00.

33:41
Thanks, Steve

34:13
Hello all

34:53
hello all!

35:01
What does that mean in terms of the role of the Board Liaison?

35:08
thanks

36:22
Thanks Avri

37:06
Thanks Becky

37:18
sorry! zoom accident

38:55
20feb

39:58
is there a link to this doc?

41:05
@Jim, there will be. We wanted to share this first as a preview, make sure there are no major objections.

41:28
We certainly welcome your detailed review.

45:02
@Jeff , as I understand GNSO op. procedures do not envision any special role such as Board Liaisons, so it is a kind of informal role - am I right?

45:28
Some predictibility would be good. I am doing community outreach since over a year for several community applications and they naturally demand a TIMELINE.

45:52
We have gone through these issues many time before. Time to make choices and compromises.

46:05
I think that expectation that WG members will be able to devote 3hours and stay in a good working condition is bit too enthusiastic

47:06
there's remote participation for all icann meetings

47:19
Currently I am forced to tell them that ICANN is not being able to provide any clear, reliable timeline. Makes ICANN look unreliable and uncoordinated.

48:41
@Robin, I agree wholeheartedly and maybe we could all confirm that we are willing to participate in the spritit of completion.

48:59
@Alexander , there is some degree of stability, there is the same level of predictability

48:59
QUESTION: By when does Leadership need our comments on the revised work plan to be submitted to GNSO Council?

49:18
on the extended call proposal - I do share MAxims concerns but my greater concern is scheduling. That needs to be done well in advance as every on this call has other standing meetings and demands on their time

50:10
Indeed, that’s the goal Jeff

50:26
potentially -10days before GNSO meeting, so it should be around middle of 10feb

50:50
but there could be a ‘placeholder’ paper with later update

51:12
Working document here: https://docs.google.com/document/d/1kUlmZH8nxWTgfcRluA5FxLheMm4XhhOwkRt7om52aQU/edit#heading=h.ghi4hytcc3

51:17
Here’s the link to the doc: https://docs.google.com/document/d/1kUlmZH8nxWTgfcRluA5FxLheMm4XhhOwkRt7om52aQU/edit?usp=sharing

51:32
2.2.1 Continuing Subsequent Procedures

51:59
Page 1

58:11
Christopher note this Board resolution for implementing CCT recommendations https://www.icann.org/resources/board-material/resolutions-2020-01-26-en#1.e

58:17
Christopher , ICANN stopped the metrics

59:21
Right.

01:02:55
Thanks Jeff

01:09:49
this is very abstract - is there a live example?

01:10:55
The first option adds to predictability for applicants. Else applicants may be in limbo for an unknown period of time.

01:12:30
Recommendation: preference is that ICANN publish a date.

01:13:08
Implementation Guidance: preference is that it should not be possible to apply for a string that is still being processed from a previous application opportunity.

01:13:46
+1 Donna

01:15:03
Disagree that strings from last round should be prohibited. SEcond option supports the notion of Applicant freedom of expression.

01:16:52
@Ann, from a process perspective it would add complications that really aren't warranted.

01:17:25
+1 Donna

01:18:25
even this round was not the first one

01:18:31
@Donna - no evaluation of the new applicant would occur until the 2012 applications are resolved. The new applicants would have to accept that risk.

01:19:02
@Alan, no ramification at all based on what has happened for getting to the next new round.

01:19:25
Agreed Donna . we have discussed this so many times already . we need to draw the line here .

01:19:38
I feel that Anne's suggested disadvantages the less sophisticated applicant/less wealthy, who does not have the benefit of advice from someone who has been engaging throughout. There's a real risk that they apply, not understanding that they will be on hold for potentially years. What is the harm in keeping a particular string closed for new apps until all the previous applicants have fallen by the wayside. Then it opens up again for all

01:20:04
Agree Susan.

01:20:37
@ Susan- because the window for application is closed at that point and we haven't said that a new window could open if they all fail.

01:21:28
@Anne, if there is agreement that rounds are the path forward, then if a string does not go through in one round it will become available in another round.

01:21:37
I think we have - that's one of our recommendations that there will be a series of windows

01:23:40
We have to distinguish between slowpokes and those that have not gone through but have not been withdrawn.

01:25:02
Can't live with prohibiting applications for the same string. If "shall not proceed" means new applicants can still apply, I can live with that.

01:26:52
+1 Greg on this being a policy issue not IG

01:27:56
+1 to Greg and Justine - this is a policy issue and it will likely apply in the future to strings we are not even considering at this point.

01:29:08
I did not suggest allowing new applications for strings “in process”. Maybe that’s where the misunderstanding stands.

01:29:36
The scenario just mentioned by Donna also is foreign to what suggested.

01:30:40
@Jeff, what do you mean by “in process”? That is really the gating issue here.

01:31:12
Exactly Anne, it did take 10 years, which is why I'm in favour of publishing a date for a next round.

01:31:20
This past round could take 50 years if blocked applications live on.

01:32:12
So Anne, are you advocating that someone could apply bot .biz?

01:32:24
apply for

01:32:48
@Donna - I don't think we ever considered that issue.

01:33:08
If it would be possible to file applications for the same string in future rounds the door is open for gaming and unknown consequences: applicant(s) from the first round might consider future applicants in their behaviour and decisions.

01:33:33
Surely, all delegated TLDs or those in process, are off limits.

01:34:44
Donna, .biz is delegated and being operated with SLDs in the root. How does that fit into this discussion???

01:35:24
I think applicant freedom of expression means you can apply for any string you want, but I don't think that extends to TLDs already in existence or those that are in process in some way.

01:35:36
+1 Donna

01:35:36
@Donna - Agree delegated TLDs are not under discussion.

01:35:43
Delegated domains were never part of this consideration.

01:36:08
Delegated TLDs, TLDs that have a contract......

01:36:12
Because Anne was leading me to believe that was a consideration.

01:36:27
Which is why I sought clarification.

01:38:24
I also think that old applications that were denied for a policy reason should have to step up to new policy recommendations if they are going to prevail/ proceed and they should be encouraged to do so by knowing there may be applicants standing in line who are willing to do so. (No stonewalling on new policy recommendations - no blocking based on old policy positions.)

01:38:36
Okay, glad we cleared that up, @Donna.

01:39:17
@Jeff - what about the status called "Not Approved"?

01:41:21
Sorry I need leave the call, bye!

01:42:03
@Anne - I really think we should agree some principles rather than get bogged down in the detail of individual statuses

01:42:54
How can they block?

01:43:25
there is no proof so far that further work on Name Collision is required

01:43:42
Policy can not be developed by the Board - it is not GNSO Council

01:44:05
NCAP is SSAC work, they do not produce policy

01:45:20
Maybe “policy” is not the right word, but the point is that the old applicant can’t meet new technical requirements.

01:45:35
That were put in place to resolve an issue.

01:45:56
before the requirement is set - there is no way to follow it

01:46:07
If the previous "not approved" applicants will meet the requirements specified in new policy, they should be "grandfathered" and be able to proceed. Any new applicant for that string is just "getting in line" and taking the risk.

01:47:44
Registries have to follow Consensus Policies, so eventually they will have to

01:48:19
An applicant from a prior round who does not want to meet new policy recommendations can block a string forever by not withdrawing a Not Approved application.

01:50:59
when you reer

01:51:26
when you refer to mega round: so that's 5k to 10k applications?

01:51:38
It would be good if we could all take a leap of faith and agree that moving forward fewer changes woudl be required, if at all.

01:51:58
Mega-round is what we just had, compared to all those before it. Bigness is always relative.

01:52:15
ok

01:52:36
@Donna, I agree with your leap of faith, at least conceptually.

01:53:51
Policy for Registries and Registrars, and for Apllicants - there is AGB , not policies

01:53:53
Yes Donna, the frequency and extent of changes should be minimal in future, certainly hope so.

01:54:02
Let’s not trip on the word “policy” — if an existing applicant can’t go to delegation in the new round, they’re out.

01:54:42
And we won’t know every scenario/fringe case to incorporate into policy

01:54:54
Are we talking about .home, .corp and .mail where the Board took the decision for security and stability reasons to not allow them to move forward, and some of those applicants have not withdrawn? So what standing do those applicants have in a future round?

01:55:43
Donna, I think that is the primary bucket we’re talking about.

01:57:05
Yes Donna. those are not withdrawn even though "not approved". If the Board adopts new name collision policy, old applicants should be willing to step up to the new name collision policy and not be able to refuse to do so and block the string forever by not withdrawing the application.

01:57:34
sure

01:58:43
Kathy’s comments are aligned with mine.

01:58:54
Always worth noting!

01:59:21
@Kathy, They applied in accordance with the rules of the round, but the rules changed during the evaluation process.

01:59:27
:-) Tx Greg!

01:59:46
@Donna: not the ones I am thinking of...

02:00:10
@Donna, that should not give them a free ticket into the next round, or a reservation, or however you want to think about it...

02:01:04
Donna has a point — we have a problem to solve but we may not need to write completely new policy to solve it.

02:01:16
@Donna - when the denial was for policy reasons, e.g. the security and stability of the Internet, the old applicants should be required to meet the new policy. This is also true for strings not yet applied for in future rounds that may implicate similar policy issues.

02:01:40
@Donna but I don't think we can kill something like Merck. Hopefully buy next round that contention will be resolved but we can't just kill all the 2012 outstanding issues

02:01:58
So, if that's the case, I am happy with the language as it currently is as it relates to policy moving forward.

02:02:18
Merck is still a contention set AFAIK, so that should move forward.

02:02:45
1500 UTC on 10 February

02:02:50
We could face similar issues as are raised by 2012 applications not withdrawn when it comes to future application rounds.

02:02:50
@Susan, I agree, but what I'm hearing is that's not our issue to deal with.

02:03:00
What Anne said.

02:03:01
Bye for now

02:03:03
Thank you

02:03:03
thank you, Jeff

02:03:07
Thanks, Jeff and all, bye!

02:03:07
bye all

02:03:07
bye, thanks