[ccPDP4-IDNWG] NOTES | ccPDP4 IDN WG | Tuesday, 25 July 2023 at 13:00 UTC

Tue Jul 25 15:13:32 UTC 2023

I apologise for missing today's meeting because I am in Accra attending AFRALO GA and ICANN Africa Engagement forum. I shall read the notes.

Kind regards

Hadia

________________________________
From: ccPDP4-IDNWG <ccpdp4-idnwg-bounces at icann.org> on behalf of Joke Braeken via ccPDP4-IDNWG <ccpdp4-idnwg at icann.org>
Sent: 25 July 2023 17:38
To: ccPDP4-IDNWG
Subject: [ccPDP4-IDNWG] NOTES | ccPDP4 IDN WG | Tuesday, 25 July 2023 at 13:00 UTC

NOTES | ccPDP4 IDN WG | Tuesday, 25 July 2023 at 13:00 UTC

  1.  Welcome

No apologies received

2.                   Admin matters

a.                  Action items

Bart: no open action items

I am grateful for your comments, and so should we all

Thanks to Irina

b.      EPDP update

Anil: one single agenda topic during previous meeting. How to restrict number of variants in the new gTLD round. Majority said to adopt a methodology where the number of variants should be restricted. Why? Security of the entire system, and secondly tech capability of the registry. Concern: additional charges from 5th variant onwards. Most recommended that - similar to ccTLDs - string that people will apply for should have a identity related to the territory. Meaningful representation of the variants. Discussion still ongoing. Will keep you abreast of new developments

Peter: do you foresee any expectations in our direction? All on the same page regarding the “sovereignty:” of ccTLDs. Not follow same limitations.

Anil: was indeed discussed at length, the similarities between the recommendations. Recognised by GNSO and EPDP that ccTLDs work with different criteria.

Bart: looking at the overview of the GNSO with respect to the differences. Looking at the annexes, where there is a comparison, and looking at the staff paper, differences are being recognised.

3.                   version (v9) of the Basic Policy proposal for IDNccTLD Strings Selection Process draft report.

version (v9) of the Basic Policy proposal for IDNccTLD Strings Selection Process draft report.

V9 includes:

  *   Suggested edits and changes accepted/incorporated
  *   Table of Contents
  *   New text in yellow
  *   Executive summary included
  *   Revised numbering
  *   Reviewed for consistency in terms

Full initial report as proposed by leadership and staff, for your consideration. Once adopted, this is the full initial report which will go out for public comments.

>> paragraph 2

Bart: does this address your concern, Irina?

Irina: yes

Anil: add ccPDP3?

Bart: yes, will add it to the text. ccPDP3-RM. This clarifies matters

Do you support the executive summary? 1st reading

Green ticks: support, Red ticks: do not support or abstain. No red marks.

Peter: question regarding “the proposals do not amend….”

Struggling with one phrase. Which may “deviate” from current policies. Rather: spirit of the current policies.

Bart: different ccTLD manager. Example: Egypt. IDN and ASCII ccTLD are different

This is “current”. Any other suggestions? If we can close this today, my suggestion would be to do a formal online call for second reading of the full report, without scheduling an additional meeting. I am not available next week Tuesday.

Peter: ok, if no-one else shares my concern

Anil: add 2 lines to make things more complete.

Bart: ok, will add it to the initial paragraph. “At the request of ccnso council in January 2023, the full group developed the proposals regarding….”

Anil: ok.

Bart: do you support the process to date? No red marks.

Peter: I’d like to suggest to add, if available, a reference to ‘the 2 reading method’ ;  it is clear to us, but since the decision making is important, other readers might benefit [in ‘process to date’]

Bart: do you support section 1.2 in 2nd reading?

No red marks

Peter: addition of requested variants. We concluded that variants might be asked for at a later stage. Is there a constraint as to when they can be asked for?

Bart: if you do not add this, you leave the requested variants in limbo. What if we turn this into “and/or the requested variants”. Hope this addresses your concern and the one by Sarmad. Beware, this is just an overview, not normative

Peter: ok. That helps.

Bart: will change it into and/or

Sarmad: the intention was not to suggest they are required. Add “if any” or “and/or”

Bart: and/or is easier. Do you agree with this suggestion?

Peter: i also like “if any”

Sarmad: yes. Not only for the string, but also for additional strings

