[GNSO-TPR] Notes and action items - TPR WG Working Session ICANN74 - 13 June 2022 at 08:30 UTC

[Julie Hedlund]

Dear TPR WG members,

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

The next meeting will be Tuesday, 28 June at 16:00 UTC.

Best regards,

Emily, Julie, Berry, and Caitlin


Action Items: None.

Notes:

Transfer Policy Review Phase 1(a) – ICANN74 Working Session
Proposed Agenda
13 June 2022

1. Welcome and opening remarks

  *   Initial Report will be released in the next couple of weeks.
  *   Now we turn to our next order of business, Phase 1(b) Work – Change of Registrant (COR)
2. High-level Overview of Phase 1(b) Work - Change of Registrant (COR)

See the slides at: https://community.icann.org/x/HhR1Cw

Overview of Transfer Policy:

What is the transfer policy: ICANN consensus policy governing the procedure and requirements for registrants to transfer their domain names from one registrar to another.

  *   Goal: Enhanced domain name portability
     *   greater consumer and business choice
     *   registrants may select the registrar that offers the best services and price for their needs

  *   Formerly called the Inter-Registrar Transfer Policy (IRTP)
  *   Went into effect on 12 November 2004
  *   GNSO reviewed the policy once before, shortly after implementation

Issue Areas for the PDP and Status – A 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

Topics in Phase 1(b):

Change of Registrant (CoR):

What is Change of Registrant?
Requirements that seek to prevent domain name hijacking by ensuring that certain changes to registrant information have been authorized.

What is required?
Registrars must obtain confirmation from the Prior Registrant and New Registrant before a material change is made to: Prior Registrant name, Prior Registrant organization, Prior Registrant email address, and/or Administrative Contact email address, if no Prior Registrant email address.

CoR Issue Areas:

What specific elements of the CoR Policy need review?

  *   “60-day inter-registrar transfer lock” prevents transfer to another registrar for sixty (60) days following a CoR. Registrants have difficulty with the 60-day lock, especially that they are not able to remove the lock once it is applied.
  *   Designated Agent: an individual or entity that the Prior Registrant or New Registrant authorizes to approve a CoR.
  *   Appear to be different interpretations of role and authority.
  *   Compliance enforcement is being deferred in relation to CoR as it applies to removal or addition of privacy/proxy services, pending further work to clarify implementation of relevant IRTP-C provisions.

CoR Lock: Transfer Policy Status Report Data

ICANN’s Global Support Center: Inquiries regarding transfers increased at a higher rate than inquiries overall, likely due to issues related to CoR lock.
ICANN Aggregate Transfer-Related Monthly Registry Reporting: Large spike in transfers in 2016 just before implementation of IRTP-C, including CoR lock.
Metrics from ICANN’s Contractual Compliance Department: Complaints about inter-registrar transfers have been decreasing, complaints related to CoR lock increased.
Survey of Registrars and Registrants: Registrants are confused and frustrated when the CoR lock prevents them from completing a transfer. Some want to eliminate or change it.

CoR: Focus of Charter Questions


  *   Does the policy achieve its stated goals? Is it still relevant in the current domain ownership system?
  *   Can requirements be simplified to make them less burdensome and confusing, especially regarding the 60-day lock?
  *   To what extent should there be a process or options to remove the 60-day lock?
  *   To what extent should the Change of Registrant policy, and the 60-day lock, apply to underlying registrant data when the registrant uses a privacy/proxy service?
  *   Is the Designated Agent function operating as intended? If not, should it be retained and modified? Eliminated?

Working Document for Charter Questions d1, d2, and d3: https://docs.google.com/document/d/1gu4sXGvyJeWJIfvaK_I7GKA6lAdfKFPQKaN4UMgzmcE/edit#:

Relevant Metrics from the Transfer Policy Status Report (summarized in the Final Issue Report):

  *   In the period from 1 January 2015 - 23 May 2018, the number of Global Support Center inquiries received regarding transfers increased at a higher rate than the overall amount of inquiries received (which also increased). GSC posited that the increase in transfer-related inquiries is likely due to an increase in issues related to the Change of Registrant (COR) lock.
  *   According to aggregate data on ICANN Monthly Registry Reports, there was a prominent spike in transfers toward the end of 2016. The Transfer Policy Status Report speculates that this spike may be explained by the then forthcoming implementation of the IRTP Part C, including the 60-day lock (see page 18).
  *   The Transfer Policy Status Report notes with respect to tickets received by ICANN’s Contractual Compliance Department between 2012 and 2018, “The nature of transfer complaints changed in December 2016, when the IRTP-C and -D became effective. While inter-registrar transfer complaints have been trending downward, Contractual Compliance noticed an increase in complaints relating to the “Change of Registrant” (COR) lock that became effective in December 2016.”

