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
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.
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".
See TPR Public Comment
Review 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)
Skype: atchen122