Dear TPR WG,

Please find below the notes from today’s TPR Meeting #2. As a reminder, the next TPR meeting will be Tuesday, 25 May at 16:00 UTC.

We wish everyone a wonderful weekend.

Best regards,

Emily, Berry, and Caitlin

Transfer Policy Review PDP 

Meeting #2

21 May 2021, 18:00 UTC

Meeting Notes

1. Roll Call & SOI Updates (5 minutes)

2. Welcome & Chair updates (Chair) (5 minutes)

• For the first few weeks of meetings, the team will be reviewing all of the topics and associated charter questions. We’ll be deciding if the topic is small, medium, or large or, said another way, easy, medium, difficult.
• We will discuss the topic broadly to ensure everyone understands it and gather initial feelings of difficulty.
• We will also denote potential dependencies (if any).
• Following review of the charter questions, does the WG think anything is missing?
• We will be using the charter questions as the outreach questions for SOs/ACs.
• A few weeks from now, we should have a general road map for how long Phase 1A and Phase 1B will take.
• The Support Staff Team needs more information regarding the context of the topics. As we review through the policy topics and charter questions, please think about roughly how long deliberations on a particular topic may take. For each one of these topics, we will utilize “the crank”. We will discuss, staff will document, and the WG will arrive at preliminary conclusions and preliminary recommendations.
• This review covers two primary tasks: (i) production of a work plan with reasonable delivery dates back to the Council; (ii) preliminary outreach to the SOs/ACs – this discussion will assist in arriving at the final outreach model.
• In terms of the duration, how long will it take for the WG to deliberate these topics – this will entail determining the complexity of the issue and how far apart the group is on the issue.
• We will not be using a calendar-based approach for this assessment. Instead, how many hours of on-call deliberations will it likely take for the group to move through this topic?
• This discussion is critical for developing the project plan.
• Can some of these topics be discussed in parallel or are there dependencies? For example, is there a dependency to getting to preliminary conclusions on Gaining and Losing FOAs, or can the group discuss Auth-info codes in parallel? It’s critical for the group to flag dependencies during this exercise.

3. High-level Review of Phase 1A Charter Topics & Charter Questions (30 minutes)

• Gaining and Losing FOAs
• We will review terminology everyone should be familiar with for the first charter topic.
• Gaining Registrar: The registrar to which the registrant is transferring the domain name.
• Losing Registrar: The registrar from which the registrant is transferring the domain name.
• Gaining Form of Authorization: A required form sent by the Gaining Registrar to the Registered Name Holder to confirm the Registered Name Holder’s intent to transfer the domain name. 
  • Typically an email to Registered Name Holder to confirm intent by clicking a designated link.
• Losing Form of Authorization: Losing Registrar sends the Registered Name Holder a notice to confirm Registered Name Holder’s intent to transfer.
• EPDP included the workaround from the Temporary Specification in its recommendations, which were adopted by the ICANN Board.
• Registrars identified challenges in ICANN org’s position that a Gaining Registrar is required to send a Gaining FOA where the email address “is available”, as there is no guarantee that the email goes directly to the registrant. 
• ICANN Board passed a resolution to defer contractual compliance enforcement of the Gaining FOA requirement pending further work in this area.
• Contracted Party House Tech Ops Subcommittee has developed a proposal for a proposed transfer process.

• Auth-Info Code
• What is the auth-info code?
• Unique code created by a registrar on a per-domain basis to identify the registrant of the domain name.
• How is the auth-info code used?
• AuthInfo Code needs to be provided to the gaining registrar as part of the inter-registrar transfer process.
• How is it provided?
• Losing registrar may provide AuthInfo Code via control panel, or by other means within 5 calendar days (email, SMS, etc).

• EPDP Rec. 27.
• Recommendation 27 in the EPDP Team’s Phase 1 Final Report recommends updating existing policies / procedures to ensure consistency with the EPDP’s outputs.
• In its Wave 1 Report, ICANN org performed a detailed analysis of 15 policies and procedures, including the Transfer Policy and Transfer Dispute Resolution Policy. 
• There are items in the Wave 1 report related to FOA, Change of Registrant, and TDRP. 
• For Wave 1 report items related to each topic, the Working Group will consider how the issues should be addressed and whether any need to be resolved urgently.
• How will these issues be addressed, and there is anything that needs to be resolved urgently?

4. Phase 1A Charter Topic #01 Discussion – Gaining FOA (30 minutes)

• The effort for the FOA should be relatively easy.
• Based on the tentative removal of this requirement due to GDPR, we can likely sunset the gaining FOA soon.
• The Gaining FOA is very different from the Losing FOA since it requires an action by registrant. It was an automated process. Because some information is redacted, it could not work anymore. It’s been almost 3 years since this requirement was removed, and there does not seem to have been an increase or uptick in unauthorized transfer request, which seems to indicate the requirement can be removed.
• How long will this issue take for the Team to deliberate this?
• This should not take much time.
• Small to medium effort for this topic.
• Seems most agree that we should eliminate the FOA, and the level of effort will be small or medium.

5. Phase 1A Charter Topic #02 Discussion – Losing FOA (15 minutes and time permitting) –

- Tech Ops process is a helpful starting point for this work, so the amount of work to make this decision is lower. Would scope this as low.

- Keeping the Losing FOA makes sense, but there may be changes to the Losing FOA

- Suggest review of available data for this question and the gaining FOA question

- If there is no source of compliance data, take it at face value and move forward.

- Are there any concerns about the registrant not able to get the auth-code from the registrar? The group should look into this

- If we keep locks, we should document why.

- For the level of effort associated with locking – this could be a large issue – it may be a medium effort.

- If the lock were to go away, a name could be hijacked multiple times in a matter of days.

- Is 60 days the correct number?

- Is it possible to have a trusted mechanism in terms of a registrant actually initiating this request?

- There seems to be widespread misunderstanding of the locking issue. It may be interesting to see some data from ccTLDs regarding this. If this is a permissive regime, there should be some consideration if it is affirmatively required to registrants. This is a medium issue.

- There are multiple locks – for example, a 60-day lock after change of registrant that the registrant can opt out of

Auth Codes

- The Tech Ops paper has a lot of feedback on this issue

- This topic is tough – should there be an automatic ACK? This is really the hardest question to answer regarding the original transfer process. It is a large issue.

- There are many registrants who do not understand what an auth-code is and how to use it. It’s difficult to get the auth-code. May need to consider processes that enable the registrant to get the auth-code more easily.

- Is it worth discussing these issues prior to FOA discussions?

- There are two important parts of an auth-code – identifying a registrant and on the backend in the case of the incumbent registrar, there were some discussions about the role of the registry in auth-code management. This issue deserves a fair amount of discussion. If the auth code is properly managed, this could establish a proper paper trail. This is a high-touch topic.

- The WG seems open to discussing the auth-info code prior to deliberating on the FOAs.

6. Next steps & closing (5 minutes) –

                      - WG members should have received 3 invites. The tentative meeting time is Tuesdays at 16:00 UTC.

                      -  The 1 June meeting will be 60 minutes so as not to interfere with the GNSO Policy webinar. There will be also be a break the week after ICANN71.

                      - We will review this time in the coming weeks to make sure it still works for everyone.