Logo

Terri Agnew's Personal Meeting Room
Julie Bisland
18:47
Welcome to the New gTLD Subsequent Procedures Working Group call on Tuesday, 28 April 2020 at 03:00 UTC.
Maxim Alzoba
21:09
hello all
Steve Chan
25:33
Link to document on screen here: https://docs.google.com/document/d/1kUlmZH8nxWTgfcRluA5FxLheMm4XhhOwkRt7om52aQU/edit#heading=h.ghi4hytcc3
rubens
27:35
Added language sounds ok to me.
Jim Prendergast
27:48
allocatable is in fact a word
Robin Gross
28:12
sounds good to me too
Jim Prendergast
29:58
guidance, guidances or guidelines are all acceptable.
rubens
30:32
I think this is weird. The application should be on-hold, not go to contracting.
rubens
31:01
Yeap
Elaine Pruis
31:10
“delegated” means added time the root?
Elaine Pruis
31:32
added TO
Maxim Alzoba
31:35
they stuck forever
rubens
32:14
I believe the scripts where such similarity could happen already have RZ-LGR rules, like latin and cyrillic.
rubens
32:32
But in theory this could happen.
McGrady
32:32
Seems unlikely, but would be bad news for someone else if they got caught up in it.
karen.lentz
32:37
RZ-LGR: https://www.icann.org/resources/pages/root-zone-lgr-2015-06-21-en
Jim Prendergast
33:36
down
Maxim Alzoba
33:44
how many years for a new table?
Justine Chew
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?
Maxim Alzoba
34:05
couple I think
Jim Prendergast
34:14
back up
rubens
34:29
Maxim, that's usually dependent on number of volunteers.
Maxim Alzoba
34:33
there should be an explicit warning
Maxim Alzoba
35:05
I think it was around one or two years
Cheryl Langdon-Orr
35:48
just in Zoom chat and listen in mode apologies my clash is unavoidable
Justine Chew
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.
rubens
36:38
IDN tables are IDNs at second-level.
rubens
37:01
Here we are discussing IDNs at the root zone level.
Steve Chan
37:25
Hand up
Justine Chew
38:13
Yup, thanks @steve
rubens
38:25
IDN TLDs is a totally different subject from IDN Tables.
Justine Chew
38:54
But Rubens said is also important - Top Level versus Second Level.
rubens
39:18
IDN tables apply to all TLDs, including ASCII non-IDN TLDs, as long as the registry offers IDN registrations.
Justine Chew
39:18
*but what
rubens
39:56
No wording change, just to remind to not include IDN tables here.
Steve Chan
40:07
@Rubens, does that mean the cross reference is not needed then?
rubens
40:15
Steve, that's correct.
Steve Chan
40:23
Cool, thanks.
Justine Chew
43:03
@jeff, can we say that in layman terms?
Justine Chew
43:29
Re: Recommendation xx (Rationale 4)
rubens
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.
Justine Chew
46:07
@Rubens, isn't bundling part of the new IDN Framework?
rubens
46:46
@Justine, I am not sure. It's kinda likely indeed.
Maxim Alzoba
46:54
if they properly sync, why not?
rubens
47:28
Maxim, it's the same race condition that prevents a string from having more than one registry system at a time.
Maxim Alzoba
48:17
we should not prescribe too deep
Cheryl Langdon-Orr
49:02
agreed @Maxim
Justine Chew
49:47
Thank you @Karen
Maxim Alzoba
49:48
a backend - is it a single entity? is it a single software platform?
karen.lentz
50:00
https://www.icann.org/en/system/files/files/idn-variant-tld-recommendations-analysis-25jan19-en.pdf
Justine Chew
50:22
@jeff, yes please!
Maxim Alzoba
50:45
it is just recommendation now
Jim Prendergast
51:03
there are a few cases
rubens
51:19
It's being very prescriptive, but if the language brings comfort to people, I don't see a problem in having it.
Maxim Alzoba
51:33
a registry is a contract holder, could be a backend itself
Justine Chew
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.
karen.lentz
52:16
Sorry, old
Justine Chew
52:30
But since Jim offers that there are a few cases, then it's certainly a loop we should close.
Justine Chew
54:05
@Jeff, English please? ;)
McGrady
54:38
@Jeff - why?
rubens
55:39
This is written in set theory, not in English, but that's a language more precise than English. ;-)
Maxim Alzoba
55:57
example, there are few scripts in a language, so the same entity for all versions of the same word
Maxim Alzoba
56:45
like word boot in different variations of the language
Justine Chew
57:17
Well said, @Jeff
McGrady
57:21
Thanks Jeff
Steve Chan
58:22
It may be helpful to look a little closer at the rationale today!
McGrady
58:34
Looks like we have 2 Rationales 5.
rubens
59:13
ICANN Org tried to force variants to have all the same name servers, so this recommendation prevents them from trying that again.
Maxim Alzoba
59:43
the last one is troublesome
Maxim Alzoba
01:01:32
how do we see contractual link?
rubens
01:02:31
The contract would need to encompass all strings in the variant set.
rubens
01:03:01
Different from the current model that is attached to a particular string.
Justine Chew
01:03:28
And possibly, the set to be updated from time to time?
McGrady
01:03:28
good point Maxim. Does bundling forever require co-existence of the variants forever?
Maxim Alzoba
01:04:42
it was a case of separate tlds
McGrady
01:04:54
@Jeff, but could you retire a variant or are you stuck with it forever?
rubens
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.
McGrady
01:05:42
Thanks Jeff. Thanks Rubens
karen.lentz
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
Maxim Alzoba
01:06:10
we do not need to require killing all variants instead of retiring a single variant of a bunch
McGrady
01:06:28
Thanks Karen!
Maxim Alzoba
01:06:39
in a case of different TLDs
Justine Chew
01:06:49
@Jeff, might we need another Implementation Guidance regarding another RA Specification for IDNs?
Justine Chew
01:08:05
IG doesn't have the "force" of a recommendation.
rubens
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.
Maxim Alzoba
01:08:57
there should not be bundled contracts of a different tlds
rubens
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.
Maxim Alzoba
01:09:47
those might be in a single hands
rubens
01:10:46
If the registrant wants that, so be it.
McGrady
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?
Maxim Alzoba
01:13:04
registry can potentially regulate content, but we should not
Steve Chan
01:13:11
FWIW, the approach is also consistent with the SSAC public comment on the subject.
Steve Chan
01:13:18
As noted in the rationale
Maxim Alzoba
01:13:34
ICANN does not regulate content
rubens
01:13:38
Paul, a bundling system usually transfers all bundle members when one is transferred.
McGrady
01:13:48
@Rubens - thanks!
McGrady
01:14:38
hands up
Maxim Alzoba
01:14:43
please be very careful here
rubens
01:14:43
There are other cases of bundling besides IDNs, like .ong and .ngo.
rubens
01:15:07
It would be nice if RPM Phase 2 could address the bundled registration issue.
Steve Chan
01:15:24
Hand up
karen.lentz
01:15:37
The UDRP/URS issue is also discussed in the document i referenced earlier, fyi
rubens
01:16:50
Jeff, we can't hear you.
McGrady
01:17:00
Have we wowed Jeff into silence? :)
rubens
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.
Alan Greenberg
01:23:39
Do we have any statistics about the delegation rate/%/numbers in the last round?
Maxim Alzoba
01:26:07
here 5k delegations might stuck for years
Maxim Alzoba
01:26:54
we should not mix administrative bottleneck and security of the delegations
Steve Chan
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.
rubens
01:27:37
http://newgtlds.icann.org/newgtlds.csv can provide for many calculations
Maxim Alzoba
01:28:50
I am not sure expectations of 10k are real now
rubens
01:32:14
In this one, we should replace Verisign with Root Zone Manager.
rubens
01:32:33
It's currently Verisign, but we don't know whether this will change or not.
Maxim Alzoba
01:33:14
+1 , @Rubens
Robin Gross
01:33:40
Support that change, Rubens.
Justine Chew
01:33:42
+1 Rubens
Maxim Alzoba
01:34:14
emojis should be banned
rubens
01:34:46
All emoji submissions should be answered with :-(
Maxim Alzoba
01:34:48
an emoji of a flag would enrage a particular government
Justine Chew
01:35:18
Yes, ban on emojis per SAC 095.
Steve Chan
01:36:28
Security and stability used to be a much more expansive section
Steve Chan
01:36:39
But parts of it got carved out, per section (d)
Alan Greenberg
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.
Maxim Alzoba
01:37:25
contact execution is an administrative bottleneck, not security one
rubens
01:37:25
Alan, there is a column in that table with delegation date.
Maxim Alzoba
01:37:41
contract execution :)
Jim Prendergast
01:38:05
are we discussing the NCAP report or our work?
Alan Greenberg
01:38:08
I wasn't looking at any table. List of contracts.
Julie Bisland
01:38:09
NEXT CALL: Thursday, 30 April 2020 at 20:00 UTC for 90 minutes.
Maxim Alzoba
01:39:54
we do not know how many years total ncap effort takes
Maxim Alzoba
01:40:10
all phases
Maxim Alzoba
01:40:54
so we do not need to include wording of before ncap ends
Robin Gross
01:41:19
Thanks Jeff and all, bye!
Justine Chew
01:41:20
Not to pre-empt @Maxim