hi 2 all

Good evening from San Francisco!

and of course at this stage the specifics of any schedules for Virtual ICANN 67 remain unknown (with lots of moving parts still being sorted out still)

if the sessions start before 2pm ET - European participation will be low. (I personally reside in Florida - so it doesn't impact me.)

Im not so sure having a few hours of bilats with the GAC qualifies as full discussion - but one can hope.

I think the way to have timely advice is to qualify advice the Board is expected to accept, like being Consensus Advice and Timely Advice.

The GAC session dedicated to SubPro learning was scheduled for Saturday 7 March. Details on GAC website.

uuups. i was off with ET.... still thinking in European time

So this puts an incentive to follow the program timeline.

+1 Rubens

The virtual meeting hours will be 14:00 - 22:00 UTC.

9-5 EST/Cancun time

Google doc available here: https://docs.google.com/document/d/1kUlmZH8nxWTgfcRluA5FxLheMm4XhhOwkRt7om52aQU/edit#

Literally midnight to Dawn for some of us

@CLO Like shift work.

Except the normal day shifts and demands also continue

Cheryl, are there werewolves in Australia at those hours ?

so more like double shifts+

naa @Rubens the Drop Bears sorted them all out ages ago ;-)

Nurses work double shifts...but get paid.

they don't od it 5 days in a row Tom

And get time off after shifts.

Page refreshed…comment from Kathy is there now

I wouldn't mind still having the week after virtual ICANN67 off to recover from 7 days of double shifts. Sigh.

My memory is that we had the same voices over and over disagreeing, not a WG disagreement.

@Justine - I was going to say - we may be even more fried from this meeting because of time zones and the challenegs of trying to be focused online for long stretches

I can bore people with the effects on the ACH (Adreno Cortisol stress hormone system) on short term but sustained interruptions to normal D=diurnal cycles is on the average human over a libation anytime any of you want to pick my "stress physiologist& qualified brain (pun intended with all the brains I 'picked' in my PhD studies ;-)

@Justine - agreed!

Consistency is key yes @Alan

So let's ask for the public to help us with this issue.

Lots of government agencies deal with this issue...

ICANN already has to identify corporate trees when it onboards a TLD. So that implementation already exists.

Registry, registry, registry

What is the "Public Interest community"?

can you put the link for this document into chat?

Sure: https://docs.google.com/spreadsheets/d/15zDdzlBwLCz5m2sNXui6N6pporbUq-lDFEwfh4rKi4A/edit#gid=2145886643

Public Interest Community is mostly NCSG familiar faces.

if there isn't consensus - we could at least try to NOT make it easier to have a DNS-land mass-grab.

I think the way it is worded now i sjust fine

The conditions for new entrants should not be determined by incumbents.

Old hand

Alexander, competition authorities are still out there and can intervene.

@Rubens ICANN itself is the competition authority.

Agree with Anne

CW, that's not true. Look at RSEP, where ICANN refers competition issues to competition authorities. ICANN has no legal standing to declare itself a competition authority.

Good point.

interesting discussion

I believe the recommendation has to reflect the totality of the discussions. That should include dissenting opinions to what the recomendations states. Is there room in C for that?

Minority reports exist to be the vehicle to disagreements.

@Jim - that's precisely where that belongs...in deliberations.

just spell it correctly Jeff

I'm pretty sure we all know the themes that will have minority statements many years back.

So it the objection to "The WG believes .."?

*So is ..

That is what I am hearing @Justine

and a desire to recognise the feasibility limitations of imposing any limits

In this case we don't need the Newmann rule; there is rough agreement.

Neumann...

Neuman :)

New Man

There is no fun in writing Jeff's name right.

ultimately the Working Group concluded that there were no effective, fair and/or feasible mechanisms to enforce such limits. It therefore concluded that no limits should be imposed on either the number of applications in total or the number of applications from any particular entity.Screen reader support enabled.

yes, provided we hone very close to 2.2.5.c.1

That would be a better reflection, tx.

Why don't we want to put limitations for Application Submissions?

"Even those that supported limitations, recognised that there were no effective, fair or feasible mechanisms to do it."

That's what our report says...

There is no such dependencies in the comments made by HUGE chunks of the GNSO that took the time to submit comments and positions. We should not rewrite history.

No one has come up with nothing near a hint of how to limit.

I don't think the status quo comes into play here.

@Kathy - and then there was public comment following on from the initial report. Unless you are suggesting that preliminary reports always govern and public comments should be ignored. But I know you better than that - you don't believe that. Comments matter, especially when they are overwhelmingly pointing us in a single direction.

We're not rewriting history with 2.2.5.c.1

The CQs phrase is backwards.

Cause x consequence

Just the wording

To the list later

question

Applicant comments: If ICANN can do all that to check ownership of Comments, then surely ICANN can do that equally well for the ownership of individual applications.

Or remove the responsible party?

Exactly Jeff

I've sent suggested wording to the list.

But no one would know...

Kathy, one issue is when the relationship between comments and change is not biunivocal.

Just a notification period about a change being posted...

But we could notify all people that commend on one application that there was a change in the application due to one application comment, but not necessarily that person's comment.

So this wouldn't be an unsolvable matrix problem, but a simpler guidance.

[ x ] I want to be notified if the application is changed

Shall we put it here too....

Implementation Guidance on Systems: IRT to look into rolling up a sign-up mechanism to be alerted by email on any part of an application that is updated.

*rolling out

right!

Tx!

It sounds contradictory to the other recommendations.

Why would we change direction at this late hour?

So we either strike them, or keep them. But the two are incompatible.

Should seek true identity but not necessarily publish it?

@Justine - I don't think that does it. The motives of the commenter are important.

Its an enormous burden to identify yourself?

It's an enormous burden to confirm identity.

My name is Paul McGrady.

@Rubens - ha!

That's great -- I was not sure. Tx for the discussion!

We could avoid disposable e-mail addresses, which is feasible to implement.

All good!

I said "seek" true identity not "verify", so not sure where I differed on this discussion.

Good to know, on CPE comments.

May you share again the link for Workplan please?

Sure: https://docs.google.com/spreadsheets/d/1SN8GX1nVER30p_VmX1fAEJUTRLByXhrI96kpdGw8VYk/edit#gid=839727774

Thanks

Good night, good morning!

Thanks everyone excellent progress today: -) bye for now...

Bye all!

Thanks everyone!

Thank you

bye