[ccPDP4-IDNWG] NOTES | ccPDP4 IDN Working Group Teleco #14 | 20 April 2021 (13:00 UTC)

Tue Apr 20 14:17:10 UTC 2021

Hello everyone,

Please find some notes from today’s ccPDP4 Working Group. These notes do not replace the recordings.

Best regards,

Joke Braeken

1.  Welcome, roll call and agenda bashing

Welcome by Chair Kenny

No apologies received

2.  Administrative matters

               a. Action items, if any

No open action items, no carry-over action items

               b. Debrief webinar

15 April 2 webinars were being held, one at 8 UTC, the second one at 16 UTC.

Bart: did anyone on the call today attend the webinar? If so, what went well, what can be improved?

Good attendance. Joint session with GAC.

Anil: update by ccPDP3 and ccPDP4. Well received. Thanks to staff for organising.

Javier: attended both sessions. Both were very informative and interactive. Good attendance, especially in the 2nd session. Various people from the ICANN community.

Svitlana: attended 1 webinar. Good info about the working groups. Info about decision-making and the applicability was much appreciated.

Webinar slides and recordings can be found:  https://community.icann.org/x/RASlCQ

There will also be a Policy session at ICANN71 (day/time TBD).  Further community feedback will be solicited during this session

3.  Subgroup update

a.   Variant Management

Update by Alireza. Done to date: Staff updates and setting the scene, over the past weeks.

Next week Dennis will give an update of the GNSO efforts.

4.  Second reading section 3.5-4.2.2

Page 8. Reference has been updated. Should work now.

3.5, 3.6. | Group agrees with the proposed changes and proposed text.

3.7.

Line 6-8: does this now capture what has been discussed at the previous meeting?

Strike “have been applied”?

Alireza: refer to code table of IDNA2008. This is updated per unicode table. If unicode is updated, that is updated too.

Jaap: that unicode tables are updates does not mean anything for IDNA2008. Not slavely following what is in unicode. Should first be interpreted by the people that do the standard. Sometimes unicode is changing attributes to characters that makes them either valid or not valid to be used in IDNA2008. Current IETF version is lagging behind the unicode version. If you follow what is in unicode blindly, you make existing labels no longer valid, or the other way around. Have a critical eye.

Bart: is there in IDNA2008 a list of scripts that can be used?

Jaap: no. big difference with 2003. Algorithm to look at attributes of the unicode characters. No single table. Changes all the time.

Dennis: wait for the VM sub group. The overarching question: What is the sole source to validate TLD tables? Candidate is the RZ-LGR. Derived from IDNA2008 but further. Universe of codepoints that could be used for TLD lables. If this PDP accepts RZ-LGR as sole source, we need to revise this small section later

Bart: we can park this. But the issue we wanted to address is whether we should use a designated script.

Group agreed this was not the most appropriate way to go. But some languages are expressed in 1 or multiple scripts or writing systems. Set of characters. Would your suggestion address this concern?

Dennis: ok. Delete “which is processed for IDNA2008”

Jaap: danger. It has been processed by IDNA2008 algorithm. You want to go through this review before you do the RZ-LGR.  These are candidates. There might be other rules that need to be applied too. It kind of limits, but not completely.

Sarmad: unicode is a necessary but not sufficient condition. Scripts processed by IETF. if RZ-LGR is adopted as the condition to move forward, then either the Maximal Starting Point or RZ-LGR would be the relevant reference points.

Peter: a script is only eligible if it appears in the latest version of unicode that has been processed.

Bart: this is not about characters. This is to address “if an application comes in with a designated language to refer to a script”.

Alireza: agrees with Dennis his suggestion.

Action item #1

Staff will prepare a revised text of item 3.7 (line 6-8) to ensure it meets all expectations. To be reviewed at a later stage.

Jaap: RFC 8753. Review of new unicode and new code point analysis.

Peter: 8753 … or respective successor document

4.1.

Non-objection included. Some governments will have an issue with explicitly expressing support or endorsing a string, but they do not mind non-objection.

Line 5-11 has been amended to reflect the timing of the concurrent request. Suggestion by Sarmad. Reference to significantly interested parties (SIP) in the footnote from the framework of interpretation (FoI)

Michael” shouldn't "... for selecting and IDN ccTLD string …" be ".. for selecting an IDN ccTLD string …"

typo: receveid => received

Peter: must / should. Mixture of language.

Bart: must be non contentious within the territory.

Peter: the headline says “should”, the text says “should”

Action item #2

Staff to replace “should” in 4.1. with “must” and correct typos

Sarmad: if there is a request that is being processed and a second request comes in, both are on hold. Each of the parties asked to solve this internally. Is it ok to inform the others about the other request?

Bart: within the territory …. SIP includes the government. You do not want a fight between 2 agencies

Sarmad: once the conflict is resolved, 1 will withdraw and the other application moves forward.

Alireza: what happens if variants will be enabled in future. Is it clear enough?

Bart: all should be revisited once the recommendation by the sub-groups are ready.

4.2.2.

Combined various sections. Criteria, procedures, documentation are related for overview. Do we want to do this differently again in future? Needs to be revisited.  For ease of documenting it.

Non objection needs to be documented.

5.  First reading 5.1, 6.1 and 6.2

Background during the previous meeting

Sarmad: after RZ-LGR is considered and agreed, it needs to be added to the technical criteria.

DNS Stability Panel (DSP)

To be revisited next week.

Sarmad: line 14 and 15. Actual technical criteria to be documented as part of the implementation plan. Who will define them? The current group, another group?

Bart: the implementation plan is up to icann org, and then consultation with the community

To be revisited.

The more you add to the policy, the less timeless it will become. Things might evolve. To be taken into account.

Anil: what did independent review mean?

Bart: recommendation is having a technical panel or a similarity review panel.  One and the same panel at the moment. We leave it up to icann for cost-saving following the regular procedure.

Jiankang: page 25. Line 1. Change to “any”.

Bart: it has to meet “all” criteria. That is the idea?

Michael: I agree. "all" should be "any" in line 2

Jaap: fails to meet any

Anil: applicant informed about non compliance?

Bart: cannot be changed “on the fly”. Process is terminated if it does not meet the criteria. Should perhaps be made more explicitly, when the termination section applies.

Action item #3

Staff will update the section 5.1. Based on the discussion today.

6.  AOB

7.  Next meeting

  *   4 May | 13:00 UTC
  *   18 May | 13:00 UTC
  *   1 June | 13:00 UTC

8.  Closure

Thank you. Bye all.

Joke Braeken
ccNSO Policy Advisor
joke.braeken at icann.org

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/ccpdp4-idnwg/attachments/20210420/59bb00bf/attachment-0001.html>