Content Comparison

Notes/ Action Items

 Documents:  

1. Link to Public Comment Review Tool (PCRT):https://docs.google.com/spreadsheets/d/1lyX27uECA5bNKRw-UOIH2bAaTRvec1YkX1EKjtHCsAQ/edit?usp=sharing [docs.google.com]
2. Link to Rec Drafting Guide: https://docs.google.com/document/d/1YODFe-aZOi1AQ3c8f2-y8MXtcUU4PjzsByFzk-dpAD4/edit?usp=sharing [docs.google.com]

Action Items:  WG members to gather further input from their stakeholder group on Recommendation 18.

1.Welcome and Chair Updates

• Target to finalize initial comments by year-end, and to begin final report writing in January.
• Update on board liaison: Alan Barrett will join future meetings as a liaison to align the board with the working group’s progress on final report.

2.Continue Review of Draft Revisions to Recs 3-28

• • Recommendation 18

1. ICANN Org presented updates incorporating feedback to include a non-exhaustive list of reasons under “reasonable basis.”
2. Ken Herman highlighted limited feedback from his stakeholder group, noting preference for specificity (18.3) but agreeing to leave the current text as-is until further input.
3. Chair suggested retaining the itemized reasons and asked for WG members to bring this back to all their groups for further feedback on this.
4. Decision: Keep the language as proposed, pending further stakeholder group feedback.
• Recommendation 21
  1. ICANN Org introduced updates requiring registrars to provide specific rationale and evidence, upon request, for denying a transfer due to fraud or DNS abuse.
  2. Rich Brown emphasized operational burdens of providing detailed evidence upfront and suggested “registrars may provide specific rationale/evidence upon requests” in the text.
  3. Theo Geurts explained the importance of registrars’ evidence collection process, aligning with DNS abuse mitigation, and already starts  earlier in the process.
• Recommendation 22
  1. ICANN Org updated on additional language to Rec 22, where comments pointed out that mention of “lock” in this case can be confusing.
  2. Chair confirmed that proposed changes are fine and don’t change the substance of the recommendation.
• Recommendation 26
  1. ICANN Org presented comments to Rec where removing Section II.B. of the Transfer Policy was considered as too impactful.
  2. WG members pointed out that keeping the text seemed duplicative at the time.
  3. Members argued the content was redundant and not directly related to transfers but more to registration data policy.
  4. Zak Muscovitch suggested keeping the text related to updating registrant data.
  5. Discussion on keeping the word “confirmed” in 26.1. WG members discussed that it recommends removing the confirmation process and Designated Agent.
  6. Chair proposed removing the proposed language for 26.1.
• Recommendation 27
  1. ICANN Org presented the comment on clarifying the actions that a registrar would have to take if there was a potentially invalid or unauthorized change of registrant data.
  2. Chair and WG members pointed out that the above is part of a different policy and should not be covered by transfer policy.
  3. WG member inquired whether 27.8 is covered elsewhere, to which the Chair noted that CORD notifications are new. Therefore 27.8 will remain in place unless duplicative language is discovered.

• Recommendation 17
  1. Theo Geurts went back to his SG and inquired whether they can create a system where the registrant confirms the transfer within a reseller registrant portal, which would take an expansion of the API.
  2. Chair pointed out that some resellers might not want to implement an API/speed up system and obligations in the TPR do not oblige them to do so.

3.Begin Discussion of Recs 29-33

• • Recommendation 29
    1. ICANN Org presented comments received to remove any reference to calendar days to avoid potential inconsistencies.
    2. ICANN Org also presented comments referring to a potential double standard where registrants are not granted the same leeway as Rrs in terms of timeline.
    3. WG members argued that extending the current timeline 4 hours to 24 hours is actually more registrant friendly. UDRP and URS remain out of scope for this WG.
  • Recommendation 30
    1. ICANN Org presented comments that proposed the word “timely” in the Rec should be better defined.
    2. Chair explained that the current text gives enough flexibility, particularly since it discusses emergency situations.

4.Begin Discussion of Recs 34-46

5.AOB