[lac-discuss-es] Actualización CPWG
[[-- Translated text (es -> en) --]] Dear members of the community, I'm sharing a summary of the main topics discussed at the meetings of CPWG of April 29 and May 6, 2026. For more details, they can consult the wiki pages for each session. *Links to CPWG sessions* April 29, 2026 <https://icann-community.atlassian.net/wiki/spaces/atlarge/pages/1066237953/2...> May 6, 2026 <https://icann-community.atlassian.net/wiki/spaces/atlarge/pages/1097728007/2...> *1. Workgroup and Small Team Updates* *PDP1 on DNS Abuse Mitigation: Domain Name Verification Associates <https://icann-community.atlassian.net/wiki/spaces/alacpolicydev/pages/103245...> * Discussions covered: - Q3 What should be understood as a “reasonable investigation” by of a registrar?, seeking to define what information a registrar should review recorder, what signals should be considered and what would the steps be minimum expected during an investigation related to DNS abuse. - Use of “reasonably available” data: that the registrar should review the information reasonably available within their systems or contractual relationships, without this necessarily implying access to data that it does not possess. It was discussed that in some operating models, especially when resellers are involved, certain relevant information It can only be found in the hands of the reseller and not directly from the recorder. - Risk that an overly flexible policy will allow for non-compliance superficial. It was suggested that if the policy only requires reviewing a minimum data point (“datapoint”), a recorder could be limited to verify a single indicator and consider their obligation fulfilled research. From an at-large perspective, this could create gaps. (“loopholes”) and reduce the effectiveness of investigations against DNS abuse. - Balance between effective research and privacy protection and personal data. The discussion on Question 4 of the Charter (“Charter Question 4”) focused on how to allow the use of sufficient information to investigate abuse without the data being used for purposes other than those intended. specific to the research. - The conversation about differentiating between registers was also resumed of natural and legal persons, although it was noted that in cases related to malicious records the information used many times It may be false or compromised, which limits its practical usefulness. that differentiation within this process. *Supplementary Recommendations Team of the Standardized System of Access and Disclosure (SSAD SRT) / Data Request Service Registry (RDRS)* It was reported that the work of the Supplemental Recommendations Team of The Standardized Access and Disclosure System continues to advance and is They were expecting further meetings before ICANN86. It was also mentioned that At-Large already has a defined representation within the team. There were no substantive updates to the Data Request Service Registration during these meetings. *Other topics listed on the agenda, such as the Universal Use Working Group (UAEWG), the Policy Process on Latino Diacritics, the Second IANA Name Function Review (IFR2), the Process Expedited Domain Name Policy Development Internationalized (EPDP-IDNs), the Transfer Process of Registrars (TPR-PDP) and the Registration Data Area (RDA) remained without substantive discussion in these sessions*. *2. At-Large Policy Initiatives* *DNS Abuse* Discussions continued regarding the related At-Large strategy with mitigation of DNS abuse. Reference was made to the webinar <https://icann-community.atlassian.net/wiki/spaces/atlarge/pages/1012498450/2...> done April 14th on mitigating DNS abuse and the document collaborative <https://docs.google.com/document/d/1smchQvYap04IMu7BCiAj6TWEhhxFE7wqayI8CyYd...> used to gather resources, references, questions and initiatives community. The objective of this work is to gather information that will allow the development of At-Large's own agenda on DNS abuse, including possible contributions to PDP1, educational materials, awareness campaigns and Compilation of regional experiences related to phishing and fraud online and end-user protection. The community was also invited again to continue contributing materials and references to the collaborative document <https://docs.google.com/document/d/1smchQvYap04IMu7BCiAj6TWEhhxFE7wqayI8CyYd...> . *3. Implementation Review Teams (IRTs)* *Privacy and Proxy Services Implementation Review Team (PPSAI IRT)* The PPSAI IRT continued discussing issues related to services Privacy and proxies, particularly the role of resellers. The conversation focused on potential gaps related to obligations contractual, data escrow, and scenarios where a reseller ceases operations without adequate mechanisms to recover the final registrant information. The possibility of extending certain obligations was also discussed. contractual to resellers through transfer mechanisms contractual obligations. *Next round of new generic top-level domains: Procedures Subsequent (SubPro), Permanent Predictability Review Team (SPIRT) and Applicant Support Program (ASP)* The opening of the application period for the 2026 round of new generic top-level domains on April 30 2026. Regarding the Applicant Support Program, it was reported that They had received 51 applications, of which 25 had already been evaluated, 22 approved and 2 withdrawn. The ASP is the program designed to support applicants who require assistance to participate in the next round. A proposal related to greater flexibility in the ASP financial eligibility assessment. Currently the threshold The reference financial threshold is USD 5 million, but ICANN proposed allowing a margin of up to 15% to account for exchange rate fluctuations, inflation and economic differences between regions. *Permanent Predictability Review Team (SPIRT)* Updates continued regarding the Permanent Review Team Predictability (SPIRT). This group was created to support the management of changes or unforeseen issues during the implementation of the next round of new gTLDs, with the aim of maintaining predictability and transparency in the process. The operation of the Guide Change Log was explained again. of the Applicant, used to document changes made to the Guide of Applicant and related documents. Changes are classified by type. Type 0 changes correspond to editorial corrections or minor adjustments; Type 1 corresponds to Minor operational changes; Type 2 corresponds to operational changes with possible material impact on applicants or processes; and Type 3 These correspond to policy changes. It was also noted that SPIRT cannot initiate cases on its own and that The issues must be submitted through the established formal mechanisms for your evaluation. *Registration Service Providers (RSPs)* A proposal (“issue submission”) related to the Registration Service Providers (RSPs), i.e., technical providers that operate registration services for new gTLDs. The discussion focused on technical requirements related to the Protocol. Extensible Provisioning (EPP). EPP is the protocol used for technical communication between registries and registrars (“registrars”). EPP extensions allow you to add functionalities additional to the protocol. Currently the Registration Service Provider Manual (“RSP”) Handbook”) and the technical tests called RST2.0 require that certain RSPs use EPP extensions registered with the Numbers Authority Assigned on the Internet (IANA). However, during the discussions of Base Registry Agreement for the next round, That limitation had been relaxed for registry operators. The concern raised is that this could create inconsistencies between different documents used in the evaluation process and limit the use of certain technical functionalities or extensions not yet formally registered with IANA. *4. Policy statements and public comments* Ratification of ALAC's comment on the Preliminary Assessment Guide for Community Priority Assessment <https://icann-community.atlassian.net/wiki/spaces/alacpolicydev/pages/991625...> (Draft Evaluation Guide for Community Priority Evaluation – CPE). Upcoming public comments related to the Rules were also mentioned. Additional Reference Label Generation <https://www.icann.org/en/public-comment/proceeding/additional-reference-labe...> (Additional Reference Label Generation Rules and Related Updates) and the Report Preliminary Review of Reviews <https://www.icann.org/en/public-comment/upcoming-proceedings> (Review of Reviews Draft Report). *5. ICANN86 and other topics* Preparation for ICANN86 was one of the recurring themes during both meetings. Possible topics for future CPWG sessions were discussed and activities related to mitigating DNS abuse, considerations linked to human rights, global public interest and protection of data, as well as proposals for the plenary meetings <https://icann-community.atlassian.net/wiki/spaces/atlarge/pages/979173388/IC...> A brief report on the Contracting Parties Summit was also shared. held in Manchester, where issues related to abuse were discussed DNS, data protection, the Uniform DNS Resolution Policy Disputes (UDRP), digital sovereignty, and other technical and regulatory aspects. The possible use of artificial intelligence tools or automated agents in meetings, particularly from an accessibility perspective and session tracking. *6. Participation of LACRALO* During this period, LACRALO maintained participation in the CPWG, including participation linked to PDP1 on DNS Abuse Mitigation already a Proposed plenary session for ICANN86. Distribution by session attendance LACRALO: April 29, 2026: Total attendees: *65 participants* Total attendees *LACRALO 4 participants (1 ALAC Member)* May 6, 2026: Total attendees *36 participants* Total attendees *LACRALO 4 participants (3 ALAC Member)* Kind regards, Eunice Alejandra Pérez Coello ALS Internet Society Mexico Chapter Member of ALAC
participants (1)
-
lac-discuss-es@icann.org