The call for the Transfer Policy Review PDP Working Group will take place on Tuesday, 27 February 2024 at 16:00 UTC for 90 minutes.

For other places see: https://tinyurl.com/yvc2jvx2

PROPOSED AGENDA


  1. Welcome and Chair Updates
  2. ICANN79 TPR sessions Agenda
  3. CORD Prelim Recs & Rationale (& volunteers)
  4. Recap “Established Relationship” topic
  5. AOB

BACKGROUND DOCUMENTS



PARTICIPATION


Apologies: Jody Kolker (RrSG), Sarah Wyld (RrSG), Steinar Grøtterød (At-Large)

Alternates: Christopher Patterson (RrSG), Rich Brown (RrSG), Lutz Donnerhacke (At-Large)

Attendance

RECORDINGS


Audio Recording

Zoom Recording

GNSO transcripts are located on the GNSO Calendar

Notes/ Action Items


 Main discussion and action items

  1. Welcome and Chair Updates
  2. ICANN79 TPR sessions Agenda

Rec 1: Prudence

Rec 2: Theo

Rec 3: Owen

Rec 4: Sarah

  • Will rationale document be presented? Focus will be on recommendations document as rationale document is still work in progress.

      3.CORD Prelim Recs & Rationale (& volunteers)

    • Link to doc: https://docs.google.com/document/d/1DpDO2BYTl6TA7ApfPpG3Hpl13nrv4y4x9B3hImrx_Fc/edit?usp=sharing [docs.google.com].
    • Rec 1.3. change included revised language to clarify if P/P is involved.
    • Rec 2 the order has been updated based on previous call. Clarifies what to keep Section II from the transfer policy.
    • Current Section II needs it own policy.
    • Recs should be taken into consideration as a whole and not in isolation.
    • Rec 2.1 includes changes that clarifies that the “designated agent” is not used properly and new wording has been added. “Designated agent”should be eliminated from “future standalone Change of Registrant Data Policy”.
    • “Designated Agent” removed from transfer policy, but it could be used elsewhere if need be for other processes.
    • Rec 2.2 Eliminate Section II b “Availability of Change of Registrant” from future standalone policy. It not necessary to include here.
    • Rec 2.4 Eliminiate 60-day lock from future policy.
    • Perception could arise that this Rec 2.4 might take away security measured. Hence, more rationale could be needed in the rational document?
    • Members referred also to other options for registrants to increase security for their domains.
    • Rec 3 group is adding that Registrars have to provide instructions how registrants can take action if the change was invalid.
    • Rec 3.4 wording changed from MUST to MAY send CORD notification to new Email address.
    • Rec 4 Registrars must provide an opt out for Change of Registrant Data notifications.
    • Rec 4.1. Registrars MUST enable Change of Registrant Data notifications by default when a domain name is initially registered. Registrars MAY disable Change of Registrant Data notifications if the Registered Name Holder elects to opt out of these notifications.
    • Discussion on is this a security feature and is this hapering security or enhancing it? Opt out as part of data protection option?
    • Email verification process is in place and could pose an overlap with Rec 4.1? Verification Email only goes to updated Email not existing Email

      4.Recap “Established Relationship” topic

  • Refresher on NACK-ing recommendations (Prelim Rec 16 and Prelim Rec 17). How does this affect registration data?
  • Small group redlined Rec 17 where registrars MUST apply 30-day post change lock and included that they may unlock earlier if an established relationship exists.
  • Rationale will be further explained and presented during ICANN79 and group should be prepared to speak for or against it during ICANN79.
  • Does the group believe that an “Established Relationship” role/procedure should be created? If so, what exemptions should customers be provided with? How do these exemptions impact TPR?

    5.AOB

    • No comment
  • No labels