2025-01-28 Transfer Policy Review PDP WG Call

Notes/ Action Items

Action Items: Consensus Call and Final Report

WG Members are kindly asked to provide final edits deadline: Friday, January 31, 2025.

• What can still be changed?

• Grammar, formatting, and minor clarifications.

• No substantive edits to recommendations.

• Final Report Submission: Next week to the GNSO Council.

Link to TPR Final Report Review Tables:https://docs.google.com/document/d/12Eoei5W6VShD-JbbD9SS2ZyZe8cT-mROpjGwxAQ3OP0/edit?usp=sharing [docs.google.com] 

1. Welcome and Chair Updates

• WG Chair thanked the working group members for their dedication over the years in reviewing and refining the Transfer Policy.
• Consensus Call Review:
• WG Chair reminded the group that a consensus call was sent out last week.
• The consensus call remains open through Friday and will close at the end of the day Friday.
• The final report will be submitted to the GNSO Council next week.

1. Final Report updates (TBD)

• ICANN Org confirmed that previously reviewed updates had been highlighted in the last meeting.
• No objections were raised regarding prior updates.
• The meeting proceeded with reviewing RySG comments and document cleanup items suggested by Rick Wilhelm.

2.1. Specific Change Proposals

• Line 284 – Clarification of "Post Creation Lock" Period
• Proposal: Replace “a 60-day post creation lock (or period other than 30 days)” with “such a period.”
• Reasoning:

• 60-day post-creation locks vary among registries (e.g., 45-day, 75-day).
• The existing phrase is redundant.

• Outcome: Accepted.
• Line 552 – Clarification on Setting TAC to Null

• Proposal: Reference RFC 9154, Sections 4.4 and 5.2 for clarity.

• Reasoning:

• The term "resetting the tag to null" is overly technical.

• The RFC contains clearer, standardized definitions.

• Outcome: Accepted.

• Line 747 – Reference to ICANN Data Retention Requirements

• Proposal: Replace “must provide such records to ICANN upon reasonable notice” with “is responsible for its own compliance requirements contained therein, as they may change from time to time.”

• Reasoning:

• Specific data retention rules may change in the future.

• Aims to ensure policy flexibility.

• Outcome: Accepted.

• Lines 936–939 – Redundancy Between Sections 18.1 and 18.2

• Proposal: Remove Section 18.2 as it is redundant.

• Discussion:

• 18.1: Requires registrars to demonstrate receipt of a request.

• 18.2: States that requests must come from the registered name holder.

• It was discussed that 18.1 already implies 18.2.

• WG members raised concerns about ensuring requests are specific and not bulk portfolio-wide.

• ICANN Org suggested adding further language in 18.1 stating that the request must be domain-specific.

• Outcome:

• 18.2 was removed.

• Add footnote to 18.1 to mention domain-specific requests from the registered name holder.

• Line 968 – Standardizing 720h (30-day) Transfer Restrictions

• Proposal: Align Rec. 18 with Rec. 3 by explicitly stating that all transfer restrictions must be standardized at 720 hours (30 days).

• Reasoning:

• Rec. 3 (Initial Registration Locks) already mandates a standard 30-day period.

• Rec. 18 should mirror Rec. 3 to avoid inconsistencies.

• Outcome: Accepted.

• Other Grammatical and Formatting Adjustments

• Several minor grammatical improvements were noted.

• Outcome: ICANN Org to implement editorial corrections.

1. Consensus Call check-in

• Final edits deadline: Friday, January 31, 2025.
• What can still be changed?

• Grammar, formatting, and minor clarifications.

• No substantive edits to recommendations.

• Final Report Submission: Next week to the ICANN Council.

1. AOB

• WG Chair thanked all members and ICANN staff for their hard work and dedication