Dear all, To be added to this from the minutes distributed to the GNSOTPR WG by ICANN Org staff: Recommendation 33: Debate over expanding TDRP to registrants. The WG Chair pointed out that the decision is with the GNSO Council. Outcome: Suggestion to highlight need for a separate process for registrants rather than expanding TDRP. WG agreed that this should be further discussed at the GNSO Council. Regards, Steinar Grøtterød From: Andrew Chen <andrew.chen@icann.org> Date: Wednesday, 18 December 2024 at 16:07 To: CPWG <cpwg@icann.org> Cc: Steinar Grøtterød <steinar@recito.no>, ICANN At-Large Staff <staff@atlarge.icann.org> Subject: [CPWG] MINUTES FROM THE GNSO-TPR MEETING ON DECEMBER 17, 2024 Dear CPWG Members, On behalf of Steinar Grøtterød, we are sharing the minutes from the 17 December 2024 Transfer Policy Review. Please feel free to reach out if you have any questions. Review of updated recommendations Rec. #9: TAC Time to Live (TTL) Added by the Registry Stakeholder Group (RySG): 9.4: The Registry MAY reset any TAC to null4 prior to the end of the 336 hours (i) by agreement by the Registrar of Record OR (ii) without the agreement of the Registrar of Record in cases where when resetting the TAC to null is in the best interests of the Registrar of Record or the RNH, e.g., security breach, account compromise, etc. 9.5: If the Registry resets any TAC to null without the agreement of the Registrar of Record, the Registry MUST provide the rationale to the Registrar of Record if requested by the Registrar of Record. Rationale: Similar to the Registrars requirements, the Registry Operator MAY reset the Transfer Authorisation code (TAC). This option for the sponsoring Registrar and the Registry Operator will reduce the harm when there is a security breach, account compromise, etc. Reco. #17: Losing Form of Authorization (FOA) 17.5: The Transfer Confirmation MUST NOT include a mechanism for immediately approving the inter-Registrar transfer. Implementation Guidance: The working group notes that Recommendation 17.5 does not prevent Registrars from sending a transfer approval mechanism to the RNH, but rather stipulates that this mechanism must not be included within the Transfer Confirmation. Rationale: There is agreement to have a 5 days "freeze" from the time where the transfer is initiated. Rec. #17.2: The Transfer Confirmation language MUST include the Gaining Registrar’s IANA ID and a link to ICANN-maintained webpage listing accredited Registrars and corresponding IANA IDs. If available, the name of the Gaining Registrar MAY also be included. This notification shall not include an "auto approve link". Rec. #33: Request to GNSO for further work on Transfer Dispute Resolution Policy and Potential New Dispute Mechanism See TPR Public Comment Review <https://docs.google.com/document/d/1YODFe-aZOi1AQ3c8f2-y8MXtcUU4PjzsByFzk-dp...> for proposed wording. Another session of discussion between At-Large and "the Rest". The final recommendation is not presented for the Working Group. My understanding is that there is consensus for a policy where the RNH can challenge improper transfers, including compromised and stolen domain names. However, the majority of the Registrars believe the TDPR is not the best place to add the RNH rights. -- Andrew Chen Policy Development Support Sr. Specialist, Policy Development Support Internet Corporation for Assigned Names and Numbers (ICANN) https://www.icann.org/ Skype: atchen122