Welcome to the New gTLD Subsequent Procedures Working Group call on Tuesday, 28 April 2020 at 03:00 UTC.

hello all

Link to document on screen here: https://docs.google.com/document/d/1kUlmZH8nxWTgfcRluA5FxLheMm4XhhOwkRt7om52aQU/edit#heading=h.ghi4hytcc3

Added language sounds ok to me.

allocatable is in fact a word

sounds good to me too

guidance, guidances or guidelines are all acceptable.

I think this is weird. The application should be on-hold, not go to contracting.

Yeap

“delegated” means added time the root?

added TO

they stuck forever

I believe the scripts where such similarity could happen already have RZ-LGR rules, like latin and cyrillic.

But in theory this could happen.

Seems unlikely, but would be bad news for someone else if they got caught up in it.

RZ-LGR: https://www.icann.org/resources/pages/root-zone-lgr-2015-06-21-en

down

how many years for a new table?

Along the lines of thought of Rubens and Maxim, are we giving applicants sufficient warning that contracting may be held up subject to RZ-LGR?

couple I think

back up

Maxim, that's usually dependent on number of volunteers.

there should be an explicit warning

I think it was around one or two years

just in Zoom chat and listen in mode apologies my clash is unavoidable

@Jeff, if what you say is the case, then why have this implementation guidance (rationale 2)? I think the explicit warning is warranted.

IDN tables are IDNs at second-level.

Here we are discussing IDNs at the root zone level.

Hand up

Yup, thanks @steve

IDN TLDs is a totally different subject from IDN Tables.

But Rubens said is also important - Top Level versus Second Level.

IDN tables apply to all TLDs, including ASCII non-IDN TLDs, as long as the registry offers IDN registrations.

*but what

No wording change, just to remind to not include IDN tables here.

@Rubens, does that mean the cross reference is not needed then?

Steve, that's correct.

Cool, thanks.

@jeff, can we say that in layman terms?

Re: Recommendation xx (Rationale 4)

Implementing this with different back-end RSPs would be a nightmare. If people feel the need I don't object to this language, but it's kinda like telling people to not shoot themselves in the foot.

@Rubens, isn't bundling part of the new IDN Framework?

@Justine, I am not sure. It's kinda likely indeed.

if they properly sync, why not?

Maxim, it's the same race condition that prevents a string from having more than one registry system at a time.

we should not prescribe too deep

agreed @Maxim

Thank you @Karen

a backend - is it a single entity? is it a single software platform?

https://www.icann.org/en/system/files/files/idn-variant-tld-recommendations-analysis-25jan19-en.pdf

@jeff, yes please!

it is just recommendation now

there are a few cases

It's being very prescriptive, but if the language brings comfort to people, I don't see a problem in having it.

a registry is a contract holder, could be a backend itself

@Alan, I prefer to think of this as something that we want to avoid from the outset rather than think of it as an edge case situation.

Sorry, old

But since Jim offers that there are a few cases, then it's certainly a loop we should close.

@Jeff, English please? ;)

@Jeff - why?

This is written in set theory, not in English, but that's a language more precise than English. ;-)

example, there are few scripts in a language, so the same entity for all versions of the same word

like word boot in different variations of the language

Well said, @Jeff

Thanks Jeff

It may be helpful to look a little closer at the rationale today!

Looks like we have 2 Rationales 5.

ICANN Org tried to force variants to have all the same name servers, so this recommendation prevents them from trying that again.

the last one is troublesome

how do we see contractual link?

The contract would need to encompass all strings in the variant set.

Different from the current model that is attached to a particular string.

And possibly, the set to be updated from time to time?

good point Maxim. Does bundling forever require co-existence of the variants forever?

it was a case of separate tlds

@Jeff, but could you retire a variant or are you stuck with it forever?

Paul, that's possibly something that the RO could specify in the RSEP request to stop variant X from being offered to new registrations.

Thanks Jeff. Thanks Rubens

@Paul, the variants do not all have to be active - however, if TLDs are delegated as variant labels based on the LGR, their status as variants would not change

we do not need to require killing all variants instead of retiring a single variant of a bunch

Thanks Karen!

in a case of different TLDs

@Jeff, might we need another Implementation Guidance regarding another RA Specification for IDNs?

IG doesn't have the "force" of a recommendation.

I don't think that any solution to this would be undesirable, so I don't think a new implementation guidance is needed.

there should not be bundled contracts of a different tlds

So while in the past I suggested for the WG report to be as defined as possible preventing IRT dead-locks, I don't think this one is needed.

those might be in a single hands

If the registrant wants that, so be it.

What if the registrant wants to transfer one of the second level variants? Will that be caught by the system and an auth code not issued?

registry can potentially regulate content, but we should not

FWIW, the approach is also consistent with the SSAC public comment on the subject.

As noted in the rationale

ICANN does not regulate content

Paul, a bundling system usually transfers all bundle members when one is transferred.

@Rubens - thanks!

hands up

please be very careful here

There are other cases of bundling besides IDNs, like .ong and .ngo.

It would be nice if RPM Phase 2 could address the bundled registration issue.

Hand up

The UDRP/URS issue is also discussed in the document i referenced earlier, fyi

Jeff, we can't hear you.

Have we wowed Jeff into silence? :)

UDRP is meant to address a large share of trademark issues, but there is always the possibility of only a court being able to settle a dispute. As long as UDRP keeps working for a near totality, it doesn't have to deal with all possible cases.

Do we have any statistics about the delegation rate/%/numbers in the last round?

here 5k delegations might stuck for years

we should not mix administrative bottleneck and security of the delegations

As I recall, the 1000 per year came from an ICANN operational assessment, which then served as the basis for security and stability considerations.

http://newgtlds.icann.org/newgtlds.csv can provide for many calculations

I am not sure expectations of 10k are real now

In this one, we should replace Verisign with Root Zone Manager.

It's currently Verisign, but we don't know whether this will change or not.

+1 , @Rubens

Support that change, Rubens.

+1 Rubens

emojis should be banned

All emoji submissions should be answered with :-(

an emoji of a flag would enrage a particular government

Yes, ban on emojis per SAC 095.

Security and stability used to be a much more expansive section

But parts of it got carved out, per section (d)

Looking at contract dates (which is not identical to adding to the root zone (and includes a few renewals for old TLDs), there were 510 in 2014 and 450 in 2015.

contact execution is an administrative bottleneck, not security one

Alan, there is a column in that table with delegation date.

contract execution :)

are we discussing the NCAP report or our work?

I wasn't looking at any table. List of contracts.

NEXT CALL: Thursday, 30 April 2020 at 20:00 UTC for 90 minutes.

we do not know how many years total ncap effort takes

all phases

so we do not need to include wording of before ncap ends

Thanks Jeff and all, bye!

Not to pre-empt @Maxim