2024-06-25 Transfer Policy Review PDP WG Call
Dear TPR WG members, Please find below the brief notes and action items from yesterday’s meeting. The next meeting will take place on Tuesday 2 July 2024 at 16:00 UTC. Kind regards, Feodora on behalf of the TPR WG Support Team 2024-06-25 Transfer Policy Review PDP WG Call<https://community.icann.org/display/TPRPDP/2024-06-25+Transfer+Policy+Review...> AI: WG to take a look at mock up report and report back to ICANN Org in case they disagree with new format of initial report. AI: ICANN Org to remove word “partial” from Rec. 37. 1. Welcome and Chair Updates * The plan is is to spend the next month finalizing the full initial report for public comment. * The aim is to go through report by section. * During July there will be a lot of “homework” for the group to due the finalization of the initial report. 2. Review of draft updates following ICANN80 * ICANN Org presented the slides of the ICANN80 session<https://docs.google.com/presentation/d/1uFh08XvAW-Y5aEzFBwOsGYxuk6XWoATuGPaT...> to show some of the updates that were either proposed from working group members or some suggestions from support staff to address the concerns that were expressed during ICANN80, and see if the working group is amenable to those changes, or if further changes are needed on these specific recommendations. * In Rec 5.3. the 5th bullet had some worrisome text for the registrar stakeholder group, particularly the bit about how to initiate a reversal. Some working group members noted that a transfer may be invalid, but it might not be possible to reverse it for a number of reasons, so that text might be misleading. * The highlighted text highlighted in light blue is the text the WG went over during ICANN 80 and was proposed by Sarah. It was also sent to the working group in writing, and there were no objections to it. * The language now details how the Rnh can contact the losing or prior registrar for support if they believe the transfer was invalid, and any deadlines or policies which may be relevant. * The notification to transfer completion is sent by the the losing registrar or the prior registered. So it's the losing registrar that'll be sending this notice out. * In Rec 22 registrars noted an issue with one of the reasons that registers must deny a transfer. The group has an exception procedure in place, for when the 30 day restriction would not apply, and it's limited circumstances. ICANN Org added some language in the rationale: it says registers must restrict the registered name holder from transferring a domain name within 30 days after the completion of an interregister transfer, unless the conditions described in recommendation 19.1 through 19.4 are met. * During ICANN80 agreed that for Rec 19 the language of 19.1 should be moved up. The actual text of the recommendation did not change just the formatting. * In Rec 19 the word necessary is mentioned for the 30 day lock. There was some discomfort with the word necessary. So in in bracketed tech support staff suggested the word needed. The WG group porposed appropriate. * In Rec 23 the WG proposed to eliminate the 60 day inter register transfer lock. The proposed update is to remove this restriction with a note that the working group recommends removal of that transfer lock. * Recommendation 25 defines what a change of registrant data is. There was a note about 25.3, which clarifies that a change of registrant data does not apply to the addition or removal of a privacy proxy service provider and the concern was that 25.1 should somehow point back to this to avoid any sort of confusion. * So the definition of change of registrant data is the same. But it's subject to the language in 25.3, which clarifies a change to a name or certain contact. Details that are result from a change of a privacy, proxy, provider, or addition or removal would be a material change. * The impact rating for Rec 4 was discussed during iCANN80. So rec 4 will involve a new notification that registrars send to registered name holders when the TAC is issued. * Rec 5: the concern from registrars for this recommendation is the inconsistent referral to the losing registrar or registrar record. ICANN Org we removed the reference to the register of record and changed it to the losing registrar. * Rec 26: the WG expressed concerns that the change of registrant data policy should be separate from the transfer policy, as they're 2 distinct things. The main oncern was that the working group should make it clear that it's not recommending a new Pdp. The WG is recommending that the recommendations related to change of registrant data be housed within a different policy, and that the current change of registrant be removed entirely from the transfer policy. 3. Proposed updated format for Initial Report * Aim of this item is to provide an overview of the mock up of what the new initial report will look like.<https://docs.google.com/document/d/1R7uGVJyUMupxnIDM4MpHs5t_EJHMRKdZ7DHnBjAK...> * The final document will probably still look different. * 1st page includes a preamble to explain the new format of report. * The excecutive summary will be replaced with a prologue to set the stage for the reader and introduce the format of the report to them. * The initial report will also include the policy impact feature. * The main feature of the report will be to allow readers to bounce back from Rec text and charter questions via bookmark links. * The report will include an archive of the old numbering system and it's been realigned to complement the swim lane diagram. * The Annexes will have the charter questions and the summary deliberations down at the bottom. AI: WG to take a look at mock up report and report back to ICANN Org in case they disagree with new format of initial report. 1. Continued Presentation of High Impact Recommendations (beginning with Rec. 36) * Rec. 36 was restriction of fee adjustments. The working group recommends that if full portfolio transfer involves multiple registry operators, and one or more affected registry operators chooses to waive its portion of the collective fee. The remaining registry operators must not adjust their fees to a higher percentage due to the other registry operators waiver. * WG member pointed out that but not all full portfolio transfers involve fees and some rewording could be beneficial. * RySG suggested that the word “partial” should be removed from Rec 37. * Rec 37 is marked high impact because of the coordination effect of this. * Rec 38 is high impact because it's the the whole moving part of coordinating and and identifying the correct numbers to the correct people here. * Recommendation 40 is inclusion of bulk transfer after partial portfolio acquisition. AI: ICANN Org to remove word “partial” from Rec. 37. 1. AOB * Chair reminded WG we've got 5 weeks 5 meetings scheduled to complete our review of the initial report and our goal is to finish by the end of July. Feodora Hamza Policy Development Support Manager (GNSO) Internet Corporation for Assigned Names and Numbers (ICANN) Mobile: +32 496 30 24 15 Email: feodora.hamza@icann.org<mailto:feodora.hamza@icann.org> Website: www.icann.org<http://www.icann.org>
I am sorry but I won't be able to be in the call, I will be traveling all week. Best regards, Osvaldo ________________________________ From: Feodora Hamza via GNSO-TPR <gnso-tpr@icann.org> Sent: Wednesday, June 26, 2024 2:56 PM To: gnso-tpr@icann.org <gnso-tpr@icann.org> Subject: [GNSO-TPR] 2024-06-25 Transfer Policy Review PDP WG Call Dear TPR WG members, Please find below the brief notes and action items from yesterday’s meeting. The next meeting will take place on Tuesday 2 July 2024 at 16:00 UTC. Kind regards, Feodora on behalf of the TPR WG Support Team 2024-06-25 Transfer Policy Review PDP WG Call<https://community.icann.org/display/TPRPDP/2024-06-25+Transfer+Policy+Review...> AI: WG to take a look at mock up report and report back to ICANN Org in case they disagree with new format of initial report. AI: ICANN Org to remove word “partial” from Rec. 37. 1. Welcome and Chair Updates * The plan is is to spend the next month finalizing the full initial report for public comment. * The aim is to go through report by section. * During July there will be a lot of “homework” for the group to due the finalization of the initial report. 2. Review of draft updates following ICANN80 * ICANN Org presented the slides of the ICANN80 session<https://docs.google.com/presentation/d/1uFh08XvAW-Y5aEzFBwOsGYxuk6XWoATuGPaT...> to show some of the updates that were either proposed from working group members or some suggestions from support staff to address the concerns that were expressed during ICANN80, and see if the working group is amenable to those changes, or if further changes are needed on these specific recommendations. * In Rec 5.3. the 5th bullet had some worrisome text for the registrar stakeholder group, particularly the bit about how to initiate a reversal. Some working group members noted that a transfer may be invalid, but it might not be possible to reverse it for a number of reasons, so that text might be misleading. * The highlighted text highlighted in light blue is the text the WG went over during ICANN 80 and was proposed by Sarah. It was also sent to the working group in writing, and there were no objections to it. * The language now details how the Rnh can contact the losing or prior registrar for support if they believe the transfer was invalid, and any deadlines or policies which may be relevant. * The notification to transfer completion is sent by the the losing registrar or the prior registered. So it's the losing registrar that'll be sending this notice out. * In Rec 22 registrars noted an issue with one of the reasons that registers must deny a transfer. The group has an exception procedure in place, for when the 30 day restriction would not apply, and it's limited circumstances. ICANN Org added some language in the rationale: it says registers must restrict the registered name holder from transferring a domain name within 30 days after the completion of an interregister transfer, unless the conditions described in recommendation 19.1 through 19.4 are met. * During ICANN80 agreed that for Rec 19 the language of 19.1 should be moved up. The actual text of the recommendation did not change just the formatting. * In Rec 19 the word necessary is mentioned for the 30 day lock. There was some discomfort with the word necessary. So in in bracketed tech support staff suggested the word needed. The WG group porposed appropriate. * In Rec 23 the WG proposed to eliminate the 60 day inter register transfer lock. The proposed update is to remove this restriction with a note that the working group recommends removal of that transfer lock. * Recommendation 25 defines what a change of registrant data is. There was a note about 25.3, which clarifies that a change of registrant data does not apply to the addition or removal of a privacy proxy service provider and the concern was that 25.1 should somehow point back to this to avoid any sort of confusion. * So the definition of change of registrant data is the same. But it's subject to the language in 25.3, which clarifies a change to a name or certain contact. Details that are result from a change of a privacy, proxy, provider, or addition or removal would be a material change. * The impact rating for Rec 4 was discussed during iCANN80. So rec 4 will involve a new notification that registrars send to registered name holders when the TAC is issued. * Rec 5: the concern from registrars for this recommendation is the inconsistent referral to the losing registrar or registrar record. ICANN Org we removed the reference to the register of record and changed it to the losing registrar. * Rec 26: the WG expressed concerns that the change of registrant data policy should be separate from the transfer policy, as they're 2 distinct things. The main oncern was that the working group should make it clear that it's not recommending a new Pdp. The WG is recommending that the recommendations related to change of registrant data be housed within a different policy, and that the current change of registrant be removed entirely from the transfer policy. 3. Proposed updated format for Initial Report * Aim of this item is to provide an overview of the mock up of what the new initial report will look like.<https://docs.google.com/document/d/1R7uGVJyUMupxnIDM4MpHs5t_EJHMRKdZ7DHnBjAK...> * The final document will probably still look different. * 1st page includes a preamble to explain the new format of report. * The excecutive summary will be replaced with a prologue to set the stage for the reader and introduce the format of the report to them. * The initial report will also include the policy impact feature. * The main feature of the report will be to allow readers to bounce back from Rec text and charter questions via bookmark links. * The report will include an archive of the old numbering system and it's been realigned to complement the swim lane diagram. * The Annexes will have the charter questions and the summary deliberations down at the bottom. AI: WG to take a look at mock up report and report back to ICANN Org in case they disagree with new format of initial report. 1. Continued Presentation of High Impact Recommendations (beginning with Rec. 36) * Rec. 36 was restriction of fee adjustments. The working group recommends that if full portfolio transfer involves multiple registry operators, and one or more affected registry operators chooses to waive its portion of the collective fee. The remaining registry operators must not adjust their fees to a higher percentage due to the other registry operators waiver. * WG member pointed out that but not all full portfolio transfers involve fees and some rewording could be beneficial. * RySG suggested that the word “partial” should be removed from Rec 37. * Rec 37 is marked high impact because of the coordination effect of this. * Rec 38 is high impact because it's the the whole moving part of coordinating and and identifying the correct numbers to the correct people here. * Recommendation 40 is inclusion of bulk transfer after partial portfolio acquisition. AI: ICANN Org to remove word “partial” from Rec. 37. 1. AOB * Chair reminded WG we've got 5 weeks 5 meetings scheduled to complete our review of the initial report and our goal is to finish by the end of July. Feodora Hamza Policy Development Support Manager (GNSO) Internet Corporation for Assigned Names and Numbers (ICANN) Mobile: +32 496 30 24 15 Email: feodora.hamza@icann.org<mailto:feodora.hamza@icann.org> Website: www.icann.org<http://www.icann.org>
At the beginning of this TPR WG I raised the issue of preservation of DNSSEC status when a domain registration is transferred. There wasn't much interest, and this issue was generally treated as out of scope for this WG. Google Domains' sale of its registrations to Squarespace apparently resulted in *all* of the registrations becoming unsigned. The numbers are big enough to have resulted in a *drop* in the overall count of signed domain names, and hence a topic of conversation. I do not have further information. I expect it will be easy enough to talk to the relevant parties to find out more. That said, Google said to its customers: Will your domain stop working at any point? Your domain name registration and DNS delegation won’t be affected by the migration to Squarespace. After your domain has been migrated to Squarespace, you can manage additional services through their management console. https://support.google.com/domains/answer/13689670?hl=en&ref_topic=3314003&s... Steve sender
participants (3)
-
Feodora Hamza -
Osvaldo Novoa -
Steve Crocker