NOTES | ccNSO Council Workshop (closed)
NOTES | ccNSO Council Workshop (closed) Sunday, 22 October 2023 | 08:30-10:00 UTC (10:30-12:00 local) Room: Hall Y 11-12<https://icann78.sched.com/venue/Hall+Y+11-12> ________________________________ To review potential policy gaps in the ccTLD post-delegation processes, the ccNSO Council will hold a closed workshop. Open to Council members and invited guests only. Welcome Welcome by Alejandra Roles and responsibilities Chris: idea regarding gTLD and ccTLD registries. Ongoing meetings between THE registries. Buy in from the gTLD Registries needed. Meeting at ICANN? Mailing list? Chairs and Vice Chairs have an agenda. DNS Abuse would be one of the common topics. Within the ICANN context in future, statements by registries might be powerful. Buy in from Council? If so, go to RySG. Tatiana: as NomCom appointee, I noticed the same. Synergies between the ccTLD and gTLD registries. Joining efforts and sharing info might be useful. But also, establish boundaries. Bilats might be considered hostile by some groups Alejandra: suggestion to have the liaison as a Council role Councillors agree Alejandra: Fellowship Selection Committee. Workload is considerable. Good idea to replace him until the end of his term. Any volunteers? Pablo: happy to take over Alejandra: thanks to both ccTLD Global policy gaps : how to approach this work 1. Brief background – the .lb case’s lessons for policy The gap is: what happens if a ccTLD manager wishes to no longer be a ccTLD manager, but there is no replacement. The policy framework does not say what to do. Gap to be filled. Pablo: it is not only when an operator decides not to continue, but also when the operator is no longer capable to continue (illness for instance), and there is no succession. Jordan: expended version of the gap. We will brainstorm in small groups Now is not the time to raise any additional gaps. We will do that in the brainstorming section Stephen: substantial misbehavior by the manager Jordan: testing of the boundaries in the follow-up work we need to do Javier: gap as term? Anglo-saxon. Succession is more universal. Jordan: example of a problem. So it is a gap in the policy framework. Something that is missing. The idea is to lift up from this particular case, and think about other areas, more broadly. Might be obsolete. Bigger picture. We do not have to solve the problem today, the first time we discuss it. 2. The three areas of work a. Consolidation RFC1591, ccPDP3-RET and FoI. other relative docs too Where do I find the 1 source of truth? There is no single doc. Outcome: coherent, easy to find, better for ccTLDs and IANA b. Gap analysis Identify gaps Outcome: * Clear assessment of gaps in policy framework * Prioritisation of gaps to tackle first c. Ways to deal with future unknowns Other unexpected situations? How to deal with those? * Addressing issue 1 and issue 3 would require a PDP * Addressing issue 2 could be part of a PDP or could be a study group leading to a future PDP * Small Group seeks agreement to continue developing its thinking towards launching a PDP at ICANN 79 * Identify and bring together all existing sources of policy * Gain additional input on gaps in the policy framework * Nascent thinking on a mechanism to deal with future unknowns 3. Work at ICANN79 * Community sessions on * Briefings on existing policy framework * Develop and refine gap analysis * Discuss future unknowns mechanism and obtain community feedback 4. Discussion / Q&A Jiankang: this is sensitive and important. For ccTLDs, the gvt has the power. Therefore this is sensitive. How to get input from the gvt? Their support and approval, if we make changes? We need to be careful. Jordan: sensitive set of issues. Therefore it needs to be a process with plenty of consideration. Stress test. Role of the gvt? Of the local internet community? Transfers between managers? No accidental changes, because it is so sensitive. Gap analysis, therefore not changing the things that are already there. IANA is not getting involved with operational policies in the country. Only the narrow scope of policy that is relevant here. IANA inputs Presentation by Kim Davies Case studies that are pertinent to the discussion. * Case study A: IANA listed manager has no role in operation of the ccTLD, no longer wishes to be listed * Case study B: IANA listed manager has no role in the operation of the ccTLD, has no practical role * Case study C: IANA listed manager is not an existing entity * Case study D: point of contact is indisputably incorrect * Case study E: local presence requirements only nominally met Unifying concept. Specific examples of general concept Nick: question (notes missing) Kim: often lack of understanding regarding obligations. Understood it resonates often at your level as well IANA as authoritative record keeper Meta observation: documentation quality * Improve ccTLD policies * Improve ccNSO products Documentation quality example ccPDP3-RET Q&A following Kim’s presentation Chris: We are attached to RFC1591. Policy exists, but it is not understandable and there are huge gaps. Nick: interesting and important. Logical solution might be more gTLD-like. Escrow and EBERO. Potential consequences. Sovereign nature of the ccTLD might be eroded. There is a bright line. ccTLDs that will step in, in case of need. Jordan: where is boundary between policy and practice/implementation? Different authorities? Regarding the meta-structure, how to extract the bits. Think about a new ccNSO role. Someone who is responsible for coherence of the ccnso policy framework? Irina: side-effect of this discussion. Consolidated policies and the overall structure and vision makes it easier to understand for any person. The PDP is the most complicated piece of ccNSO work. Stephen: both RET and RM were developed via a consensus approach. Many meetings, and long time. Maybe we should consider move away from consensus process, to a formal voting process? Jordan: interesting suggestion. Who knows where to find definition about consensus processes to making policy? Chris: work is fine, but not presented well. We need to sort this out. Our responsibility Jordan: consolidation is just a word. Bart: see charter of the WG what the consensus process is Pablo: thanks for the work you have done. And for giving us the opportunity to discuss Jordan: we are grateful to Kim and team for providing the insightful and useful input, and for progressing the discussion Sean: thanks to Kim. very informative. Kim: appreciate the invitation to be frank. Last few years, noticed that we get better policy, if we share operational insights Javier: what is outdated? Kim: we do data quality campaigns. We collect e-mail bounces and follow-up. We are not empowered to update, unless they fix it. Molehe: 2nd case study. The sooner we get a solution, the better. My position, depending on national legislation. Pablo: critical that whatever we do will be communicated to the relevant authorities Jordan: report back to community about this workshop during Welcome session on Tuesday morning, starting at 08:30 Alejandra: be considerate during the report. Ensure that it is not conveyed as a Council initiative only Biyi: lots of complexities. All potential options Jordan: start with brainstorming regarding other gaps. We hoped to do so today, but ran out of time Process management Bart presents a roadmap. Step 1: Agree on 3 area approach (Council Workshop ICANN78) Step 2: Agree method to assess various process management models to address 3 areas (ICANN78) Step 3: Understand details and and assess nature of areas to be addressed (policy <-> operational) (November 2023-December 2023, ad-hoc group) Step 4: Rank areas/process management model combination in order of priority (Effort/Impact analysis used also by the Triage Committee, January-February 2024) Step 5: Inform and consult broader community on process method per area and prioritization (ICANN79) 90 min session, potentially even longer. Step 6: Launch Process to address prioritized area (post ICANN79, planning request issue reports etc.) During the Council meeting on Thursday, ensure the ad hoc group is empowered to continue the discussion. Useful to reference to that Council decision. Nick: hand off of control from broader community of ccTLDs to council. Do we have that authority? Formalise this? Procedural stuff, which we may need to do Bart: council identifies issues. That is a role for council. To prepare for whatever mechanism you want to use. See annex C of the bylaws. That is why Tuesday is important. Jordan: We inform the community that we foresee to do work on this on Tuesday morning. Chris: there is process and there is politics. This has to be about enrolling the community in every step on the way. Be careful. Not: “council will do this and that” If we start launching PDPs on this, governments want to be involved. Last resource. Jiankang: ccTLDs strongly relate to gvt. GAC comments might be needed in future. Jordan: will share my draft slides with small team. Let’s confirm membership of the small team on Thursday’s council meeting Alejadra: thank you and wrap-up Joke Braeken joke.braeken@icann.org<mailto:joke.braeken@icann.org> ICANN78: Links to bookmark now ccNSO Schedule https://community.icann.org/x/doDxDg ccNSO Session Highlights https://community.icann.org/x/K4LxDg
participants (1)
-
Joke Braeken