Dear TPR WG members,

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

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

Best regards,

Emily, Julie, Berry, and Caitlin

ACTION ITEMS/HOMEWORK:

1. Small Team on Exemption for Recommendation 16 and 17 to send proposed language and rationale to the list before the next meeting.
2. Small Team on TTL enforcement to send proposed rationale to the list before the next meeting.

Notes:

Transfer Policy Review - Meeting #76

Proposed Agenda

10 January 2023

1. Roll Call & SOI updates

2. Welcome and Chair Updates

3. Proposed Work Plan Update & Project Change Request

• Plan for the PDP looking at the subjects in the charter, timeline, and what was planned.
• GNSO Council agenda for 19 January to provide an update on the work plan and proposed Project Change Request.

Summary:

Original phased approach:

Phase 1(a):

• Form of Authorization (including Rec. 27, Wave 1 FOA issues)
• AuthInfo Codes
• Denying (NACKing) Transfers

Phase 1(b): 

• Change of Registrant (including Rec. 27, Wave 1 Change of Registrant issues)

Phase 2: 

• Transfer Emergency Action Contact
• Transfer Dispute Resolution Policy (including Rec. 27, Wave 1 TDRP issues)
• Reversing transfers
• ICANN-approved transfers

As a reminder, the phased approach initially seemed logical for two reasons: 

• The phased approach is consistent with PDP 3.0 Guidelines, Enhancement 11, which provides “a PDP should have a narrow scope and, in those cases where a subject is broad, it needs to be broken into manageable pieces.” 
• It also allowed for the possibility of implementation work for Phase 1 recommendations in parallel with Phase 2 policy development work.

Original timing:

Phase 1A Initial Report	June 2022 (complete)
Phase 1B Initial Report	March 2023
Combined Phase 1 Final Report	August 2023
Phase 2 Initial Report	TBD
Phase 2 Final Report	January 2026 (approximate)

Why is a change needed?

• The Working Group identified dependencies between the Phase 2 and Phase 1 work. Specifically, the working group will need to make substantial progress on Phase 2 topics TDRP and/or TEAC before it can finalize Phase 1A and 1B recommendations pertaining to inter-registrar and inter-registrant transfers. The current project plan anticipates two fully independent phases, but this is not workable in practice.
• Phase 1A preliminary recommendations have been substantially revised following the public comment period and may be revised further following discussion of TDRP and/or TEAC. Additional community input through public comment is warranted on these revisions.
• Phase 1A is behind schedule due to a public comment extension and the need to consider a number of substantive comments, which has also resulted in Phase 1B work falling behind schedule. A work plan adjustment would be needed for this reason alone, independent of the above points.

Proposed change:

Combine Phase 1 and Phase 2 into a single body of work, with a combined Initial Report and Final Report covering all topics. Reorder the sequence in which topics are addressed by the PDP to account for dependencies between topics.

Proposed work plan:

Milestone	Target Date
Phase 1A Initial Report	June 2022 (complete)
Combined Phase 1A (revised), 1B, and 2 Initial Report (75 day public comment)	August 2024
Combined Phase 1A (revised), 1B, and 2 Final Report	February 2025

Benefits of the proposed change:

• Allows the working group to deliberate on all topics iteratively and consider the dependencies between recommendations in different topic areas.
• Allows the community to review all draft recommendations as a single package, taking into account dependencies between recommendations in different topic areas.
• A single, extended public comment period of the combined Initial Report will allow ample opportunity for the community to review the package of draft recommendations and provide input. 
• Fewer public comment periods and combination of outputs will allow the working group to reduce the overall timeline of the PDP.
• Reduces burden on the volunteers, as the PDP no longer anticipates a Phase 1 IRT in parallel with Phase 2 policy development. In addition, only a single IRT will now be needed.

Additional Considerations:

• The draft revision of the work plan anticipates that the PDP will conclude in Q1 2025. Some working group members may not be able to commit for the full length of the PDP.

• The working group may want to consider if there if there is a logical point in the PDP in which groups are invited to adjust their membership.
• Given that participation in the PDP is already uneven in terms of both membership and attendance (e.g. real-time participation) and attendance overall is trending downward, this may be a good moment for groups to consider how they can best ensure sustained engagement through the life of the PDP.

Next steps:

• PDP update and preview of the Project Change Request during 19 January GNSO Council meeting.
• Wrap up discussion on Phase 1A topics by end of January.
• Briefly revisit status of Phase 1B discussions, including any touchpoints with Phase 2 Topics in early February.
• Begin Phase 2 deliberations in early February.
• GNSO Council vote on Project Change Request during 16 February GNSO Council meeting.

