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

21:09
hello all

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

27:35
Added language sounds ok to me.

27:48
allocatable is in fact a word

28:12
sounds good to me too

29:58
guidance, guidances or guidelines are all acceptable.

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

31:01
Yeap

31:10
“delegated” means added time the root?

31:32
added TO

31:35
they stuck forever

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

32:32
But in theory this could happen.

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

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

33:36
down

33:44
how many years for a new table?

34:02
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?

34:05
couple I think

34:14
back up

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

34:33
there should be an explicit warning

35:05
I think it was around one or two years

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

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

36:38
IDN tables are IDNs at second-level.

37:01
Here we are discussing IDNs at the root zone level.

37:25
Hand up

38:13
Yup, thanks @steve

38:25
IDN TLDs is a totally different subject from IDN Tables.

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

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

39:18
*but what

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

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

40:15
Steve, that's correct.

40:23
Cool, thanks.

43:03
@jeff, can we say that in layman terms?

43:29
Re: Recommendation xx (Rationale 4)

45:30
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.

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

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

46:54
if they properly sync, why not?

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

48:17
we should not prescribe too deep

49:02
agreed @Maxim

49:47
Thank you @Karen

49:48
a backend - is it a single entity? is it a single software platform?

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

50:22
@jeff, yes please!

50:45
it is just recommendation now

51:03
there are a few cases

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

51:33
a registry is a contract holder, could be a backend itself

51:40
@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.

52:16
Sorry, old

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

54:05
@Jeff, English please? ;)

54:38
@Jeff - why?

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

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

56:45
like word boot in different variations of the language

57:17
Well said, @Jeff

57:21
Thanks Jeff

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

58:34
Looks like we have 2 Rationales 5.

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

59:43
the last one is troublesome

01:01:32
how do we see contractual link?

01:02:31
The contract would need to encompass all strings in the variant set.

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

01:03:28
And possibly, the set to be updated from time to time?

01:03:28
good point Maxim. Does bundling forever require co-existence of the variants forever?

01:04:42
it was a case of separate tlds

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

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

01:05:42
Thanks Jeff. Thanks Rubens

01:06:03
@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

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

01:06:28
Thanks Karen!

01:06:39
in a case of different TLDs

01:06:49
@Jeff, might we need another Implementation Guidance regarding another RA Specification for IDNs?

01:08:05
IG doesn't have the "force" of a recommendation.

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

01:08:57
there should not be bundled contracts of a different tlds

01:09:30
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.

01:09:47
those might be in a single hands

01:10:46
If the registrant wants that, so be it.

01:12:47
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?

01:13:04
registry can potentially regulate content, but we should not

01:13:11
FWIW, the approach is also consistent with the SSAC public comment on the subject.

01:13:18
As noted in the rationale

01:13:34
ICANN does not regulate content

01:13:38
Paul, a bundling system usually transfers all bundle members when one is transferred.

01:13:48
@Rubens - thanks!

01:14:38
hands up

01:14:43
please be very careful here

01:14:43
There are other cases of bundling besides IDNs, like .ong and .ngo.

01:15:07
It would be nice if RPM Phase 2 could address the bundled registration issue.

01:15:24
Hand up

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

01:16:50
Jeff, we can't hear you.

01:17:00
Have we wowed Jeff into silence? :)

01:18:52
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.

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

01:26:07
here 5k delegations might stuck for years

01:26:54
we should not mix administrative bottleneck and security of the delegations

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

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

01:28:50
I am not sure expectations of 10k are real now

01:32:14
In this one, we should replace Verisign with Root Zone Manager.

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

01:33:14
+1 , @Rubens

01:33:40
Support that change, Rubens.

01:33:42
+1 Rubens

01:34:14
emojis should be banned

01:34:46
All emoji submissions should be answered with :-(

01:34:48
an emoji of a flag would enrage a particular government

01:35:18
Yes, ban on emojis per SAC 095.

01:36:28
Security and stability used to be a much more expansive section

01:36:39
But parts of it got carved out, per section (d)

01:36:47
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.

01:37:25
contact execution is an administrative bottleneck, not security one

01:37:25
Alan, there is a column in that table with delegation date.

01:37:41
contract execution :)

01:38:05
are we discussing the NCAP report or our work?

01:38:08
I wasn't looking at any table. List of contracts.

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

01:39:54
we do not know how many years total ncap effort takes

01:40:10
all phases

01:40:54
so we do not need to include wording of before ncap ends

01:41:19
Thanks Jeff and all, bye!

01:41:20
Not to pre-empt @Maxim