[ccPDP4-IDNWG] NOTES | ccPDP4 | 16 May 2023 (13:00 UTC)

Tue May 16 14:34:51 UTC 2023

NOTES | ccPDP4 | 16 May 2023 (13:00 UTC)

  1.  Welcome

Welcome by Kenny

2.                   Admin matters

a.                  Action items (Update document)

Circulated last week

b.      Progress Confusing similarity consolidation

Bart: invites all to review Irina’s document
Anything you want to discuss next week?
Would be good to close CS next week. That will allow us to start with the stress-testing on CS. Bart will introduce next week also the additional paragraphs. That allows you to have a good sense of the document, before ICANN77.
Irina: Apologies, I just realized I sent the doc with my comments to Bart only, not to the entire list
Bart: thanks, will recirculate.
Section 5.3 to 5.8

3.                   Stress testing document

a.                  Run through test for second reading 17-28

Bart: discussion why we need a cooling down period. Experience has shown that domain names have a long TTL. cashing. To avoid collision in future, the suggestion is to have a cooling down period of at least 10 years.
Peter: technically, this is not about “DNS caching”, but external references to that domain name, say in URLs
Irina: Assessment column needs to be updated accordingly
Peter: i like the adjustment
Irina: looks good. (apart from assessment column)

>>> Number 17, 18, 19: confirmed in 2nd reading

>>> Number 20: new

Irina: question
Bart: might be confusing. According to the basic criteria. Then variants. Can stress the bit in the assessment itself. Should I strike?
Irina: let’s avoid confusion for the future. Please strike
Bart: do you support?

Michael: similar-looking. Almost confusingly similar
Bart: use this as scenario when we discuss CS
Dennis: the 2 applicants apply at the same time? It is not clear here. If that is the case, the 2 are eligible. As a scenario. If one of them is incumbent, it is another story.
Bart: will include another scenario for next time.
Peter: had a discussion that resulted in 20a. Did we miss something? What is the distinction with 20?
Bart: Confusingly similar, but not a variant. That is 20a.
Peter: in that case we need to review the description in 20a
Bart: yes
Michael: yes.

>>> Number 21
Bart: questions or comments? None
Dennis: assessment column is not consistent with how the scenario was set up.
Peter: question regarding roles
Pitinan: the community RZ-LGR is not often updated. Conservative approach. If there are updates in the future, they try to make it backward compatible. If there is an impact, it is carefully considered.
Bart: if such an event occurs in future, will the RZ-LGR be informed about a potential collision?
Pitinan: let’s revisit when Sarmad is here too. To date only integrated new scripts in RZ-LGR, or corrected typos. There is always a public comment period
Bart: (IDN) ccTLD managers are advised to look at public comment.
Is a reference to that point sufficient?
Peter: external reference to our policy doc. We cannot solve it. Dependencies.

>>> Number 23
Irina: regarding the assessment. I do not see a clear answer to the scenario?
Bart: basic point. A new application round starts
Hadia: we need to make it more explicit.
Dennis: agree
The outcome is consistent with GNSO EPDP

>>> Number 24

Hadia: my question is about. Variants can only be applied for after the primary string was delegated. That means…
Bart: assumption throughout the VM that IDN ccTLDs, the selected string, and the delegatable variants will always be requested at same time. However, it was already delegated. One of them requests a delegatable variant. How does that work?

>>> Number 26

Irina: could this happen or not?
Bart: needs to be rewritten. if the delegation is requested before
New text: “What if the delegation of a Delegatable variant IDNccTLD string is requested before the delegation of  the Selected IDNccTLD?”
Bart: is this a concern?
Irina: the selected string should always be delegated first, and only then
Dennis: when a string is delegated to a registry operator, they have to delegate within a time frame. That is not the case with the ccnso?
Apply, but never delegate if they choose to do so?
Bart: slightly different. In the past there were some cases where it took time before the string was delegated (2 or 3 years). Board resolution.
Dennis: that clarifies matters.
Peter: want to see text first
Bart: not yet 1st reading, just direction of travel
Do you have concerns, Peter, at this stage?

>>> Number 29

Jaap: do not recall recent discussion.
Need to check in status report
Bart: could you please do so in 2 weeks time? Sarmad is a co-author of SSAC52. Important. In response to the joint IDN group.
Pitinan: SSAC052. single char TLDs can be allowed. But conservative approach. Lack of context is the reason. Also relevant to IDN PDP group, which requested the chinese/japanese/korean RZ-LGR to work together regarding the han script.
Bart: meaningful criteria requirement. Does that make a difference
Kenny: we do have 2 opposite considerations from the community. Many consider single character TLDs cannot be a meaningful representation. (Chinese community). The other party is also considered. Some single characters with meaningful representation, but used elsewhere. For instance a surname. But not as a country code. Discussions ongoing in community.
Bart: make this part of the first review of the policy
As this is another requirement that kicks in; there is only one IDN ccTLD per territory, per script. Chinese, japanese, korean not eligible for single character, since they already have an IDN ccTLD in these scripts.
Kenny: makes sense.
Bart: will include this in next version of the doc. Noting the issues, the ongoing work. Revisit in 5 years, once implementation has been completed

>>> Number 28

Bart: my nightmare scenario.
Dilemma. If you can wait 5 years, what is the value of the change? Hopefully captured in the stress test and assessment.
Irina: cannot immagine how such amendment can happen. See Pitinan’s explanation.
Bart: by carrying it through, you deliberately endanger the stability and security. Due to a 5 year period.
My advise would be to strike “it could be deselected under these circumstances”
Pitinan: there are also external influencers. Unicode, or IETF.
In case anything happened. My suggestion.
Bart: concern. External parties change, and make these changes. This could be during the process of retirement that they become effective
Irina: suggest to change the description of the scenario. Sounds strange. If there are strong reasons to amend RZ-LGR affecting the ccTLD, then this is the description of the scenario. I am in favour of same approach for gTLD and ccTLD. If gTLD to be grandfathered, then ccTLD to be retired
Bart: word “assume”. But will make it clearer.
Will adjust by next time we meet. Outcome: needs to be grandfathered. And refer to EPDP. predictability and clarity is warranted. Also taking into account public consultation regarding changes to RZ-LGR.

Irina: Some stress tests sound like good examples for the FAQ when we introduce the policy to the community.
Bart: mix. Method to deal with outlier situations following inital discussions. They serve multiple purposes.
The ccPDP3-RM used stress tests for that purpose as well. Questions referred to stress-tests, and the assessments by the group.

4.                   Next meetings (full working group)

Confusing Similarity consolidation:

  *   23 May 2023|13.00 UTC
Stress Testing:

  *   30 May 2023|13.00 UTC,
  *   6 June 2023|13.00 UTC
Prep Update ccNSO members meeting:

  *   6 June 2023| 13.45 UTC

Bart: we need 2 June for second reading, to finalize the stress-testing. Use part 1 of the meetign for stress-testing, and part 2 to discuss policy presentation
Assuming that next week would be the last day of the CS discussions

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

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

  *   Tech Day
https://community.icann.org/x/MAM5Dg

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