The call for the Transfer Policy Review PDP Working Group will take place on Tuesday, 13 February 2024 at 16:00 UTC for 90 minutes.
For other places see: https://tinyurl.com/2ekrey4n
PROPOSED AGENDA
- Welcome and Chair Updates
- CORD Availability discussion
- Preliminary Recommendations
- AOB
BACKGROUND DOCUMENTS
PARTICIPATION
Apologies: John Woodworth (ISPCP), Prudence Malinki (RrSG), Jothan Frakes (RrSG)
Alternates: Essie Musailov (RrSG)
RECORDINGS
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:
- 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.