[ccPDP4-IDNWG] NOTES | ccPDP4 IDN Full WG (#42) | 4 April 2023 (13:00 UTC)

Tue Apr 4 14:30:01 UTC 2023

NOTES | ccPDP4 IDN Full WG (#42) | 4 April 2023 (13:00 UTC)

  1.  Welcome & roll call

Welcome by Chair Kenny

2.                   Admin matters

1.       Action Items

None. Bart updated the stress test doc as per ICANN76 discussions

2.                   Other admin matters (progress EPDP)

Dennis: About to finalise its phase 1 report. Will be published for public comments at the end of April. Document has been in production for over 1 year. Ensure that the language is consistent and clear. Differences between IDN EPDP and ccPDP4, when it comes to the introduction of variants.
Mostly in sync, but due to different working methods of ccNSO and GNSO and their nature,  there are differences. Nonetheless,  the recommendations are consistently similar. One item stands out: the one on grandfathering delegated TLDs.  ccPDP4 offers a caveat with grandfathering, related to security and stability issues.
Report: Aiming for publication on 24 April
Bart: could you please circulate the section about the differences between the 2 groups to ccPDP4, for their awareness? To ensure a coordinated approach
Dennis: yes
Bart: Q for Patricio. Is there an expectation that this group makes such an explanation?
About the differences between both policies
Patricio: the timeline that was established is centered around SubPro. Focus on the G-side, GNSO. There will be questions whether what ccNSO proposes is compatible with the GNSO efforts. Side by side comparison proactively would be very welcome
Anil: Ariel prepared section 5. Ask Ariel to share the complete doc. In light of the Board request. Differences are there, but we should be able to explain why.
Ariel: yes, can share today or tomorrow. Also provided analysis on whether the differences would be a problem, as per board request. Is there anything you want us to include in the report? Also, we are in a late stage of the process.
Bart: Question for Ariel. Initial report for public comment. Assumes that the WG will take onboard the public comments, but also has its own mandate to review what comes out? This is not the final outcome of the deliberations of the EPDP group?
Ariel: indeed. This is the initial report. Recommendations might be changed, following the public comments. No rush to comment now. There is the public comment period
Anil: question to Board liaisons. Because of scope limitations, some aspects not discussed. E.g. single character domains, time limit for submitting an application, second level.
Patricio: will review with Katrina after the call, and will answer accordingly.
Bart: meaningfulness criteria for IDN ccTLDs. We could check what would happen if we include it as a stress test.
Anil: yes.
Bart: what was meant by time limit?
Anil: how much time does it take to allocate a domain? Delegatable? Status of application
Bart: duration of validation process?
Anil: yes
Bart: let’s also include this as a stress test. Given the nature, there are caveats
Regarding second level, that is the scope of the ccPDP.

3.                   Stress testing

1.       Recap outcome from in-person meeting (ICANN76)

Updated, based on discussions in Cancun
Changes in yellow

2.                   Discussion stress tests

Bart: page 3. New stress test 7.a.
Assume a IDN ccTLD string is retired, because name of country changed significantly, and another country wants to have the ccTLD. Should it be available in 2 years?
Hadia: makes sense to have cooling down period.
Anil: logical. Range of 10 to 25 years.
Mirjana: was my proposal to include this as a stress test
We need a cooling down period. Suggests at least 25 years.
Anna: very long, generation change. Suggests 30 years
Hadia: 50 years is long. Base for our decision is to follow ISO3166. Base requirement for delegation. What is a good period, and what is good for what?
Jaap: it depends. Example 2 names with “Congo” in it. Hard to put a strong requirement. A “should” is preferable, not a “must”
Bart: final sentence in direct quote. Use of former code element
Jaap: recently a code was re-used sooner. But no-one noticed. Hardly used. Some codes were never delegated.
Bart: suggestion is to include a cooling down period. Duration to be determined.
Do you agree to introduce one? Green marks
Peter: confused. I thought we discussed this a while ago. Scarcity in iso standard is not necessarily here the case, in the idn world?
Bart: rather to limit the duration of the exclusion. Not indefinitely, because of scarcity reasons. To avoid confusion, have a cooling down period
Peter: ok. Undecided
Jaap: this is about the IDN string. Problem is more sensitive. Depends on context. Some 2-letter codes lives on in airline industry
Patricio: has to do with avoiding confusion. However long the cooling down period, leave room for exceptions.
Bart: another question. Iana should not be in the position to decide what is and what is not a country. Mechanism for in-territory string selection. Should ICANN decide the reasonable timeframe? Should it be left to others?
Mirjana: difficult question. Experience from czechowlakia domain at the time. Suggestion to have a a Committee to judge without prejudce.
Anil: what is meant by leaving it to ICANN?
Bart: policy recommendation directed at icann and the board. They would play the role of the maintenance agency
Anil: should be recommended by PDP.
Bart: alternative - another institution to determine. Or follow the standard itself. (the decision by the Maintenance Agency)
Kenny: difficult question, as we do not have the context to determine the variable. No control over the list maker. We could have a conditional assumption. E.g. 15 or 30 years. And providing the condition is not changed. (not delegated)
Mirjana: ICANN not to decide on what should be done.
Bart: someone needs to assess whether the conditions are met.
Jaap: the names of the countries are not decided by MA. they might change overtime, while the code remains the same
Jiankang: icann is not the decision maker. ccPDP creates policy. ICANN executes. If there is no such policy, ICANN cannot act. Another PDP cycle?
Bart: suggestion to leave it for the time being. However, to determine the details, the suggestion is to launch a new ccNSO PDP?
Jiankang: yes.
Bart: topic to be revisited at the next meeting.
Page 4
Peter: agrees with was is written. Cooling down would only apply to delegated strings? But not those that are potentially delegated? Part of a variant set?
Bart: always linked to the name of the country. To avoid people game the system?
Peter: check. Miliciouslyt or by accident
Mirjana: if the main label is retired, all variants should be retired. So also in this case, treat them the same
Bart: all derived from the selected tld string.
Peter: academically interesting corner case. Given that the variants are non-symmetric, in combination with the retirement and cooling down of a variant that has not been delegated … there could be strange effects.
Referring to Michael. Think about it off-list.
Bart: following Mirjana’s argument. Cooling down applies to them too.
Peter: but is there over-blocking in that case?
Bart: easy, and addresses the issue.
Bart: item 9. Typo faith/fate, degatable/delegatable
Anil: add one line. In the new scenario AA should follow the same criteria. Country code, script, language and support of the SIP.
Bart: suggests to include this. First reading. Will include it in the next version.

Patricio: island example. conclusion different in this case
Bart: in principle removed, but if the new territory and SIP support the IDN ccTLD string, why remove it?
Assume it should be removed, and it is a supported idn cctld string after the merger, with the cooling down period.
Patricio: this assumes that the gvt of the country agrees
Bart: hence the reference to the SIP. as defined by the FOI. always includes the gvt
Patricio: if there is no unanimous agreement, it will not be done against wishes of the gvt?
Bart: definitely. See FOI
Peter: reattaing idn string to other ISO code. Pre-condition, other would not have an IDN of its own. If DE would have another IDN, that script would have been used up. The old one could not have been reattached without violating the principle of one string per …
Bart: in this example there has not been an IDN ccTLD for the original one.
Peter: Germania would have blocked this.
When we rephrase, be careful that even with this merger, you can only fill your slot once
Bart: only one IDN ccTLD string. Add. this applies too
Question for Irina. Do you agree? You raised this?
Or do you wish to see the text first?
Bart: we move on, and revisit this again. We add the point that Peter raised.

Number 17
Bart: revisit next time. Dennis raised this, and he had to leave for another commitment

Number 18
Hadia: possibility to serve the community through gTLDs. There is always another path.

4.                   Next meetings

1.       Full WG stress testing (18 April, 2 May | 13:00 UTC)
2.       Full WG discussion updated policy document (11 April, 25 April, 9 May | 13:00 UTC)

5.                   AOB

None

6.                   Closure

Thank you all

Joke Braeken
joke.braeken at icann.org<mailto:joke.braeken at icann.org>

ICANN77 links to bookmark now

  *   ccNSO Schedule
https://community.icann.org/x/IQM5Dg<https://community.icann.org/x/8IMFDQ>

  *   ccNSO Session Highlights
https://community.icann.org/x/RgI5Dg<https://community.icann.org/x/kYYFDQ>

  *   Tech Day
https://community.icann.org/x/MAM5Dg<https://community.icann.org/x/WIQ-DQ>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mm.icann.org/pipermail/ccpdp4-idnwg/attachments/20230404/922e0994/attachment-0001.html>