[ccPDP4-IDNWG] NOTES | ccPDP4 IDN Working Group #12 | 9 March 2021 (13:00 UTC)

Joke Braeken joke.braeken at icann.org
Tue Mar 9 14:25:00 UTC 2021


Hello everyone,

Please find included below some high-level notes and action items of today’s ccPDP4-IDN WG meeting, held on 9 March 2021 at 13 UTC.

Best regards,

Joke Braeken

ACTION ITEM

AI #1

  *   Secretariat to update the draft slide deck of the 16 April ccPDP webinar to community and GAC
  *   Working group members are requested to review the draft powerpoint presentation as prepared by Bart (updated version to follow) ahead of the meeting on 6 April, and to send suggestions to the mailing list, if any



NOTES



1.  Welcome, roll call and agenda bashing


2.  Administrative matters


             a. Action items, if any


None


             b. Progress liaison to GNSO


sub-WG was asked to nominate one. By next week the liaison will be nominated


             c. Update IDN Variant Management Subgroup


First meeting took place last Tuesday. Tour de table of the various sub-WG members. ICANN IDN staff (Sarmad) gave an introductory presentation: setting the scene. Continuation in the next sessions.

recording of the IDN VM teleconference can be found here:  https://community.icann.org/x/OgFtCQ


             d. Review progress/pace/working method of group


How is this group doing, as a WG? After ICANN70, check progress against the work plan. Suggestion on how to improve? Balance between speed and quality. Needs to remain interesting for participants

Kenny: balance between technical knowledge and policy development

Anil: thanking all WG members. Timetable mentions that the report should be out for public comments in December 2021. How can we improve the pace?

Kenny: group is well on its way, now that sub-WG is in place.


3.  Initial draft slides


2 editions of the same webinar to the community, post ICANN70 on ccPDP3 & ccPDP4:

16 April | 8 and 16 UTC. Calendar invites have been sent to the WG

Bart points to some highlights in the slide-deck. Suggested draft, typos need to be corrected.

Questions or comments by the group? Please send them to the mailing list, or to Bart directly


4.  Continue discussion – Criteria, Procedures and documentation


             a.  Include designated script?


Version 6

Alert: placeholder, as result from last discussion

Any final comments or questions, line item 14 to 22?

None

Do you support the text as proposed, incl placeholder?

Temperature of the room (checking green/red marks)


             b.  Second reading section 3.4 and further


Introduced during the last call. Amended slightly, based on the discussions from the previous meeting.

Line 3-7


Peter: name does not appear in the manual. Could be a misunderstanding

Bart: this is about the territory.

Peter: add footnote to clarify


Section 3.5


Page 8 (line 12-26)

ICANN or IFO/PTI?

Should be ICANN. This policy is directed at ICANN. The implementation and the execution of the policy is not with IANA/IFO, but with ICANN org. Same as the Fast Track. Not within the remit of PTI, not part of the IANA naming function contract.


Peter: wording issue. Line 12-13. “Recognise”. Use assume instead

Item c: exceptional circumstance. Circular definition.


Jiankang: what does designated script mean? This is not the normal terminology

Sarmad: the phrase is arbitrary. What was intended is that in some countries a language can be written in various scripts. When a country shifted from one script to another. From the government perspective, the use of a language, is under a certain script. However, older population might still use the old script. That gets reduced over time, as the government shifts to the new script. Designated script is script suggested for use by a designated language by a government.

Jiankang: still unclarities. Potential confusion for the audience.

Alireza: question about the label. Territory proposes a string. Proposed it to be a TLD. Do we need to refer to designated string or language? Just focus on process? Is it important to define that it is designated for a community? String should be acceptable for a community. Do we need this term in the policy?

Bart: discussed previously. If you do not put a limit to the number of languages, you can easily end up in a situation which is out of control. 639-3 standard: 7000 languages listed. Potentially 1.5 million TLDs.

Designated = official language, external definition. UNEGN.

In-territory matter. Not for icann or the community to tell “you have the wrong name”. Matter for government and other significantly interested parties to determine the right string.

ICANN recognises and accepts the documentation from internationally recognized entities.

Anil: in India they have more than 2000 languages. Various territories by indian constitution. Only 22 recognised languages, officially approved by government

Department of languages. They determine how communication should go between gvt and citizens

Sarmad: There are examples of such cases.  For example Wolof in Senegal can be written in Arabic and Latin scripts. The link https://www.ethnologue.com/language/wol  suggests that the primary use script is Latin for Wolof in Senegal.

Alireza: suggestion. Make 2 terms (script/language). Connected with eachother. Should solve the issue, and question raised by Jiankang Yao. recognised by ICANN

Documentation should include language and script and reference

Bart: think along same lines. Potentially include “if there is more than 1 script, reference to the script. ISO15something, or other existing standard where the script is mentioned.”

If you include the link regarding change of script, is it a condition for the de-selection of the string.

Sarmad: around 150 scripts in unicode. When a territory applies a string for a particular language, does the application need to be limited to the scripts in that territory? Or any of the scripts in the unicode?

Bart: not every language is written in every script. See example Wolof (senegal). Not an implied script, to have Wolof for instance in Chinese

Sarmad: understood. Current language does not imply that restriction. Do we want to make script relevant to the language? Or arbitrary choice. There are implications.

Alireza: if icann receives a string for a particular country, supported by the government, it should be processed.

Bart: fast track demonstrated that this approach works. We take the same approach here, with some small refinements

Alireza: suggestion

Bart: section 3.3. Include reference to a script, as being required in the documentation provided by the national naming authority or the national linguistic authority.  Further discussion on 6 April. Historical reason why we use “designated language”.

Sarmad: reference to a script used in the country is good


5.  AOB


Anil : webinar on the 16th. On 6 april we will discuss the content of the webinar. Please review the powerpoint presentation as prepared by Bart (updated version to follow) ahead of the meeting on 6 April, and send suggestions to the mailing list, if any


6.  Next meeting


  *   6 April | 13:00 UTC (after ICANN70): start again with section 4 and recap what was discussed today.
  *   16 April ccPDP3 & ccPDP4 update to the community (and GAC) webinar | 2 editions of the same webinar, scheduled to be held on  8 and 16 UTC
  *   20 April | 13:00 UTC


7.  Closure


Thank you all. bye!



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/20210309/8a32edf5/attachment-0001.html>


More information about the ccPDP4-IDNWG mailing list