Hi Maxim

Please review ICANN Expected Standards of Behavior here: https://www.icann.org/resources/pages/expected-standards-2016-06-28-en

I have a small SOI update

Hello everyone

I am going to update SOI on the web as soon possible

https://docs.google.com/spreadsheets/d/1YJJDm9mdmSssXav1P08Uhw6Ofyp0KtfTX8QSRChrVNI/edit#gid=2136691260

yes please state the point re IRt and Predictability framework

Who are the ‘Article 19 Group’. ?

https://www.article19.org/

Thanks Emily!

it closed on Nov 23

@Emily - I'm a bit confused in that the Google doc link you sent does not appear on my screen to include Comment 6 in red?

I mean Comment 6 and 7. of Leadership are not appearing in the linked doc at all?

Hi Anne, are you on the tab for Topic 26?

yes indeed. Maybe it's just the way it is displaying on my screen. I do see it on yours. Thank you

How odd . . .

@Anne, maybe try refreshing the Google sheet?

When I set it to 75%, I can see it.

yes - have to click on the column then use the scroll bar that appears

yes - like .onion

https://www.icann.org/en/system/files/files/octo-015-01oct20-en.pdf

special use TLDs

Recommendations forEarly Warning for RootZone Scaling

No. So far so good @Jeff.

@Jeff - we should update the report as to the current status of Study 2. We should reflect the fact that the Board will not be acting on Study 2 until after the issuance of the Final Report and we should say our recommendations could be affected by further Board actions.

It will act one way or the other.

OK thanks

Avri and Becky said they wanted the responses in the Deliberations sections of the Report.

rationale

That's right Paul - forgot about that. So it should be in the report

ncap is not a show stopper

also it is a kind of fishing expedition - one of the answers of SSAC on the nature

there were no consesus about that

agreed maxim

there are other SGs, who do not share the opinions

https://www.icann.org/en/system/files/correspondence/chalaby-to-drazek-et-al-01nov19-en.pdf

but the group actually doing that work doesn't Anne. Isn't that far more relevant?

@Susan - It all depends on Board action. And the Board will avoid making policy and delays can result where policy-making is involved. It could end up being a dependency and it will delay the next round if sp.

Study 1 has been done for quite some time and NCAP has moved on to the other studies.

I would not characterize NCAP as a “fishing expedition.”

those were words of Rod at the webinar

I suppose the question is whether this is intended to be pejorative in our discussion.

without a proper timeline, it makes an unpredictable delay

I am not saying it should be stopped, just it should not be waited for

I think the relevant issue for us is how do we address community efforts and recommendations that may come after we have concluded our work? Notwithstanding NCAP is the issue we are discussing now, there is potential for other subjects to collide in some way with our recommendations. So wouldn't it be prudent for us to have a high level discussion about how to account for those situations? The recommendation from leadership on this topic may be appropriate more broadly.

We have not said there is consensus. . There is already SAC Advice on its view of the dependency and the ALAC keeps making this point. I agree with Greg that the tenor of the discussion is not neutral. I wish we could be more practical about how we will resolve issues when the Board kicks policy back to GNSO on name collisions. Right now we make it a big open question as to how it will be handled. We have said ICANN should develop a test for which strings can be delegated How is that going to happen if not through NCAP?

NCAP is an approved effort, but there is no reason to stop the next round because of it

there are many ways to do the same thing, not limited to NCAP

status quo is controlled interrupt ion

there is no records of some issues not prevented by the controlled interruption

then the community will ask, if there is no new ideas - why not doing it the same time as the last time

How was it decided that .home .mail and .corp had a high likelihood of name collision.

My sense is this would have to factor into the Board's Operational Design Phase analysis.

there was a first bite on name collision s- JAS teport

report

I don't think all of us agree that this is an actual high risk area...

We can draft something to redline

I agree on that point Paul

completely agree Paul. work was done on name collisions before the 2012 round, some strings were rejected. controlled interruption has worked.

@Paul - there is a consensus in the Report that ICANN should have a test to avoid needless applications for high risk strings.

3 out of w thousands

it is less than 0.1% of strings

or around that

Is that a relevant statistic?

Seems like some of the ghosts would have shown up by now. It's been 10 years.

3 names out of 2 thousands

Thanks Jeff. Hard to make Policy on non-public data. My point is we just need to keep this issue in its proper perspective.

not all ICANN platforms fully UA comliant ;)

compliant

the problem is in large mail platforms

they use different standards

But most are and there is a plan for full compliance I thought Maxim

Here is the link to the document on display: https://docs.google.com/spreadsheets/d/1bxEnuFrtI7996NnGPMR00JEwM6KK5m8Y_AGpSwqfi1o/edit#gid=123470843

it is an idea, not implemented same way

Yes UA is NOT a mere IDN issue

@ Donna: True -- longer TLDs have had issues with UA

also there is no control over how computer languages are written and libraries

which is highly UA relevant

Agree, Maxim

You just answered my question Cheryl. So if the metrics is already being collected can those be referred to? And I also don't think that promotion of UA readiness is a bad idea, notwithstanding Jeff's point that much of the problem is outside registries and registrars.

and note too that the current focus on UASG work also includes provision of a lot of education material for implementation that should be activt aroind the timing of the next round as well Data captured therefore will be usefil (and interesting to some of us)

Can't we compel ICANN org to ensure that it is fully or more UA-ready?

https://docs.google.com/spreadsheets/d/1PglquKDd8amHiqI6Wfko0Plb80RPpbEjTMS_F-5t4sU/edit#gid=1163822586

@Justine here is the case study on ICANN org, also describes the how work on UA-readiness is organized

https://uasg.tech/wp-content/uploads/2020/03/UASG_ICANN_Case_Study_UASG013C.2.pdf

Thanks @Karen

Thanks @Karen I tried to aluude to that work plan :-)

+1 Susan. Road well traveled, I think. Also agree that until there are real protections for .brands (i.e. ICANN has to do a trademark search before it sells a TLD to someone that contains someone else's brand) in this program, we don't want to be dictating how much "use" a .brand needs to undertake. Keeping your brand from being squatted to death is a very important use.

many applicants changed back ends right before the launch, so it caused some delay

+1 @ Susan

bye all, have to drop

Thanks for joining @Maxim

20:00 UTC

“Use” has always been a problem, very difficult to find the right solution here

Monday, 07 December 2020 at 20:00 UTC

Next topics: Topic 18: Terms and Conditions; Topic 22: Registrant Protections; Topic 7: Metrics and Monitoring; Topic 23: Closed Generics

Good progress team, remember to keep reviewing redlines as they come out as well and all the email interaction opportunities :-)

These will be sent shortly with the agenda.

Bye for now … Thanks again everyone!

Thanks Jeff, Cheryl et al