In addition, ​​the Transfer Policy Status Report summarizes survey input with respect to Change of Registrant:

  *   Respondents wanted to see fewer and/or less complicated steps for registrants to transfer their domain(s), and quicker transfer times.
  *   Respondents express frustration when they encounter barriers to transferring their domain name(s) (e.g. the “Change of Registrant” lock).
  *   Some respondents recommended eliminating or reducing the 60-day Change of Registrant transfer lock imposed on registrants who’ve changed their contact information.
  *   Some registrar respondents indicated that their customers were often frustrated with certain aspects of the Policy, and did not seem to understand the underlying rationale for certain requirements (such as the Change of Registrant lock).

3. Discussion of Charter Questions<https://community.icann.org/display/TPRPDP/2.+WG+Charter?preview=/161808892/183993306/Charter%20-%20PDP%20to%20Review%20the%20Transfer%20Policy%20v.%201.2.pdf> d1, d2, and d3

Overview:

  *   First charter question is the most important – is the policy doing what it set out to do; does it need to do those things?
  *   Once we address that question the other charter questions get easier.
Charter Questions d1, d2, and d3:

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:

  *   Very different now than when the policy was created.
  *   Security is much more of the emphasis now.
  *   In 2015 there were no statistics and we still don’t have statistics.
  *   Security technology will continue to evolve and the security situation has changed significantly since 2015; now we have GDPR, which takes away email as an attack vector.
  *   Why doesn't the policy achieve the stated goal? I think the goal is changing the registrant, which is a valid goal?
  *   Goals are to curtail hijacking and facilitate Change of Registrant.  May not be meeting those goals today – hiding email may even facilitate hijacking.
  *   We could change the Registrant without going through this double approval process.  So maybe the goal was to prevent domain theft, and maybe we've seen that that's not necessary?
  *   The original goal was to make domain names more secure, but have we done too little to protect domain names and are we requiring too much.
  *   So can registrants transfer ownership and registrar at the same time now?  With the 60 day lock, not really. The policy states that registrars must notify registrants that if they are changing data for a transfer, then they should do so after to avoid the COR lock.
  *   Maybe the split in two independent processes "inter-Registrar-Transfer" and "Change-of-Registrar" cause a lot of the headache, because both processes had their own checks and locks, but are initiated concurrently. So the processes interfere and block each other. It's not a solution to weakening each of the processes separately.
  *   Have statistics changed after the implementation of the Temp Spec; do we have statistics?  There are some stats in the Issues Report, but that is a good question to ask.
  *   I think most of these are less statistics and more anecdotal references we all experience from registrant complaints.
  *   Useful to look at the current Change of Registrant policy: https://www.icann.org/resources/pages/transfer-policy-2016-06-01-en.  Get concrete about what we might be proposing.
  *   think ICANN data did not really show a decrease or increase of unauthorized transfers after Temp Spec (at least that is my recollection when we did the scoping for this PDP).
  *   I “feel" that we are now seeing less reports of hijacked domains than we did in the past, but that may also be due to our tendency to return such domains
  *   It's a complex process! If someone is unsure and wants to learn more, we put out this help info when the policy was first live, might help parse things: https://opensrs.com/change-of-registrant-re-enablement/.
  *   Would like to see us have the goal that the domain owner knows what is happening with their domain name and making it easier for the update to happen and making it easier to undo it.
  *   Maybe the policy needs to stick around but be changed.
  *   We thought a lot about security issues in Phase 1(a), so we don’t want to lose that emphasis in Phase 1(b).
  *   As a baseline we could start with all the same security principles we established in Phase 1(a).  In the intra-registrar case don’t see that the Transfer Policy can address hijacking.
  *   Quick reversal is one part of the puzzle, but that only protects the registrant.  It is only relevant if we have failed to prevent hijacking/theft.   If we go in the direction of security we have to remember that this doesn’t protect all registrants.
  *   Just a thought: generally speaking, in order to follow up the efficiency of new policies, it could make sense to see via statistical data the evolution before and after a new policy that addresses a problem like this PDP.
  *   We must not forget the reseller business model and tune the CoR policy for this too.
  *   I think the use of TAC in COR is an important consideration, important enough that you should start with that baseline (i.e., align with inter-registrar transfer) and think about why you shouldn't do it as opposed to why you should do it.
  *   There is no quick undo.  Let’s not base policy on this.
  *   Have been some reversals among registrars working together.
  *   I think a core difference in the case of intra-registrar hijacking, remedy is less complicated than in the event of inter-registrar.    because the domain remains within the registrar, the registrar's control, ability and means to restore the domain name to the victim is much stronger.
  *   Remedy may be easier but I wouldn't use that as a reason to do things differently than the way things are done for inter-registrar transfer.
  *   As we move forward we might want to talk to the ICANN Rights and Responsibilities staff as to how this is working for registrant.
  *   Statistics would be very helpful.
  *   You could decide they are not different and thus COR should use a TAC and should involve a registry.  On the other hand, maybe there is a distinction you want to make, and thus you use a TAC-like model, i.e., a COR TAC that is only and fully managed by the registrar.
  *   Like the suggestion of going through all the security features for the Inter-registrar transfer -- and considering which can apply here also.
  *   We should take into account that most transfers occur without incident.
  *   Group seems to be deciding that the CoR policy should stay but should be changed.
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?

  *   The policy is complex and hard to understand.
  *   Could be interpreted in different ways – particularly re: details not listed in the policy.
  *   Consistency in the implementation of CoR is something that would be beneficial.   Registrar A may implement the opt-out of the 60 day lock, Registrar B may not.
  *   I don't think the “security theater" is any worse than it is in the inter-registrar case.  if any change to registration data is a "transfer", then use the transfer process.
  *   One fundamental consistency we should probably adopt is to make this a 30-day lock, as with the inter-registrar locks.
  *   On the other hand, if the actual physical owner is not changing but the "name" or "address" is changing, then don't use a transfer process.  the question is can you identify those cases so you can make that simpler.
  *   One model is to take on board everything we did in Phase 1(a), but then ask a number of questions – such as do you want to involve a registry? Or do you keep it local?  I CoR a physical transfer, or not an ownership change in a physical sense?  If the physical owner is going to change then you’d want to use a TAC-like system.
  *   You could decide they are not different and thus COR should use a TAC and should involve a registry.  On the other hand, maybe there is a distinction you want to make, and thus you use a TAC-like model, i.e., a COR TAC that is only and fully managed by the registrar.
  *   Could make a list of security features from Phase 1(a) and see what fits and what doesn’t.  Maybe also think about what updates are a material change or would trigger this process?
  *   The distinction I'm making is whether material change to registration information is any way correlated to the physical entity that owns it.
  *   As well as looking at CoR policy we need to look and see if the transfer policy actually can address change of registrants and if there are other issues other than security.
  *   Re: material change, think about what is the anchor.  Could be the email address.  It could mean that nothing else is material.  So the only thing that constitutes a transfer is moving between registrars.
  *   On the other hand, if the actual physical owner is not changing but the "name" or "address" is changing, then don't use a transfer process.  the question is can you identify those cases so you can make that simpler.
  *   For COR,  policy considers these are the contact data points that are impacted and considered material changes -
     *   Prior Registrant name
     *   Prior Registrant organization
     *   Prior Registrant email address
     *   Administrative Contact email address, if there is no Prior Registrant email address.
  *   Anchor could be whatever you are using for contactability.
  *   To Maxim's point, I like the idea of having that as an exception for the Rr to use in case of dispute, but I'm not sure it can be the standard.
  *   Where can we put in flexibility?
  *   What’s the definition of ownership?
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.

Discussion:

  *   Should the policy be split?
  *   Like splitting but they are interrelated.
  *   First bullet seems to describe the current process, while the last bullet point seems to be referencing thick TLDs.
  *   Could table this for later or skip this question.
  *   Making them separate policies would be the easier thing to do.
  *   Think we're moving away from the thick/thin terms anyways, right?
  *   If you take a look just below the charter question in the working document, there is a further clarification of why the charter question refers to "thin".
  *   Look at what are the elements that are distinctive to document about this policy – if there aren’t any then do we need it?  Or maybe defining “material change” will tell when you need to use an inter-registrar transfer process or not.
  *   Seems that a Change of Registrant should be easier than a Change of Registrar.
  *   Gaining Registrar doesn’t have a reliable source of data right now with GDPR.  We have to rely on the transfer process being secure.
4. AOB
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mm.icann.org/pipermail/gnso-tpr/attachments/20220613/4c1c0af9/attachment-0001.html>