Dear TPR WG members,

Please find below the notes and action items from today’s meeting.

The next meeting will be on Tuesday, 24 January 2023 at 16:00 UTC.

Best regards,

Emily, Julie, Berry, and Caitlin

ACTION ITEMS/HOMEWORK:

Swimlane:

1. WG members to review and provide comments and technical WG members in particular to review language relating to EPP actions to make sure it is accurate/clear.
2. Preliminary Recommendation 11: check the language for operational accuracy – particularly the suggested revised language: “The Registry Operator MUST reset the TAC to null as part of completing the successful transfer request when is accepts a valid TAC from the Gaining Registrar

Proposal on Exemption for Recommendation 17:

3. WG members to review and comment on the list.  See attached document.

Notes:

Transfer Policy Review - Meeting #77

Proposed Agenda

17 January 2023

1. Roll Call & SOI updates

2. Welcome and Chair Updates

• Reminder – deadline extended for comments to Recommendations 10-22 to 23 January.
• Any updates to the Recommendation 13 TTL rationale?  Not at this point.

Threat vectors Small Team: In the works.

Steiner (ALAC): Recommendation 16 – clarify whether there is any consensus on this proposal.  Think the Small Team agreed that an exemption wasn’t needed for the Recommendation 16 restriction (lock) post-registration.  Won’t have a common reason to opt out of the 30 days post-creation lock.  So, Recommendation remains the same.  Not clear yet if there is support for an opt out re: Recommendation 17 (see below).

3. Updated Transfer Process Swimlane (see attached and at: https://community.icann.org/display/TPRPDP/2023-01-17+Transfer+Policy+Review+PDP+WG+Call)

Summary:

• This will never be perfect – it is conceptual in nature and not meant to be a policy document.
• Starting to get busy and complicated – lots of worm holes; even once stable it will be subject to change re: Phase 1b, CoR, Phase 2.  Need to create a space for CoR.

Details of Revision:

• Substantive changes from Initial Report.
• What hasn’t changed is the general use and expiration of the domain.
• Post-Create Transfer Restriction: Gap in the rationale around the reasons for why we are implementing the change as opposed to what is in the marketplace today.
• Timeframes: 1) Made consistent to hours and calendar days across all recommendations; 2) transfer policy is more technical in nature so timeframes will be coded – so set a hours. But include both hours and days as a compromise – hours for technical use, and days for readability.
• Yellow sub process re: established customer procedure – placeholder for now until discussed/agreed in the WG.
• Couple of substantial changes in the first task:
  • From the moment the RNH requests the TAC the 120 hour-clock starts.
  • “Frictions to Cure” – New part: further deliberations made clear that previous version of the swimlane didn’t account for what really happens – check of validity of the TAC before it is sent to the registry. 
  • If an issue it will be the gaining registrar that is notified that the TAC is not valid.  Enter a worm hole.  Process in effect starts over.
  • Assuming that the TAC is valid, registry does the check on whether the TTL is expired (Rec 13) – Gaining Registrar will need to send an (operational) notice that the TTL is expired and RNH needs to make a decision. 
  • If not expired registry sets to pending transfer, reset the TAC to null, and terminate the TTL.
  • RNH receives transfer confirmation – if choose to cancel (Rec 2) the Registrar of Record will invoke the cancellation procedure.  If RNH does accept the transfer the Losing Registrar send the poll message – ask technical-oriented WG members – confirm language adjustments to make it more clear what is actually happening in EPP.
  • Challenge at Gaining Registrar is not likely to reflect what actually happens. Logic is there to help facilitate how we are using the worm holes.

Discussion:

• Points of clarity:
  • 1) Setting domain to “Pending Transfer” after TTL expired –
    • If the TTL is expired means that the TAC is no longer present/valid and should not be treated as present – that’s all the registry knows and if not present would treat it as null – only the Registry of Record knows if it is expired. 
    • There is no response from a registry that would say “TTL expired” – it can either accept it, TAC is invalid, or say no transfer is permitted.
    • No such thing as the registry checking for an expired TAC. If it is expired it is null/invalid per the registry. 
    • So this decision box (TTL expired?) should go away – put a decision box “Is there a TAC present?” then check if it is valid, etc. All the steps around the TTL expired decision box goes away.
    • Registries responses on a failed TAC will be purposefully oblique.
  • 2) Set Domain to “Pending Transfer”:
    • Understand what this means operationally.  A TAC is considered used at the moment a valid TAC is received, not when the transfer is complete.  Once a valid TAC is received it is set to null and the TTL expires and completes the process with the Registrar of Record – a transfer cannot be tried again with that TAC.
    • The “pending transfer” and box to the right are all one state.  This is a combination state – the registry does not Set Domain to “Pending Transfer”.
    • The pending state is because of the Losing FOA process.
    • The losing FOA changed, but the requirements of it haven’t. So, yes. ‘Pendingtransfer’ would still remain.
    • Removing the ‘pendingtransfer’ would cause so many issues for CS and also for registrants.
    • Confirm that there isn’t anything in the recommendations at this point that is specifically for the registry to Set the Domain to “Pending Transfer”.  May need to take a closer look at this.
    • Preliminary Recommendation 11: “The working group recommends that the TAC as created by the Registrar of Record according to Preliminary Recommendation 7, MUST be “one-time use.” In other words, it MUST be used no more than once per domain name. The Registry Operator MUST reset the TAC to null  as part of completing the successful transfer request.”  Final sentence may be misleading.  Need to make sure this language is technically accurate.
    • Proposed revised language (change in bold):  “Preliminary Recommendation 11: The working group recommends that the TAC as created by the Registrar of Record according to Preliminary Recommendation 7, MUST be “one-time use.” In other words, it MUST be used no more than once per domain name. The Registry Operator MUST reset the TAC to null as part of completing the successful transfer request when is accepts a valid TAC from the Gaining Registrar.”

ACTION ITEM re: Swimlane

1. WG members to review and provide comments and technical WG members in particular to review language relating to EPP actions to make sure it is accurate/clear.
2. Preliminary Recommendation 11: check the language for operational accuracy – particularly the suggested revised language: “The Registry Operator MUST reset the TAC to null as part of completing the successful transfer request when is accepts a valid TAC from the Gaining Registrar

4. Proposed redline from Small Group on Exemption for Recommendation 17 (see attached)

Proposed redline:

Preliminary Recommendation 17: Registrars MUST apply a 30-day post-change of registrar lock by default for all domain names transferred into a Registrar, however on a case-by-case basis and where an Established Relationship exists, the Registrar may unlock the domain name in less than thirty (30) days for the purpose of an inter-registrar transfer, on a case-by-case basis. An Established Relationship means a RNH who has; a)  received registrar services for a period of  at least thirty (30) days; and b) a history of regular interactions with the Registrar and who has demonstrated a willingness to continue receiving registrar services from the Registrar in the future.

Discussion:

• Idea is to keep the post-transfer and post-create restrictions, but to allow an opt out for the post-transfer limited to Established Relationship.
• When it gets transferred in the restriction is placed, the registrar has the option to remove the restriction upon the request of a RNH with an Established Relationship.
• Lock is still mandatory (“MUST”).
• Would require manual intervention to determine that an RNH has an Established Relationship – makes it harder to remove the lock.
• Still an agreement between the registrar and registrant.
• WG members should review and comment on the proposal.

ACTION ITEM: Proposal on Exemption for Recommendation 17 – WG members to review and comment on the list.  See attached document.