Irina: and/or sounds good.

Bart: do you support 3.3?

No red marks

Peter: what was the concern, Sarmad? The SSAC advice talks about single character domains, a “letter” would be even more ASCII-ish than character. Page 17

Sarmad: definition of character by unicode. 2 characters could mean an e followed by an accent. But they are one single letter. Intention was to require 2 letters. I can quickly check the unicode definition again. Character may not be sufficient.

Peter: e and accent should indeed be one impression. Perhaps a verbatim expression? 2 distinct impressions to the human eye, rather than whatever number of code points used to generate.

Bart: would it work if we strike, leave letters, and include footnote to unicode definition in the footnote?

Sarmad: challenge is whether “character” is sufficient here.

Peter: i agree. If we just write “character”, even if it follows the unicode definition, not sure the reader will understand. Hope we are in the normative part here.

Bart: this is the normative part.

Sarmad: https://unicode.org/glossary/#character<https://ntra.mv.net.eg/glossary/,DanaInfo=unicode.org,SSL+#character>

Bart: The smallest component of written language that has semantic value; refers to the abstract meaning and/or shape, rather than a specific shape (see also glyph), though in code tables some form of visual representation is essential for the reader’s understand

Sarmad: not clear whether accent is considered having a semantic value. I need to dig deeper.

Bart: must contain more than one character.

Concerned this will take additional time, and we extensively discussed this already.

Michael: Problem is "letter" is possibly not better, because U+02CB is for example called "MODIFIER LETTER GRAVE ACCENT", so it seems to be a "letter"

Peter: it is important. What we want to have is that for the human eye, there should be 2 “things”. Trusts Sarmad to come up with a solution.

Bart: Sarmad to come up with a definition, building on previous work of SSAC and other groups. To be finalised soon, so we can circulate by end of the week?

Bart: thanks, please asap.

Sarmad: Yes, I will get back with some detail and also consult Unicode colleagues

Peter: could the gvt in the minority?

Bart: no, SIP

Notes and observations, not part of the policy itself. To underline the point that unanimity is not required

Irina: 5.1 last line 'section' 2 times

Bart: major changes regarding 7.2

Bart: sections now part of notes and observations. Used to be a footnote. But now moved, due to the nature of the text. It does not change the status, but as an alert.

The notes and observations to 7.2.1. And 7.2.2.

Irina: page 37. new addition should start with 1st word

Sarmad: if variants are requested, ensure they are aligned with RZ-LGR. If not aligned, inform the requestor

Bart: font difference, and this note and observation was included twice. Addressed.

Peter: section 11, 3rd bullet. Mentions “european union”

Bart: exceptionally reserved, copy-paste from the fast track.

Peter: exceptionally reserved code point

Bart: indeed. we will replace it

Annex

Irina: looks confusing.

Bart: we talk about 3 sources in this annex

This table was developed around the retirement WG. The definition description pre-dates the 2020 terminology. 2013 standard. It changed again in 2020. Changes are included, that is the current wording.

“unassigned“ was not defined in 2013. Third source: online browsing platform. ISO

Irina: term was not defined in 2013 or 2020 version of standard or other place.

Bart: we could clean it up. Jaap? Let’s only use the standard. If there is no definition in the standard, we use the online browsing platform. And mention this. And we only use the latest version, which is the one applicable.

Peter: OBP==online browsing platform, not open browser platform

Jaap: see glossary ISO3166 on the ISO side. That is where you find it. I will post the link

Bart: let’s only include the recent version and the source

Irina: that works

Jaap: Glossary: https://www.iso.org/glossary-for-iso-3166.html<https://ntra.mv.net.eg/,DanaInfo=www.iso.org,SSL+glossary-for-iso-3166.html>

Peter: agree w/ glossary cleanup re 3166

Annex C

Irina: is there a value of adding this, as part of the advice? Why not add it in the notes and observations. Box above.

Bart: ok. Any concerns? None

3. Next meetings

On 8 August 2023 at 13:00 UTC

Bart: Peter and Irina are not available. We will try to circulate it next week. I cannot use my voice next week. If you have any comments, please let us know asap

Final reading of the initial report on 8 Aug,

Irina: i am available until friday this week. Out until  14 Aug

Peter: not availabl 8 and 15 Aug

4.                   AOB

5.                   Closure

Thank you all. Bye

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