[ccPDP4-IDNWG] NOTES | ccPDP4 IDN WG Teleconference #21 | 17 Aug. 2021 (13:00 UTC)

Tue Aug 17 14:26:17 UTC 2021

NOTES | ccPDP4 IDN WG Teleconference #21 | 17 Aug. 2021 (13:00 UTC)

  1.  Welcome, roll call and agenda bashing

Welcome by Chair Kenny Huang (.tw)

Attendance will be taken based on those on Zoom.  Apologies:  Michael Bauland and Dennis Tanaka.

2.                   Administrative matters

a.                   Project schedule overview

Overview by Bart. Where are we in the process? How are we doing against the planned progress?

Suggestion is to review this on a regular basis, every 3 to 4 meetings, to keep track.

Review 2013 proposal: nearly done. We are now at the final section of the 2013 doc review, plus some additional items still to be addressed.

VM-group is making progress too. Still in drafting mode of the basic recommendations. They need to propose some suggestions to the draft the full group has been developing.

New subgroup, on the deselection, to be created too.

The full WG and the VM-group will need to discuss the proposed suggestions, for adoption by full WG.

If the de-selection WG would start later than foreseen, the impact on the overall process would be fairly limited.

Anil: what are the most critical items, that could delay the final product?

Bart: tool foresees this. Critical path is most likely the stress-testing. To be continued.

Kenny: let’s review this from time to time, to track progress against our plan.

b.      Subgroup launch

Expressions of Interest from members of the full WG.

De-selection subgroup.  Call for participants.

Please send an email to the mailing list, if you wish to volunteer.

This group is about the de-selection of an IDN ccTLD string. What is the trigger event that causes an IDN ccTLD to retire? This was not included in the work by the ccPDP3 on the retirement of ccTLDs.

The sub-group will work in parallel with the other sub-group, on variant management.

Meetings will be held every 2 weeks, alternating between the 2 sub-groups. Once the sub-groups finishes their work, the full WG will start meeting again. Both sub-groups develop the recommendations, which need to be adopted by the full WG. potential overlap between the VM and DS-subgroups.

VM: Variant Management

DS: De-Selection.

First focus on the selected IDN ccTLD strings, and what triggers their retirement.

Secretariat will send instructions to the mailing list on how to volunteer. Deadline to apply: end of August

c.       IDN EPDP kick-off – liaisons

Alireza is the appointed liaison to the EPDP group. Dennis is the liaison from the EPDP group to the ccPDP4 Working Group. Dennis apologised for this meeting, and Alireza is not available either.

Update to be deferred to the next meeting.

Anil: last wednesday, 11 Aug, the group met. Chaired by Edmund (.asia). In the first meeting, the group was briefed about the charter. Majority of the work will be about Variant Management. ccPDP4-VM-group will inform the EPDP group, and vice versa. Anil available to assist.

Kenny thanks

d.      Action Items

All completed.

                                                                     i.add section 7 & 8 to consolidated document

                                                                   ii.overview points discussion of section 9c

                                                                 iii.creation of list of time

                                                                 iv.update section 9d

3.                   Subgroup update

a.                  Variant Management – Alireza or Dennis

Bart: the sub-group is discussing 5 major topics:

  *   Specific recommendations around the original staff recommendation on VM. issue the full group will need to discuss in near future: scope of the recommendations, since some of them look at second level domains. Not within remit of the PDP? Important to do, taking into account what a variant is, and the basic principle that whatever the WG does,it should not harm the security, stability, interoperability of the DNS.
  *   The technical recommendations. Will start next week, oe meeting after
  *   IDN tables
  *   introduction
  *   Process update: suggestion how the VM should be included. To what extent does the process as originally identified need to be adjusted?

Group spent some time on understanding VM, what it means, and its implications. Second level: hard nut to crack.

4.                   Continue:  Section 9c, 9d

  *   Section 9a was supported by the WG members that attended the last meeting. No comments or questions.
  *   Section 8b on Confidentiality: no changes to the next. WG comments and findings added. Was supported at the time

>>> Section 9c

Arguments, taking into account discussions from the previous meeting and some additional comments. Main raison for the creation of this recommendation at the time, were the dates. The original proposals were developed in the 2010-2011 era. Discussion of use of country and territory names as gTLDs. See AGB at the time. Some references included to the Applicant Guide Book used to be in the text. Timeline was included. Looked also at SubPro WT5. adjustment of policies for the upcoming gTLD round. For historical reasons, adoption of a list, disappeared, following adoption of AGB and WT5. WT5 recommendations and the original recommendations in AGB exclude all country and territory names in all languages from use as a gTLD, unless there is support from the relevant governmental authority. There is still a grey area, but that will not be addressed by the creation of a list. Historical reason for such a list is gone.

Are there existing lists? Yes, 5 lists. Will record IDN ccTLD names or their variants. For instance: IANA Root Zone Database. This is policy in action. ccTLDs, gTLDs.  What is the added value of an additional list? None …. Seen the fact that there are existing lists, the historical reasons for having such a list no longer exist, and the maintenance of such a new list is a true challenge. Bart refers to “reserved names”. What should happen with them? High cost, implications of reserving names, especially when open-ended. Needs to be litigation-proof.

Line 21 on page 2. Staff also included the arguments from the discussion at the previous meeting.

Questions or comments?

Taking all the arguments into account, and seeing the divergence in this group at the previous meeting, staff prepared an overview of the existing lists.