Discussion/Questions:

• Question: Is ICANN approved transfers a topic for discussion? Yes, for bulk transfers.  We aren’t changing any of the original charter questions.  There are a couple relating to bulk transfers in Phase 1a.  ICANN-approved transfers has always been part of Phase 2.  Said we would talk about bulk transfers later at the same time as ICANN-approved transfers.  This is about changing the plan to make sure the work is sequenced in a logical way.
• Should help to minimize the lost cycles – good change.
• We aren’t changing the scope, just trying to be more efficient.
• Hopefully the extended, consolidated comment period reduces the concerns from those beyond this group who'd have preferred two comment periods.

4. Proposed redline from Small Group on Exemption for Recommendation 16 and 17

• On final edits and hope to get the proposal out today.
• Steinar: discussion in At-Large WG – If you have the opt out feature it could encourage registrar jumping.  No consensus but will discuss again tomorrow.  See Google doc of comments at: https://docs.google.com/document/d/1O3vBcIr-mkDcdF5hX8jRcLXu0DoIWDTgMl4HrUQBWYs/edit?usp=sharing.

ACTION ITEM: Small Team on Exemption for Recommendation 16 and 17 to send proposed language and rationale to the list before the next meeting.

5. Rationale for Recommendation 13 - Registry enforcement of TTL Enforcement

• Here is a draft rationale for registry enforcement based on the public comments received at: https://docs.google.com/document/d/1Wq4dHcIFR5XogoutSh0klkCyhZFUlS1z7cl2ilv9c9I/edit?usp=sharing and here:

Draft Rationale: The purpose of the standard TTL is to enforce security around unused TACs (e.g., requested/received but not used), in a situation where the TAC may be stored in a registrant’s email or other communications storage. The working group supports the CPH TechOps conclusion that the TAC TTL should be no more than 14 calendar days and notes that a 14-day period is appropriate in order to accommodate transfer-related business processes associated with different registrar models.

The working group extensively discussed whether the Registry or Registrar should enforce the 14-day TTL and requested community input on this question through public comment on the Phase 1A Initial Report. The working group recommends enforcement by the Registry for the following reasons:

• The Registry is the central authority for registrations, and therefore is the appropriate party to enforce a standardized and consistent TTL.
• It is a more secure and streamlined approach due to the lesser number of Registry Operators as compared to ICANN-accredited Registrars.
• The TAC is set at the Registry, and therefore it is logical for the Registry to set the TTL and enforce the 14-day limit through the system as soon as the TTL expires.

With respect to 13.2, the working group acknowledged that there may be a variety of circumstances in which the Registrar of Record and the registrant may want to mutually agree to reset the TAC to NULL prior to the end of the 14th calendar day. The working group included this language to ensure that Registrars are permitted to do so under relevant circumstances.

Discussion:

• Question: In Rec #3 We proposed “Date and time that the TAC was issued and information about when the TAC will expire”, will the expire be given by the Registry?
• 13.2 came up because a 14-day window may seem large to some people and that’s why it says agreement of the registrar and the RNH.
• Left some flexibility to shorten the time, but didn’t define how much time the registrant had for the transfer.  We did find that there is a diversity among registrars for various shorter periods.
• One of the reasons the TTL was proposed was to stop having no limit – the longer side, to make sure it didn’t live forever.
• Small Team and registries are likely to shorten the draft rationale language.
• Trying to make as few changes as possible to a complex process.
• Basically, some registrars might implement the NACK by setting TAC to NULL , either to ensure no transfer could be initiated or to be thorough, with or without the eligibility statuses.
• Having a TTL is a key security feature.
• The idea of including the TTL in the TAC was discussed in the review of public comments and not adopted because of security issues relating to gaming the system.
• Did not consider where the TTL would be stored at the registry – that should be private for security reasons, and because we are talking about making modest changes.
• Recommendation #3 does require that the expiration is notified to the RNH.
• Small Team will suggest a revised rationale to the WG on the list before the next meeting.

ACTION ITEM: Small Team on TTL enforcement to send proposed rationale to the list before the next meeting.

6. AOB:

Revised Swimlane – see attached.

• Request was for staff to update the Swimlane.
• Staff will send a revised version (see also attached).
• Extend the deadline for the review of the redline of the Phase 1a recommendations to 23 January.  This is not meant to be a big exercise --  just focus on the specific redline edits to the recommendations based on the review of the public comments and the WG’s preliminary agreement.