2024-02-13 Transfer Policy Review PDP WG Call

Notes/ Action Items

 ACTION ITEMS/HOMEWORK: WG to complete the COR Reduction Rationale document at:https://docs.google.com/document/d/1DpDO2BYTl6TA7ApfPpG3Hpl13nrv4y4x9B3hImrx_Fc/edit?usp=sharing [docs.google.com]

Notes:

1. Welcome and Chair Updates

• Three sessions with this one before ICANN79.
• Two sessions scheduled for ICANN79 – COR and impacts. See TPR agendas at: agenda:(https://community.icann.org/display/TPRPDP/2024-03-02+ICANN79+Transfer+Policy+Review+PDP+WG+Call+Session+1). It is currently a rolling agenda for both sessions, part 1 being discussion of the draft COR recommendations, and part 2 being discussion of the Group 1(a) 30-day transfer restriction (and whether the existing recs need to be updated in light of the CORD recs).
• ALAC will be meeting at ICANN79 to discuss COR on Saturday, 02 March; open to the public.  Follows the TPR sessions.
• Still no rationale in the document at: COR Reduction Rationale document at:https://docs.google.com/document/d/1DpDO2BYTl6TA7ApfPpG3Hpl13nrv4y4x9B3hImrx_Fc/edit?usp=sharing [docs.google.com]
• WG Self-Assessment Survey is still open – 9 responses so far.  Closes 21 February.

2. CORD Availability discussion – See attached slides, starting at slide 3.

Discussion:

• Numbers 2 and 3 can go away completely.  No longer relevant.
• 2.3 is probably duplicate policy language.
• Don’t know what harm there is in allowing someone to update their data – would be less harmful to allow (2.1).
• If there is a domain name for which you could update the registrant data would think there would be a contract between the registrar and registrant.
• Unless there is disagreement it seems we could simplify the policy by eliminating 2 and 3.
• Does 2.2 still make sense if authorization is not required?  We now have a notification-only policy so you don’t need it.

3. Preliminary Recommendations – See attached slides.

Discussion Prelim Recs 1.1 and 1.2, slide 5:

• This is impossible to code for – hard to define a typo or not.
• Original language assumed some manual processes.
• Think about how this would work in the real world.  No notion of typo.
• Nothing to prevent a registrar from treating any change as material.

Discussion Prelim Rec 1.3, slide 6:

• Make sure we are talking about the underlying customer data.
• Question: Why do we care about this and how does it tie into change of registrant data? Answer: To clarify in response to charter questions.
• If a registrant applies a privacy proxy service, that’s not a material change.
• But there is underlying customer data and if that changes there is a notification. Changing the name would trigger notification because it’s out there.
• We're getting into a discussion that no longer has anything to do with a change of registrant data in combination with the privacy proxy service.
• We had a couple of charter questions on privacy proxy that needed to be addressed.
• Do we eliminate it?
• It may have been important when we wrote the charter but we can say it’s no longer applicable.

Discussion Prelim Rec 2, slide 7:

• It’s redundant language.

Discussion Prelim Rec 3, slide 8:

• Question: Should we change “registrant data” to “registration data”?
• Why would we change anything? This section is no longer relevant. There is no confirmation process anymore. There's only notification. Just remove it.

Discussion Prelim Rec 4.1, slide 9:

• No comments.

Discussion Prelim Rec 4.2, slide 10:

• Question: Send to the previous or only the new RNH? Answer: We discussed getting rid of the prior and sticking with just RNH.  I don’t think we decided that you couldn’t send to both of them if you chose to.
• Since this is framed as a change of data the only time it would make sense to notify both is if email changes, which is addressed in 4.4.

Discussion Prelim Rec 4.3, slide 11:

• No comments.

Discussion Prelim Rec 4.4, slide 12:

• Question: What are we trying to achieve? Answer: When you are changing the email address the registrar is required by contract to verify that email address -- the new one. So there is work that goes into that. So it's not like it's just changed. Getting a positive notification that email is updated.
• Don’t see any good reasons from a policy perspective.
• From a registrant perspective see the benefit but if already done by WHOIS verification then that is the complete solution.
• Could think about turning the MUST into a MAY?
• Notifications might typically go to the account control panel.

Discussion Prelim Rec 4.5, slide 13:

• No comments.

Discussion Prelim Rec 4.6, slide 14:

• No comments.

Discussion Prelim Rec 4.7, slide 15:

• Wonder if we need to be that specific.

Discussion Prelim Rec 5.1, slide 16:

• Concerns with this: when it comes to a new RNH that is out of the registrar’s control if there is a new agreement.
• Question: Maybe we could incorporate more about the decision to be informed and when can an opt out be reversed.  Answer: See slide 17.
• Question: When a domain name changes hands is there anything that needs to be done about the opt out continuing?  Answer: Talked about whether to opt out every time you make a change.
• It can be a permanent flag not an every time flag.
• Change MUST to MAY?  We kept MUST for consistency across registrars.

Discussion Prelim Rec 5.2, slide 17:

• Question: If a registrant makes a CORD and prior to that opts out there still would be a verification email – any concern about fraud in opting out?
• Continue discussion at the next meeting.

4. AOB: None.