Dear TPR WG members,

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

The next meeting will be Tuesday, 05 July at 16:00 UTC.

Best regards,

Emily, Julie, Berry, and Caitlin

Action Items: None.

Notes:

Transfer Policy Review Phase 1(a) - Meeting #51

Proposed Agenda

28 June 2022

1. Roll Call & SOI updates

2. Welcome and Chair Updates

• Thanking the group: Hit our first major milestone last week by publishing our Initial Report for Phase 1a for public comment on schedule.
• ICANN74 started our next phase and topic – Change of Registrant (COR). Seemed good support for continuing the COR policy.

a. Call schedule for July and August

• Public comment open on 21^st of June and scheduled to close on 2 August.
• Weekly calls are scheduled through 9 August.
• Discussions through 9 August will be focused on key COR questions.
• There will be no calls in the second half of August. WG members will be asked to review public comments during that period.
• Calls will resume 6 September. About a month of the work plan is allocated to public comment review.
• Target date for Phase 1(b) delivery is 29 March 2023.

3. Review of Phase 1(b) charter topics and workplan

See the specific charter questions at page 5 by topic with a summary here:

Overall Policy

d1) Are the goals of the policy still valid and if so how can they be achieve?

d2) If the policy is maintained, how to make it simpler but maintain safeguards.

d3) Should it be changed to a standalone policy and what guidance is needed if both registrant and registrar change?  How to review the applicability of the COR?

60-Day Lock:

d4) Big question is that there have been issues with this lock – key question is what should happen with this lock.  Also, questions related to issue of domain name hijacking.

d5) Survey responses indicate frustration with the lock.  If it is retained what options should there be for removal of the lock?

d6) Due to privacy requirements there has been a lack of public access to certain data, which may have reduced the risk of hijacking.  Is the 60-day lock not needed when underlying registrant data is changed?

d7) Concerns about hindering corporate acquisitions, consolidations, and divestitures of large lists of domains to new legal entities.

d8) Specific questions related to the policy language.

Change of Registrant – Privacy/Proxy Customers

d9) and d10) Application of CoR policy, and the 60-day lock, apply to underlying registrant data when the registrant uses a privacy/proxy service.

d11) Notifications relating to privacy/proxy services.

Designated Agent

d12) Questions relating to overuse of the Designated Agent.

d13) If the Designated Agent function is not operating as intended, should it be retained and modified? Eliminated?

d14) Are there alternative means to meet the objectives of Designated Agent role?

d15) Questions relating to the flexibility of the Designated Agent.

d16) Questions relating to the role of the Designated Agent, whether and how it should be changed, and what authority it should have over CORs.

Additional Questions

d17) The Registrar Stakeholder Group recommended the following in its survey response: “For a Change of Registrant, both the gaining and losing registrants should be notified of any requests, and should have the option accept or reject, over EPP notifications.” Should this proposal be pursued further? Why or why not?

e1) Re: Wave 1, Recommendation 27: How should the identified issues be addressed?

e2) Re: Wave 1, Recommendation 27: Can the Change of Registrant-related issue (identified in paragraph 6 of the Wave 1 report) be discussed and reviewed during the review of the Change of Registrant Process?

Change of Registrant Topics – timing:

• Overall Policy (40 days, approximately 6 meetings)
• 60-Day Lock (40 days, approximately 6 meetings)
• Privacy/Proxy Customers (35 days, approximately 5 meetings)
• Designated Agent (25 days, approximately 3 meetings)
• Additional questions (20 days, approximately 2 meetings)
• Wave 1 - Recommendation 27 (20 days, approximately 2 meetings)

Discussion:

• Could be issues with GDPR. We could take a look at that material change discussion – what is it, and the accuracy requirements under GDPR and privacy requirements.
• This provides a level set of what we are expecting.  Looks like a good plan with built in flexibility.
• Three important documents: Section 2 of current policy; charter; and Issues Report.

4. Continued discussion of charter questions d1-d3

High-level Discussion at ICANN74:

• Good discussion at ICANN74.
• Policy seems to be working but not sure it is achieving its goal as it stand now.
• There are some things we can do related to security, but not everything.  Could carry over some security aspects suggestion at ICANN74.

Working document: https://docs.google.com/document/d/1gu4sXGvyJeWJIfvaK_I7GKA6lAdfKFPQKaN4UMgzmcE/edit

Charter Question d1) According to the Transfer Policy Review Scoping Team Report, the Change of Registrant policy “does not achieve the stated goals” and “is not relevant in the current & future domain ownership system.” To what extent is this the case and why? Are the stated goals still valid? If the Change of Registrant policy is not meeting the stated goals and those goals are still valid, how should the goals be achieved?

