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


  1. Welcome and Chair Updates
  2. CORD Availability discussion
  3. Preliminary Recommendations
  4. AOB

BACKGROUND DOCUMENTS



PARTICIPATION


Apologies: John Woodworth (ISPCP), Prudence Malinki (RrSG), Jothan Frakes (RrSG)

Alternates: Essie Musailov (RrSG)

Attendance

RECORDINGS


Audio Recording

Zoom Recording

GNSO transcripts are located on the GNSO Calendar

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


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.

  • No labels