The call for the Transfer Policy Review PDP Working Group will take place on Tuesday, 15 October 2024 at 16:00 UTC for 90 minutes.
For other places see: https://tinyurl.com/jp8p5c3c
PROPOSED AGENDA
- Welcome and Chair Updates
- Review Assignment Schedule
- Discuss Recs 1, 2, 4-11
- AOB
BACKGROUND DOCUMENTS
PARTICIPATION
Apologies: Rick Wilhelm (RySG), Prudence Malinki (RrSG), Catherine Paletta (RrSG)
Alternates: Essie Musailov (RrSG)
RECORDINGS
Notes/ Action Items
Action Items:
- ICANN Org to update recommendations based on discussions and present revised drafts.
- WG Members to complete homework for Assignment 2 and review the updated draft recommendations. Assignment 2 - Recs #3, 12-23 (Group 1(a) - Restriction + denial of transfers).
Documents:
- Link to Public Comment Review Tool (PCRT):https://docs.google.com/spreadsheets/d/1lyX27uECA5bNKRw-UOIH2bAaTRvec1YkX1EKjtHCsAQ/edit?usp=sharing [docs.google.com]
- Link to Rec Drafting Guide: https://docs.google.com/document/d/1YODFe-aZOi1AQ3c8f2-y8MXtcUU4PjzsByFzk-dpAD4/edit?usp=sharing [docs.google.com]
1.Welcome and Chair Updates
- The Chair welcomed all attendees and provided brief updates.
- It was noted that the group is progressing well, with the finish line in sight. A few weeks of comment processing remain.
- The Chair mentioned that George Kirkos from Leap of Faith Services had submitted repeated comments on the push transfer model, which the group has previously addressed. These comments will not be revisited unless they relate to new aspects.
- The push model concept will be introduced to the Tech Ops group for further exploration as a potential future project.
2.Review Assignment Schedule
- ICANN Org reviewed the assignment schedule and addressed concerns that some members found the pace too ambitious.
- WG Members were asked to review the schedule with their respective groups to ensure its feasibility. Adjustments will be made if needed.
- ICANN Org informed the WG that the comments were divided into 5 groupings of subject matter. This session focused on the TAC related recommendations.
- Recommendation 3 is not included in this group, because the recommendations are in the order of how the transfer takes place and recommendation 3 deals with a transfer restriction placed on the domain.
- The current session aimed to cover recommendations 1, 2, and 4-11, focusing on the public comments related to these recommendations.
3.Discuss Recommendations 1, 2, 4-11
- Recommendation 1: Update terminology from “whois” to “registration data.” No objections or concerns were raised.
- Recommendation 2: Replace “administrative contact” with “transfer contact.” No objections or concerns.
- Recommendation 4: Update terminology from “auth info code” to “transfer authorization code (TAC).” Comments on push model discussed will be discussed at ICANN81 by the Tech Ops Group. No changes to the group’s decision.
- Recommendation 5: Definition of TAC. Comments noted the need for clarity on when TAC can be issued. A revision may be made to avoid misinterpretation regarding transfer restrictions. Options were proposed for clearer wording.
- Recommendation 6: TAC provision timing (5 days). Comments suggested precise timing in hours for clarity, and there was consensus to adjust the wording accordingly.
- Recommendation 7: TAC composition. A minor grammatical correction was made based on feedback.
- Recommendation 8: TAC verification. No objections; comments on the push model were noted but not acted upon.
- Recommendation 9: TAC time-to-live (TTL). Comments varied:
- Some stakeholders requested flexibility for registrars to null TACs without RNH approval in cases of security threats.
- Concerns were raised about the 14-day TTL being restrictive for some cases (e.g., aftermarket). The group decided to provide more context and maintain consistency in the language used.
- Recommendation 10: TAC generation, storage, and provision. No significant objections, only recurring comments on the push model.
- Recommendation 11: Notification of TAC issuance. Suggestions were made to ensure registrants and underlying customers (in proxy service cases) are notified. The group discussed the feasibility of aligning notifications with RFC 9154 encryption standards while balancing current industry practices.
4.Any Other Business (AOB)
- The next assignment was confirmed, with staff incorporating feedback and updating the construction recommendations. Assignment 2 - Recs #3, 12-23 (Group 1(a) - Restriction + denial of transfers).
- Members were encouraged to review and provide further comments before the next session.