Discussion:

• Key question is “Do the goals still make sense and can we create something that will support those goals.
• Registrars need to make an assessment of how high is their level of risk.
• Curious about the argument that in order to get your name to secure you have pay.
• Different registrars have different business models.
• Some registrants aren’t aware of the various security options from different registrars.
• Note that we are trying to solve a registrant issue.
• We don’t have numbers relating to the goal of preventing hijacking although we do have some numbers on complaints.

Charter Question d2) Data gathered in the Transfer Policy Status Report indicates that some registrants find Change of Registrant requirements burdensome and confusing. If the policy is retained, are there methods to make the Change of Registrant policy simpler while still maintaining safeguards against unwanted transfers?

Charter Question d3) The Transfer Policy Review Scoping Team Report suggests that there should be further consideration of establishing a standalone policy for Change of Registrant. According to the Scoping Team, the policy should take into account the use case where a Change of Registrar occurs simultaneously with a Change of Registrant. To what extent should this issue be considered further? What are the potential benefits, if any, to making this change? To what extent does the policy need to provide specific guidance on cases where both the registrar and registrant are changed? Are there particular scenarios that need to be reviewed to determine the applicability of COR?

• Gaining Registrar allows a new customer to input the Registrant information when requesting an inbound inter-registrar transfer. The information entered by the customer does not match Registration Data available in the Whois display.

• In the case of “thin” domain names, the Gaining Registrar obtains information from the Registry. If it is determined that the Change of Registrant policy should be retained and modified, the following specific areas may be appropriate for further review.

TPR Poll:

1. To what extent are changes to CoR requirements needed, taking into consideration changes to the landscape since the IRTP-C, available data, and/or personal experience? – 11 Responses

• No change is needed – 0%
• Only small adjustments are needed – 27%
• Significant changes are needed – 55%
• There should not be a CoR policy – 18%
• No answer/don’t know – 0%

Discussion:

• Most people thought the policy make sense with changes.

2. Are the CoR goals discussed during ICANN74 valid for the purposes of future policy work?  - 10 Responses

• All are valid – 36%
• Some are valid – 55%
• None are valid – 9%
• No answer/don’t know – 0%

Goals are:

• Standardize across registrars, creating a better/easier experience for registrants.
• Improve security by ensuring the changes are authorized.
• Manage instances of domain theft/hijacking (especially with respect to the 60-day CoR lock).

Discussion:

• Security is a baseline – but may this is a transparency of change, rather than a policy.
• Some registrars might use their experience of change of registrant as a way to differentiate through their business models.  Requiring the same processes of all registrars may stifle innovation.
• Could be some baseline requirements, particularly relating to security.
• Based on the poll there is agreement on something, but not clear what that is.

3. Should the working group further explore the proposal to apply principles and processes developed in Phase 1a to CoR? – 11 Responses

• Yes – 82%
• No – 18%
• No answer/don’t know – 0%

Discussion:

• One thing that is common is the confusion between the CoR and inter-registrar transfer. Most transfers are a registrant seeking to move from one registrant to another.  These should be dealt with separately.

4. Is the definition of what constitutes a Change of Registrant still appropriate or should it be changed? – 13 Responses

• Still appropriate – 38%
• Needs to be changed – 62%
• No answer/don’t know – 0%

Definitions:

A.1.3 "Material Change" means a change which is not a typographical correction. The following will be considered material changes:

1.3.1 A change to the Registered Name Holder's name or organization that does not appear to be merely a typographical correction;

1.3.2 Any change to the Registered Name Holder's name or organization that is accompanied by a change of address or phone number;

1.3.3 Any change to the Registered Name Holder's email address.

For avoidance of doubt, nothing prevents the Registrar from treating any change to the Registrant Name or Registrant Organization field as a Material Change.

The IRT defined any change to the email as material because any change to the original email would generally render the email undeliverable.

Discussion:

• A lot of transfers also occur around expiration dates, so registrants are even more frustrated that they have to renew at the old registrar even though they wanted to transfer/renew at same time, and now they're locked for 60 days.

5. Should CoR be a standalone policy or continue to be part of the Transfer Policy? – 12 Responses

• CoR requirements should continue to be part of the Transfer Policy – 25%
• CoR should be a standalone policy – 42%
• This question should be considered only after other charter questions are addressed – 33%
• No answer/don’t know – 0%

Discussion:

• Pretty even split.
• Interesting to see how this evolves as we address the charter questions.

5. AOB

Next session: Tuesday 5 July at 16:00 UTC