NOTES | PGA WG | Tuesday, 10 September 2024 at 20:00 UTC. 1. Welcome Welcome by Jordan Carter, PGA WG Chair Apologies by Bart, Pengzu, Abdalmonem and Chris 2. Administrative matters a) SOI updates Action item #1: Staff to check whether SOIs are missing for WG members. b) Nomination Chair and Vice Chair: confirmation and next steps Jordan nominated as Chair, Maria as Vice Chair Next step: formal appointment by Council (mid-September Council meeting) 3. Decision meeting rotation from next meeting onwards Suggestion: 4 UTC, noon UTC, 20 UTC Agenda item 3. Timezone distribution PGA members https://www.timeanddate.com/worldclock/meetingtime.html?month=9&day=10&year=... 4, UTC, noon UTC, 20 UTC: Rotation until ICANN 81. Evaluate at ICANN 81, to see how it works. 4. Previous meeting: questions or comments regarding the intro to PGA WG work? none 5. Overview of Policies and Guidance relevant to ccTLDs Agenda item 4: overview policies and guidance relevant to ccTLDs https://docs.google.com/document/d/1Jp2WLD6ZfF1nVY3p0xSNkCeo1E4fKIdL/edit?us... Jordan: Bart was the original author of the document. Explains what each page is, and welcomes comments.
intro ccNSO mandate to develop best practices. Some of the policy sources pre-date ICANN. E.g. RFC1591. Key foundational document.
chapter 1 Idea behind the doc: have a comprehensive list of all policies, guidelines etc that apply to relation between the ccTLD and IANA. main sources of the mandate.
chapter 2 Iso 3166-1. Exceptionally reserved names, IDN ccTLDs ccPDP4
chapter 3
section 4. Dispute resolution
Pablo: will we create a new RFC that replaces FOI and 1591? Jordan: we do not need to do that. The RFC series is no longer the place where the policies are made. Kim: what Jordan said is correct. MoU between ICANN and IETF regarding policy development. There is no RFC to be published. Unless: RFC1591 is not a thing, go see icann policy docs. Was published in 1994 by icann staff. Current operational practices, but it is not policy. Part of the problem: a new person looking at the doc does not understand that it has never been intended as a policy. Jordan: we had to had have sth to point to Nick: nostalgia. It is not a policy doc. It is a quaint use of the language. Long time ago. Jordan: https://www.rfc-editor.org/rfc/rfc1591 Nick: almost the 10 commandments. Nuances are historic. Hard to rewrite, without changing the interpretation of the policy as it was intended. Some intentions are obscure. You need to look at the FOI. once you pull the string, you do not know where it ends up/ Irina: Sections 2 & 3 of this document need to be updated as PDP4 was approved by ccNSO Council and members and now is for Board consideration Nick: interesting exercise. Sad to see it retiring. It is a historical artifact. Words from John Postel. It is going to take extreme care. Jordan: part of the work by this PGA WG, identify gap. One way to fill the gap is to create policy. In a later call, we will look into the set of methods to fill a gap. If we create something new, it will create benefits (e.g. for iana), but it will also create challenges. By nature, it opens up what is in the policy. Some gvt or community participants might be uncomfortable. This group will make a recommendation to the ccNSO community what the gaps are and what the recommended method is to fill them. Pablo: i believe the work that was done by the small team of Councillors that developed this doc. It created a path for us to understand how these policies evolved, and the importance of why they need to be updated. Need to be careful. Recognise that the doc no longer responds to the realities of what we do, and how the TLDs evolved. Strong doc. Jordan: don’t come to a decision too quickly. We will come to the way forward later on
Section 5. guidance/advice. E.g. emojis, wildcards Jordan: not sure if there is a policy about what can and cannot be in the root zone Current state of knowledge from April. Some things have changed in the meanwhile. E.g. ccPDP4 policy as noted by Irina.
Peter: financial contributions to ICANN guideline. Not sure it fits here? The rest of the list deals with the structure of the naming system, the role of the ccTLD and related parts. Jordan: this group does not update the guidelines. We have GRC. but we factored in all factors in the relation between ccTLDs and iana. Whether or not you make a financial contribution, does not influence the treatment by iana Peter: rabbit hole. Avoid it form the start. Jordan: for some it was the first time you walked through this doc. To do: make introductory paragraph. Action item #2: Working group members to read the following documents by the next meeting, and to add any comments they may have: * Overview of Policies and Guidance relevant to ccTLDs * Identified GAPs from IANA perspective<https://docs.google.com/document/d/15D2j805FMomv0Hl7pn39D3S3_DbBAJYpeq8d1kYf...> Jordan: Treat it as a resource for us to use. It is a working doc for us. Between now and November, we need to be careful that we are comfortable with the content and that it is up to date, before we share it with the community. 6. PGA Workplan Agenda item 5: proposed PGA workplan https://docs.google.com/document/d/1KLwT8OSYHnHf-bRHfZuAW15cKIx6vthA_W36g5tx... Jordan is hoping for Kim to be available. IANA gaps list, and prioritisation. What are the most important gaps? Were they listed in priority order? Kim: roughly ordered, but yes. I will need to clarify it is a not a conflict for me, will be in Colombia Jordan: if needed, we will shift the order. Jordan speaks to the proposed workplan. 90 min block at ICANN 81 Here is the draft ccnso block schedule for ICANN81: https://community.icann.org/pages/viewpage.action?pageId=351404066 Saturday morning, block 2: working group meets Tuesday afternoon, block 4: update to community as part of the ccNSO members meeting Nick: likes the workplan. ccPDP4 Caucus of the ICANN Board had 40plus questions regarding implementation. When we come up with restatements of existing policies, we need to learn from that experience. Disconnect. Huge amount of extra work. Great drain on the limited amount of volunteer time. Could we move in parallel with a quasi board caucus? Before the ccnso vote? Do the people we deliver the policy to, is it fit for purpose? Jordan: agree with the problem with the problem you identified. Council to examine how to avoid it from happening again. Look at how the GNSO writes its policies. ICANN system is used to that. Engaging with legal, with iana. Whatever we do, we want a collaborative relationship with icann. Use all resources. To avoid the situation we are in now Irina: regarding the suggested workplan. The first task for the WG as per its charter is to complete the overview of the policies and guidance at ICANN. What are we goign to present? Doc from item 5? Or a consolidation doc as discussed by small team Jordan: the doc we ran through today would be the doc. If we decide to do a consolidation, and identify there is a gap … just create a resource where people can find the info. Not write new content. There is no time. Peter: phase 1 of the work in this group. Once council adopts the output of the work of this group. At icann 81, or the meeting after that, the group comes to a close? Jordan: yes, in narrow sense. Phase 2: starting work on the gaps. 7. AOB none 8. Closure and next meeting 24 September 2024, 4 UTC Background materials * Doc library: https://community.icann.org/display/ccnsowkspc/Background+Material * All materials will be posted on the PGA WG workspace. See https://community.icann.org/display/ccnsowkspc/PGA+WG+-+10+September+2024+at... Joke Braeken joke.braeken@icann.org<mailto:joke.braeken@icann.org>