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

Please note: raised hand option has been adjusted to bottom tool bar/ reactions section.

Hello all

Welcome Maxim

CAn you give us access to put comments in the mapping document?

Right now we only have view only

+1

Mapping doc: https://docs.google.com/spreadsheets/d/1jQrzU9NDOlMwNw4zFcndOFEYhSIo3EAXAHTVirsMup8/edit#gid=0

done

thanks!

FYI, it appears all of the IDN recommendation from SubPro have Full Consensus

this is just a mapping document i understand, and the "extracts" are taken from the various documents (and each box is inevitably "out of context")

I think there are questions related to how to deal with legacy TLDs

Yep

then we need to ensure no old TLD is out of compliance on this

then this might need to be redirected clearly

subpro was intended to regulate future

but no new TLDs are expected from the past

one example could be the application of variant TLD labels from existing TLDs

but it will be a future TLD item

so it will be regulated, not the old one

and nothing prevents ICANN from not launching the new one until all things are sorted out in both

@Dennis correct. But the WG needs to understand that recommendations dealing with the past must be "Consensus Policies" which are a higher standard than what can be approved for TLDs in the future

then a disclaimer might be added - that additional consideration is required , where the legacy (not future TLDs ) are might be affected

are all existing TLDs compliant with RZ-LRG rules?

For the RZ-LGR scripts finalized, yes.

but is it 100%?

of all TLDs?

to avoid situation where a live TLD is killed for the sake of RZ-LGR

most probably the situation where TLD1 is from the past is a variant of the TLD2 from the future - should be reviewed

we need to mark it somewhere , to avoid forgetting it

What Maxim discussed would likely be part of the discussion/deliberation of the future EPDP. This group is to focus on developing charter questions that would help facilitate future discussion on this, in terms of how to deal with current/existing TLDs

i think we should avoid the term "apply for" for variant TLDs for the current TLDs (or future for that matter)

@Ariel, I think it might be important in terms of what the future group does/does not

new TLDs are always apply for

Yes, hence the aim is to draft the charter questions in a precise manner

on hold after passing the application is way better

"apply for" should be used for "the" TLD and "request" or some other term should be used for "activation/use" of a variant TLD

but the notification should be given in advance

the Council does not have reasons to say that SubPro materials are not good so far

There is a point there though in pointing out how this was arrived at

I'm not talking about 'confirming' but rather 'acknowledging'

it is more about a ‘hold’ tag, than about competitor application TLDs

not processed = the dead application

i thought that was "not proceed"

but anyway its fine :-D

i think subpro's recommendation is good

it might be more clear when we look a the draft charter text

Yes, it would be helpful for the DT to point out whether the charter questions are clearly drafted to reflect the discussion here and include necessary context. This table is to show potential gap that may need to be addressed

By the way, the TSG was not a policy group

+1 it was not

just an interest group

And what to do with an application is NOT a technical question at all

In other word, it may be more efficient to discuss the substance when we are reviewing the draft questions wording

This is an area where I agree about the GAP and that it must be considered by this ePDP

am I only one who looses audio of Dennis?

Dennis your audio is breaking up

I did not hear last 2 minutes

dial out?

old

I did not hear your sentences

I think Maxim’s comment may be reflected in this draft charter question c4: c4) [Implementation Question] Taking into consideration the circumstance noted in a6), it is possible that two or more previously delegated independent TLDs are found to be variants of each other under RZ-LGR but they are not operated by the same Registry Operator (or back-end registry service provider). How to remedy such a situation so that the “same entity” rule is followed?

Agree that the WG needs to look at existing TLDs

another issue is same entities for a domain (old TLDs )

But for future TLDs, no need

new hand

I agree with the GAP in 9. In 8 I think Questions 2 and 3 will be implementation of SubPro for future TLDs.

variants SLDs of variant TLDs :)

yes

By manage, you also include bundling or blocking?

both i think

it should be reflected (researched)

@Edmon, right. I can't imagine there are actually existing TLDs in the root that are variants of each other? And then I can't imagine within that edge case, that there are different operators. It just seems so remote to have already happened and no one has noticed

.CHINA and .TAIWAN

are the only ones but they are not gTLDs

then all TLDs should be checked for existence of such collisions

How are .china and .Taiwan variants?

sorry the Chinese version

Next meeting: The IDNs EPDP Charter Drafting team Group call is scheduled on Tuesday, 19 January 2021 at 18:00 UTC for 60 minutes.

SimplifiedCHINA and traditionCHINA

we can not speak about politics here :)

etc.

This has been captured in the “Data & Metrics” section in the charter — Number of labels generally deemed as the same (e.g., variant TLDs under RZ-LGR) that were previously delegated in the root zone as independent TLDs or were reserved names (a6, c4)

Thanks Dennis

thanks all

.<chinaInTraditionalChinese> and .<chinaInSimplifiedChinese>

bye

sorry for the confusion

Thank you

thx bye