Hadia: line 15. How can it have an impact on non-ccTLD policies?

Bart: Currently, non-ccNSO policy means GNSO policies. If we build a list, it may directly impact what is allowed under the new gTLD process. If you carve out certain aspects, it may impact what has been developed under SubPro. Grey area around IDN strings with 3 characters. Allowed currently under subPro. There is no clean delineation between the 2. The world was easy with only 2-char codes. Clearly ccTLDs. With the arrival of IDN ccTLDs, this distinction became blurred.

Hadia: distinction between IDN ccTLD and IDN gTLD?

Bart: if the name of the country or territory is listed in iso 3166. Keep in mind, that at the time when this was created, there was no such exclusion. This was pre-AGB, pre-SubPro WT5.

Are you in favour of removing item c? Line 6-11.

2 in favour, some not in favour.

Ram, Idaho, Jeff used their red marks.

Yudho: .id has submitted 2 years ago an IDN application. But was rejected. Language is still not an official language. Important that we refer to ISO3166.

Bart: But this list has nothing to do with the iso list. Independent. Completely different.

Jeff: red mark used as abstention

Ram: more of a question. What harm is done by keeping the list, other than the possibility of ambiguity with the ISO list. This list has also the variants, which are not going to be listed elsewhere.

Bart: will be maintained. Independent of the creation of a new list. But why maintain a list, if there are so many lists? Effort needed.

Ram: is there another place where an authoritative list continues to exist? Variant, territory, ccTLD

Bart: root zone.

Sarmad: we do maintain a list of IDN ccTLDs. Variants for IDN TLDs (gTLDs and ccTLDs): need to develop a mechanism. Talking to IANA too. How to maintain the list? ccTLDs maintained. Variants maintained once policy is approved and implemented. Independent of this list.

Ram: conservative. Is there is something currently that is authoritative, do not remove it unless the new authoritative list is in place. Expecting policies to be created in the future, seems risky. Worried about utility going away, before a replacement is found

Bart: this list does not exist yet. This was an idea in 2011, but was never implemented.

Jaap: my point too. There is currently no such a list.

Ram: understood. Changes red mark into a green one.

Hadia: the iana list includes idn ccTLDs and variants? Only idn ccTLDs, and the process for including variants is not yet defined?

We could instead of creating a list, maintain a record of the validated idn ccTLDs and variants. Refer to iana list, and say we expect them to included the variants too?

Bart: there are no variants yet. Not yet delegated.

Even before delegation, ICANN maintains a list of validated IDN ccTLDs. There will be a mechanism, for dealing with VM, once the policy has been adopted.

Sarmad:

  *   list of IDN ccTLDs successfully delegated.  https://data.iana.org/TLD/tlds-alpha-by-domain.txt

  *   List of successfully validated TLDs: https://www.icann.org/resources/pages/string-evaluation-completion-2014-02-19-en

There could be validated TLDs, which are not yet delegated.

Sarmad: reading number c as “what is possible”, already maintained by iso3166 list.

Bart: Hadia’s suggestion. Section 6 which we discussed previously is about the publication of the validated IDN ccTLD string. The VM-group will come up with a recommendation to include variants. Will be addressed in the future

Yudho: will follow Ram’s comments.

Bart: record of the WG comments maintained.

Jeff: The discussions have convinced me to move to approve to remove

We will strike lines 6-11

>>> section 9d

3 scenarios last time, that should be included. Staff drafted some text around the 3 scenarios. Or 4 scenarios. Number 4 is the easiest one. VM sub-group will address this. The other 3 will run through them successfully.

Line 3-6.

Any comments or questions? Closure of the FTP (Fast Track Process)

Irina: we should rephrase. “this policy shall be the only one available to submit a request.” something along those lines.

Bart: once the policy is operational and becomes operational, no new strings can be requested through the FTP.

Irina: agrees with the idea. But the wording should be clearer.

Bart: if you look at the Fast Track Implementation Plan (FTIP), there is the administrative clause where there is a natural end of the FTP foreseen.

Bart will update the text ahead of the next meeting.

Item 5: review of the policy.

Notion of a review, to be triggered by the ICANN Board, with a review Team which operates with ToR.

Anil: why 5 years?

Bart: could also be 10 years

Anil: event which triggers the review of the policy. But what if there is no trigger, no complaints?

Bart: valid question for the group

First, do you agree to include a Review Mechanism?

Yes

Regular review?

Yes

Terms to be discussed at the next meeting (5 years, or different proposal)

This is done by a WG, which has Terms of Reference (ToR), to be defined under auspices of the ICANN BoD

Broader review, and then a PDP?

Irina: ccNSO itself can make a review and determine whether adjustments are necessary to the policy.

Bart: policy would say that ccNSO would need to organise issue report and review.

Irina: ccNSO itself. Preferred option

Bart: ccNSO Council and Board can always start a PDP

Regular review, whenever needed. Through mechanism of a PDP. The review itself is the Issue Report. Policy directed at the ccNSO. In the review, interested SO/ACs need to be consulted - if willing.

5.                   Other sections:  9e, f, g (time permitted)

deferred

6.                   AOB

7.                   Format of next meetings

31 August | 13:00 UTC

14 September | 13:00 UTC

8. Closure

Thank you all for your participation.

Reminder: call for EoI to the de-selection Sub-Group.

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

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