October 2023 - GNSO-TPR - lists.icann.org

For your review: TPR recap recording + documents
by Caitlin Tubergen Nov. 2, 2023

Nov. 2, 2023

Dear TPR WG members, It was great to see many of you in Hamburg. As discussed during our session, Support Staff has been working with Leadership to prepare some materials to refresh the group on the preliminary agreements we have made over the last 980 days since the Council initiated this PDP. (For those of you who did not attend the ICANN78 session, Berry informed us that we are about to close in on 1000 days of work.) Since it’s been a while (and thank you to everyone for sticking with this work!), we thought it would be helpful to have a brief refresher before we pivot back to our charter questions on Change of Registrant (Group 1(b)). Our Tuesday, 7 November 2023 meeting will be dedicated to this refresher exercise. To prepare for the call, please review the following materials in advance: * the recording from the 17 January WG meeting<https://icann.zoom.us/rec/play/M9Q6l-3ucT4SL0OiDJ0zQc9EmlMzB84MywmdUKDQqgAq…>, where Berry presented the swim lane diagram * an updated swim lane diagram, which shows how the recommendations interrelate (attached) * a slide deck, which provides an overview of the recommendations the group has agreed on to date (attached) We recommend listening to the Zoom recording<https://icann.zoom.us/rec/play/M9Q6l-3ucT4SL0OiDJ0zQc9EmlMzB84MywmdUKDQqgAq…> first before reviewing the updated swim lane and the slide deck as these will make more sense after a refresher from the recording. Thank you. Best regards, Christian, Julie, Berry, and Caitlin

4 3

Slides re: Notes and action items: TPR WG at ICANN78 on 21 Oct at 08:30 UTC/10:30 local time
by Julie Hedlund Oct. 24, 2023

Oct. 24, 2023

Dear TPR WG members, Here also are the slides that were presented during the meeting. Kind regards, Julie From: GNSO-TPR <gnso-tpr-bounces(a)icann.org> on behalf of Julie Hedlund <julie.hedlund(a)icann.org> Date: Saturday, October 21, 2023 at 8:47 AM To: "gnso-tpr(a)icann.org" <gnso-tpr(a)icann.org> Subject: [GNSO-TPR] Notes and action items: TPR WG at ICANN78 on 21 Oct at 08:30 UTC/10:30 local time Dear TPR WG members, Please find below the brief notes and action items from today’s meeting. The next meeting will be in two weeks on Tuesday, 07 November at 1600 UTC. Kind regards, Christian, Caitlin, Berry and Julie ACTION ITEMS/HOMEWORK: Please review these recap materials in advance of our next call, so if there are questions or concerns you can bring them up during the call. Recap materials will be distributed, covering the recommendations from WG Group 2, 1(a), and 1(b). The next call is on November 7. We also strongly encourage you to listen to the 17 January Zoom call [icann.zoom.us]<https://urldefense.com/v3/__https:/icann.zoom.us/rec/play/M9Q6l-3ucT4SL0OiD…> before going into recommendation text and swimlane. Transfer Policy Review - Meeting at ICANN78 Proposed Agenda 21 October 2023 1. Welcome and Chair updates 1. Recommendations from ICANN-approved transfer (bulk transfers) are now in a stable condition. Been our focus since ICANN78. 2. We will be briefly revisiting some open questions from other Group 2 topics before transitioning back to a recap of what the WG has agreed to date, and then moving to Group 1(b), which is Change of Registrant (Part II of the Transfer Policy) in November. 3. Working Group Member updates or Stakeholder updates – none. 4. Project Status (Berry, Staff) * 5 weeks behind schedule wrapping up Group 2. * We will do a recap of all groups before moving on. * Total of 110 sessions (began Feb 2021), close to 1000 day duration, 165 hours of discussion time. * Want to try to expedite moving through CoR, preferably go to Public Comment before June ICANN Meeting 2024, have Final Recommendation Report in May. 2. Transfer Dispute Resolution Policy (“TDRP”) – Registrant Access 1. Reminder of current draft recommendation * Relevant charter question: g3) If the TDRP is considered to be insufficient: i. Are additional mechanisms needed to supplement the TDRP? ii. Should the approach to the TDRP itself be reconsidered? * Current Draft Preliminary Recommendation: The Working Group recommends the GNSO request an Issues Report or other suitable mechanism to further research and explore the pros and cons of (i) expanding the TDRP to registrant filers and (ii) creating a new standalone dispute resolution mechanism for registrants who wish to challenge improper transfers, including compromised and stolen domain names. In making this recommendation, the Working Group recognizes that if such an effort were ultimately adopted by the GNSO Council, this request could be resource-intensive and will require the Council to consider the appropriate timing and priority against other policy efforts. 1. ALAC message re: registrant access to TDRP<https://mm.icann.org/pipermail/gnso-tpr/2023-July/000945.html>: * View of the ALAC is that registrant should be given the opportunity to initiate TDRP, this should be included in the WG recommendations. This would not be for registrants to combat domain theft. It would still be under the conditions and requirements of the TDRP. The only option for registrants currently is to go to court. * The option of bringing legal option isn’t sufficient and is costly. * If no agreement in the WG ALAC will file a comment. * It is the responsibility of the Registrar to educate, guide, explain to the registrant. * Options in light of ALAC feedback and previous discussion. When we introduced the topic earlier, we noted this was discussed/scoped by IRTP-D WG, they decided not to overload the TDRP. Potential options: * Require registrar-provided rationale in the event registrar refuses to file TDRP. * Registrant responsibility for TDRP fee. * Open TDRP to registrant filers (where registrant is responsible for payment of fee, irrespective of outcome – similar to UDRP). * Note: Need to ensure this is separate from other similar actions/processes. * In this case, also similar to UDRP, the registrars would be responsible for registrar verification of data. * Leave recommendation as is. * Other Options? Discussion: * There are other policies that this may impact, e.g. ERRP. It is important to untangle that. * Strongly think there needs to be a process, but need to investigate who the parties would be and what it would be – not the TDRP. * Registries don’t think TDRP is the right mechanism – it is a very targeted process. From a registry perspective, concern that if TDRP is cracked open that it would not get worse. If rewritten, concern it would be expanded. Perhaps if there was another mechanism/tool. * Should do something but should be separate/standalone and not UDRP. * Registrars don’t initiate a TDRP but do so when registrant alerts them – should they provide a rationale if they don’t initiate. * Before we go too far down the request for an Issue Report, need to consider other transfer issues – such as inter-registrant transfer – might want to wait until the WG discusses all related issues. * From group 1a and 1b discussions, post-transfer restriction or policy issues out of Change of Registrant. The third option is on the table with current issue report recommendation, but the first two may be wanting more thoughts on this for an interim solution. It may be 3+ years until such a policy is enacted. * Registrant could be confused by what it an inter-registrar transfer. * Sounds like there is support for expanding (to bullet a.) If ALAC can provide comments during Public Comment that would be helpful This group is not scoped to do this – is there something we can do as an interim solution – get feedback on these options:: * Require registrar-provided rationale in the event registrar refuses to file TDRP * Allow the registrant to be responsible for any fee required by the TDRP provider * If the fee is set the registrant has the option to decide and can be well informed; still need to determine who would be the parties to the dispute. E.g. would it be filed against the Gaining Registrar, Losing Registrar, or gaining registrant? Whether that is TDRP or another vehicle. Thoughts on the first two options in the interim? * Don't believe ALAC has discussed fees on this, but if the registrant is informed of the fees they can weigh the pros and cons. The fee should be transferred and well-informed. * If we make a policy change that the registrant can pay the fee, my concern is the Registrar already knows that it will fail because the policy was followed. * The one filing would be the customer/client of the former Registrar. Their ability to do anything is already diminished because they don’t have access. * Maybe have a mechanism that is tied to getting domain back that is broader than just a failure of following the Transfer Policy. Registrants likely won't know the transfer policy well enough to know whether it was followed. We don't want registrants losing all the time. * Always a bunch of lawyers involved. I doubt a registrant will pay without any legal backup. If the process is opaque maybe, but the registrant should advise legal counsel before filing TDRP. * Leave the UDRP to trademark stuff. * What about the first bullet? Registrars don’t typically initiate the TDRP on their own, the registrant contacts them and tells them something is wrong. Should we require a letter/rationale why they won’t pursue the TDRP. Maybe this is a course of action? * Don’t think it's necessary. The panel should provide that data. If there is lack of support from the registrar, I don’t think the registrar will be willing to provide this data. * Think the current recommendation may eventually create a panel. Option 1 or 2 is something to do in the interim. Can we/should we add language to require Registrar to provide rationale in the interim? * Two situations: when the person filing is mad their domain moved between registrars, or mad because they lost their domain. The TDRP is about: did you violate the policy? We need to consider the broader scope, there will be more discussions about this when we talk about inter-registrant policy. Maybe before we start spinning work on this, we consider waiting until we discuss CoR. * If this is just an intra-registrar issue, that is something to think about. * Introducing a new policy will likely delay our work and would be out of scope. ICANN Compliance already has a role, maybe we expand current language that would open a route for registrants to go through ICANN Compliance, enabling them to get more information they can use. * If we are not careful, we will get into circular dependencies. Looking at Change of Registrant, when we did the high-level overview, the group had momentum about tearing down what is a Material Change for CoR. These were directly connected to what Rick was talking about re: disputes of CoR not change of Registrar. Maybe making a new mechanism could be a way forward in the meantime. * Change of Registrant may also be tangled with EDDP/ERRP. Need to be aware how a registrant could be confused about filing. 3. TDRP updates in light of EPDP – Temp Spec – Phases 1, Recommendation 27 1. Refresher of EPDP Team Recommendation #27. “The EPDP Team recommends that as part of the implementation of these policy recommendations, updates are made to the following existing policies / procedures, and any others that may have been omitted, to ensure consistency with these policy recommendations as, for example, a number of these refer to administrative and/or technical contact which will no longer be required data elements: * Registry Registration Data Directory Services Consistent Labeling and Display Policy * Thick WHOIS Transition Policy for .COM, .NET, .JOBS * Rules for Uniform Domain Name Dispute Resolution Policy * WHOIS Data Reminder Policy * Transfer Policy * Uniform Rapid Suspension System (URS) Rules * Transfer Dispute Resolution Policy 1. Proposed updates to TDRP in light of Rec. 27 – see: https://docs.google.com/document/d/12ncsCc_sYiBs2cRZVOPCrBes92aV0p-6S-7hNBk… [docs.google.com]<https://urldefense.com/v3/__https:/docs.google.com/document/d/12ncsCc_sYiBs…> Relevant Excerpt from ICANN Impact Paper: “TDRP section 3.2.4 provides that a panel appointed by a TDRP provider will “review all applicable documentation and compare registrant/contact data with that contained within the authoritative Whois database and reach a conclusion not later than thirty (30) days after receipt of Response.” This provision relies on comparison with the "authoritative Whois database," which does not have a clear analogue in the new Registration Data Policy.” * ICANN Impact Paper notes: o Data could be requested by the panel (similar to UDRP), though that may result in duplicative data; OR o Requirements could be written at a higher level o In the current draft [docs.google.com]<https://urldefense.com/v3/__https:/docs.google.com/document/d/12ncsCc_sYiBs…>, both are included – thoughts? o Further discussion Discussion: * TDRP / Rec 27. ICANN org delivered an impact policy that discussed what may need to be changed from EPDP Phase 1 recommendations. There is no clear analogue for “authoritative Whois database” in TDRP. Two potential options: (1) Data could be requested by the panel (like UDRP) but this may produce duplicative data; (2) Requirements could be written at a higher level. Both options were included in the current draft [docs.google.com]<https://urldefense.com/v3/__https:/docs.google.com/document/d/12ncsCc_sYiBs…>, but received no WG comments, so we wanted to make sure the WG is happy with the current recommendations. * Sending the gaining FOA in no longer a requirement, so changes have been reflected * Panel determines whether a violation of policy occurred based on the information provided. * We will send a link with this to make sure everyone is okay with this. * Any comments on these? * Where does this data come from? Want to raise this as a potential challenge. * There are evidentiary requirements the Registrar would be following, that is worth looking at. 4. If time allows, presentation of Group 2 – ICANN-approved transfers recommendations and any feedback received Shortly after this meeting, the WG will receive a recap of where we are now. Support staff tried to highlight all the changes and draft recommendations thus far. We will distribute this recap document as well as updated swimlane. Since we have some time now, we will cover the recommendations from Group 2 (TEAC, TDRP, ICANN-approved Transfers). TEAC Recommendations: * TEAC Prelim Rec 1: The WG recommends updating the required timeframe for initial response from 4 hours to 24 hours / 1 calendar day. * TEAC Prelim Rec 2: The WG recommends that the initial communication to a TEAC is expected to occur no more than 30 days following the alleged unauthorized loss of a domain. * TEAC Prelim Rec 3: The WG recommends that substantive updates by email to the Losing Registrar occur at least every 3 calendar days until work to resolve the issue is complete. * TEAC Prelim Rec 4: Refers to the format of communication, and adding text around notification requirement that the initial email to the TEAC starts the clock. * TEAC should there be a fast undo, clawback recommendation. A small team drafted a process, but the majority of the group seemed to think informal resolution works today. Adding to the Transfer Policy may add complications and so this mechanism was not added to the policy TDRP Recommendations: * TDRP Prelim Rec 1: The WG discussed opening TDRP to registrants, and recommended GNSO request an issue report to further look at these issues. * TDRP, Rec 27 - Prelim Rec 3 : textual changes to account for updated language in new policy ICANN-Approved Transfers Recommendations * Explanation of icons. Farm: a registrar is transferring all of its gTLDs to another registrar; Herd: only transferring a particular TLD; Single cow: partial portfolio transfers * Prelim Rec 1: The RO MAY charge a fee, and MAY waive the fee * It would be good to do some editorial work around the context of these recommendations. On the screen it says “Full domain name portfolio transfers”. Would be good to specify an “ICANN-approved full domain name portfolio transfer”. Once we publish these recommendations it should be very clear this is not BTAPPA. * Prelim Rec 2: Makes clear the number of names and price ceiling are staying the same, status quo. The ecosystem has changes since the policy was initially drafted, now there maybe many registries involved in a bulk transfer, look at recs 3-6 for allocation recommendations. * Prelim Rec 3: Due to the variable nature of the fee associated with full portfolio transfers, the WG recommends that ROs MUST provide notice to registrars of any fees associated with full portfolio transfers upon request. * Due to Rec 2, we changed how this mechanism works. Now there is a hard cap on fees to Gaining Registrar. No fee schedule, it is fixed to cap $50,000. Given the way discussions have unfolded, I would suggest dropping Rec 3 as it may be burdensome/silly. There is no more schedule. If Rec 2 changes and the fee schedule becomes variable again then we can bring it back. * It says “variable nature of the fee”, but I guess the fee isn't variable now? * You’re right the variable nature has disappeared, I think that is a good call to drop it. Do others disagree? * Then Rec 4 may not be actionable. * Rec 4 I think still applies and can be used * Registries are still good with Rec 4. * Prelim Rec 4: this notes that if a Registry decides to waive their fee, the others cannot charge more to bring the fee up to $50,000 * Prelim Rec 5: ROs would need to provide notice to ICANN with the number of domains transferred * Prelim Rec 6: ICANN would send a notice to the ROs with reported numbers and corresponding percentages of domain names involved in the bulk transfer. * “According to registrar’s fee schedule” is this language still appropriate? * Prelim Rec 7: the Gaining Registrar MUST be responsible for paying the relevant Registry’s fee (if any). BTAPPA/Change of Sponsorship Recommendations * Prelim Rec 1: Opening BTAPPA to include circumstances where a reseller/service provider wants to transfer its portfolio of domain names to a new Gaining Registrar * Prelim Rec 2: WG recommendation to notify affected registrants approximately 1 month before the change of sponsorship is expected to occur. * “by X date if desired” should that be before the transfer occurs? Let’s try to fill that in. * To clarify ICANN does not approved BTAPPA, it is a service provided by the registry * Prelim Rec 3: update to boilerplate BTAPPA language, confirming status quo that * Prelim Rec 4: RO must reject a change if there is evidence * The WG has been talking about the macro changes, but we have recommendations on micro language. We haven't come to an agreement whether BTAPPA is going to be required or not. * Either these recommendations go into BTAPPA boilerplate or they go into Transfer Policy. Where they will go is our only open question in bulk transfers, but the recs themselves still apply either way. So these are building block recommendations, like pre-preliminary recommendations? * No matter where they go, these are our recommendations. The group agreed to these, but not yet to where they go * Prelim Rec 5: Relevant agreements need to permit this type of transfer if using BTAPPA service * Prelim Rec 6: RO MAY charge a fee for a change of sponsorship, but ROs MUST provide notice to Registrars of any fees associated with a change of sponsorship * Prelim Rec 7: Notes that the gaining registrar must not impose a new inter-registrar transfer lock as this was not initiated by registrants ACTION ITEM: Please review these recap materials in advance of our next call, so if there are questions or concerns you can bring them up during the call. Recap materials will be distributed, covering the recommendations from WG Group 2, 1(a), and 1(b). The next call is on November 7. We also strongly encourage you to listen to the 17 January Zoom call [icann.zoom.us]<https://urldefense.com/v3/__https:/icann.zoom.us/rec/play/M9Q6l-3ucT4SL0OiD…> before going into recommendation text and swimlane.

1 0

Notes and action items: TPR WG at ICANN78 on 21 Oct at 08:30 UTC/10:30 local time
by Julie Hedlund Oct. 21, 2023

Oct. 21, 2023

Dear TPR WG members, Please find below the brief notes and action items from today’s meeting. The next meeting will be in two weeks on Tuesday, 07 November at 1600 UTC. Kind regards, Christian, Caitlin, Berry and Julie ACTION ITEMS/HOMEWORK: Please review these recap materials in advance of our next call, so if there are questions or concerns you can bring them up during the call. Recap materials will be distributed, covering the recommendations from WG Group 2, 1(a), and 1(b). The next call is on November 7. We also strongly encourage you to listen to the 17 January Zoom call<https://icann.zoom.us/rec/play/M9Q6l-3ucT4SL0OiDJ0zQc9EmlMzB84MywmdUKDQqgAq…> before going into recommendation text and swimlane. Transfer Policy Review - Meeting at ICANN78 Proposed Agenda 21 October 2023 1. Welcome and Chair updates 1. Recommendations from ICANN-approved transfer (bulk transfers) are now in a stable condition. Been our focus since ICANN78. 2. We will be briefly revisiting some open questions from other Group 2 topics before transitioning back to a recap of what the WG has agreed to date, and then moving to Group 1(b), which is Change of Registrant (Part II of the Transfer Policy) in November. 3. Working Group Member updates or Stakeholder updates – none. 4. Project Status (Berry, Staff) * 5 weeks behind schedule wrapping up Group 2. * We will do a recap of all groups before moving on. * Total of 110 sessions (began Feb 2021), close to 1000 day duration, 165 hours of discussion time. * Want to try to expedite moving through CoR, preferably go to Public Comment before June ICANN Meeting 2024, have Final Recommendation Report in May. 2. Transfer Dispute Resolution Policy (“TDRP”) – Registrant Access 1. Reminder of current draft recommendation * Relevant charter question: g3) If the TDRP is considered to be insufficient: i. Are additional mechanisms needed to supplement the TDRP? ii. Should the approach to the TDRP itself be reconsidered? * Current Draft Preliminary Recommendation: The Working Group recommends the GNSO request an Issues Report or other suitable mechanism to further research and explore the pros and cons of (i) expanding the TDRP to registrant filers and (ii) creating a new standalone dispute resolution mechanism for registrants who wish to challenge improper transfers, including compromised and stolen domain names. In making this recommendation, the Working Group recognizes that if such an effort were ultimately adopted by the GNSO Council, this request could be resource-intensive and will require the Council to consider the appropriate timing and priority against other policy efforts. 1. ALAC message re: registrant access to TDRP<https://mm.icann.org/pipermail/gnso-tpr/2023-July/000945.html>: * View of the ALAC is that registrant should be given the opportunity to initiate TDRP, this should be included in the WG recommendations. This would not be for registrants to combat domain theft. It would still be under the conditions and requirements of the TDRP. The only option for registrants currently is to go to court. * The option of bringing legal option isn’t sufficient and is costly. * If no agreement in the WG ALAC will file a comment. * It is the responsibility of the Registrar to educate, guide, explain to the registrant. * Options in light of ALAC feedback and previous discussion. When we introduced the topic earlier, we noted this was discussed/scoped by IRTP-D WG, they decided not to overload the TDRP. Potential options: * Require registrar-provided rationale in the event registrar refuses to file TDRP. * Registrant responsibility for TDRP fee. * Open TDRP to registrant filers (where registrant is responsible for payment of fee, irrespective of outcome – similar to UDRP). * Note: Need to ensure this is separate from other similar actions/processes. * In this case, also similar to UDRP, the registrars would be responsible for registrar verification of data. * Leave recommendation as is. * Other Options? Discussion: * There are other policies that this may impact, e.g. ERRP. It is important to untangle that. * Strongly think there needs to be a process, but need to investigate who the parties would be and what it would be – not the TDRP. * Registries don’t think TDRP is the right mechanism – it is a very targeted process. From a registry perspective, concern that if TDRP is cracked open that it would not get worse. If rewritten, concern it would be expanded. Perhaps if there was another mechanism/tool. * Should do something but should be separate/standalone and not UDRP. * Registrars don’t initiate a TDRP but do so when registrant alerts them – should they provide a rationale if they don’t initiate. * Before we go too far down the request for an Issue Report, need to consider other transfer issues – such as inter-registrant transfer – might want to wait until the WG discusses all related issues. * From group 1a and 1b discussions, post-transfer restriction or policy issues out of Change of Registrant. The third option is on the table with current issue report recommendation, but the first two may be wanting more thoughts on this for an interim solution. It may be 3+ years until such a policy is enacted. * Registrant could be confused by what it an inter-registrar transfer. * Sounds like there is support for expanding (to bullet a.) If ALAC can provide comments during Public Comment that would be helpful This group is not scoped to do this – is there something we can do as an interim solution – get feedback on these options:: * Require registrar-provided rationale in the event registrar refuses to file TDRP * Allow the registrant to be responsible for any fee required by the TDRP provider * If the fee is set the registrant has the option to decide and can be well informed; still need to determine who would be the parties to the dispute. E.g. would it be filed against the Gaining Registrar, Losing Registrar, or gaining registrant? Whether that is TDRP or another vehicle. Thoughts on the first two options in the interim? * Don't believe ALAC has discussed fees on this, but if the registrant is informed of the fees they can weigh the pros and cons. The fee should be transferred and well-informed. * If we make a policy change that the registrant can pay the fee, my concern is the Registrar already knows that it will fail because the policy was followed. * The one filing would be the customer/client of the former Registrar. Their ability to do anything is already diminished because they don’t have access. * Maybe have a mechanism that is tied to getting domain back that is broader than just a failure of following the Transfer Policy. Registrants likely won't know the transfer policy well enough to know whether it was followed. We don't want registrants losing all the time. * Always a bunch of lawyers involved. I doubt a registrant will pay without any legal backup. If the process is opaque maybe, but the registrant should advise legal counsel before filing TDRP. * Leave the UDRP to trademark stuff. * What about the first bullet? Registrars don’t typically initiate the TDRP on their own, the registrant contacts them and tells them something is wrong. Should we require a letter/rationale why they won’t pursue the TDRP. Maybe this is a course of action? * Don’t think it's necessary. The panel should provide that data. If there is lack of support from the registrar, I don’t think the registrar will be willing to provide this data. * Think the current recommendation may eventually create a panel. Option 1 or 2 is something to do in the interim. Can we/should we add language to require Registrar to provide rationale in the interim? * Two situations: when the person filing is mad their domain moved between registrars, or mad because they lost their domain. The TDRP is about: did you violate the policy? We need to consider the broader scope, there will be more discussions about this when we talk about inter-registrant policy. Maybe before we start spinning work on this, we consider waiting until we discuss CoR. * If this is just an intra-registrar issue, that is something to think about. * Introducing a new policy will likely delay our work and would be out of scope. ICANN Compliance already has a role, maybe we expand current language that would open a route for registrants to go through ICANN Compliance, enabling them to get more information they can use. * If we are not careful, we will get into circular dependencies. Looking at Change of Registrant, when we did the high-level overview, the group had momentum about tearing down what is a Material Change for CoR. These were directly connected to what Rick was talking about re: disputes of CoR not change of Registrar. Maybe making a new mechanism could be a way forward in the meantime. * Change of Registrant may also be tangled with EDDP/ERRP. Need to be aware how a registrant could be confused about filing. 3. TDRP updates in light of EPDP – Temp Spec – Phases 1, Recommendation 27 1. Refresher of EPDP Team Recommendation #27. “The EPDP Team recommends that as part of the implementation of these policy recommendations, updates are made to the following existing policies / procedures, and any others that may have been omitted, to ensure consistency with these policy recommendations as, for example, a number of these refer to administrative and/or technical contact which will no longer be required data elements: * Registry Registration Data Directory Services Consistent Labeling and Display Policy * Thick WHOIS Transition Policy for .COM, .NET, .JOBS * Rules for Uniform Domain Name Dispute Resolution Policy * WHOIS Data Reminder Policy * Transfer Policy * Uniform Rapid Suspension System (URS) Rules * Transfer Dispute Resolution Policy 1. Proposed updates to TDRP in light of Rec. 27 – see: https://docs.google.com/document/d/12ncsCc_sYiBs2cRZVOPCrBes92aV0p-6S-7hNBk… Relevant Excerpt from ICANN Impact Paper: “TDRP section 3.2.4 provides that a panel appointed by a TDRP provider will “review all applicable documentation and compare registrant/contact data with that contained within the authoritative Whois database and reach a conclusion not later than thirty (30) days after receipt of Response.” This provision relies on comparison with the "authoritative Whois database," which does not have a clear analogue in the new Registration Data Policy.” * ICANN Impact Paper notes: o Data could be requested by the panel (similar to UDRP), though that may result in duplicative data; OR o Requirements could be written at a higher level o In the current draft [docs.google.com]<https://urldefense.com/v3/__https:/docs.google.com/document/d/12ncsCc_sYiBs…>, both are included – thoughts? o Further discussion Discussion: * TDRP / Rec 27. ICANN org delivered an impact policy that discussed what may need to be changed from EPDP Phase 1 recommendations. There is no clear analogue for “authoritative Whois database” in TDRP. Two potential options: (1) Data could be requested by the panel (like UDRP) but this may produce duplicative data; (2) Requirements could be written at a higher level. Both options were included in the current draft<https://docs.google.com/document/d/12ncsCc_sYiBs2cRZVOPCrBes92aV0p-6S-7hNBk…>, but received no WG comments, so we wanted to make sure the WG is happy with the current recommendations. * Sending the gaining FOA in no longer a requirement, so changes have been reflected * Panel determines whether a violation of policy occurred based on the information provided. * We will send a link with this to make sure everyone is okay with this. * Any comments on these? * Where does this data come from? Want to raise this as a potential challenge. * There are evidentiary requirements the Registrar would be following, that is worth looking at. 4. If time allows, presentation of Group 2 – ICANN-approved transfers recommendations and any feedback received Shortly after this meeting, the WG will receive a recap of where we are now. Support staff tried to highlight all the changes and draft recommendations thus far. We will distribute this recap document as well as updated swimlane. Since we have some time now, we will cover the recommendations from Group 2 (TEAC, TDRP, ICANN-approved Transfers). TEAC Recommendations: * TEAC Prelim Rec 1: The WG recommends updating the required timeframe for initial response from 4 hours to 24 hours / 1 calendar day. * TEAC Prelim Rec 2: The WG recommends that the initial communication to a TEAC is expected to occur no more than 30 days following the alleged unauthorized loss of a domain. * TEAC Prelim Rec 3: The WG recommends that substantive updates by email to the Losing Registrar occur at least every 3 calendar days until work to resolve the issue is complete. * TEAC Prelim Rec 4: Refers to the format of communication, and adding text around notification requirement that the initial email to the TEAC starts the clock. * TEAC should there be a fast undo, clawback recommendation. A small team drafted a process, but the majority of the group seemed to think informal resolution works today. Adding to the Transfer Policy may add complications and so this mechanism was not added to the policy TDRP Recommendations: * TDRP Prelim Rec 1: The WG discussed opening TDRP to registrants, and recommended GNSO request an issue report to further look at these issues. * TDRP, Rec 27 - Prelim Rec 3 : textual changes to account for updated language in new policy ICANN-Approved Transfers Recommendations * Explanation of icons. Farm: a registrar is transferring all of its gTLDs to another registrar; Herd: only transferring a particular TLD; Single cow: partial portfolio transfers * Prelim Rec 1: The RO MAY charge a fee, and MAY waive the fee * It would be good to do some editorial work around the context of these recommendations. On the screen it says “Full domain name portfolio transfers”. Would be good to specify an “ICANN-approved full domain name portfolio transfer”. Once we publish these recommendations it should be very clear this is not BTAPPA. * Prelim Rec 2: Makes clear the number of names and price ceiling are staying the same, status quo. The ecosystem has changes since the policy was initially drafted, now there maybe many registries involved in a bulk transfer, look at recs 3-6 for allocation recommendations. * Prelim Rec 3: Due to the variable nature of the fee associated with full portfolio transfers, the WG recommends that ROs MUST provide notice to registrars of any fees associated with full portfolio transfers upon request. * Due to Rec 2, we changed how this mechanism works. Now there is a hard cap on fees to Gaining Registrar. No fee schedule, it is fixed to cap $50,000. Given the way discussions have unfolded, I would suggest dropping Rec 3 as it may be burdensome/silly. There is no more schedule. If Rec 2 changes and the fee schedule becomes variable again then we can bring it back. * It says “variable nature of the fee”, but I guess the fee isn't variable now? * You’re right the variable nature has disappeared, I think that is a good call to drop it. Do others disagree? * Then Rec 4 may not be actionable. * Rec 4 I think still applies and can be used * Registries are still good with Rec 4. * Prelim Rec 4: this notes that if a Registry decides to waive their fee, the others cannot charge more to bring the fee up to $50,000 * Prelim Rec 5: ROs would need to provide notice to ICANN with the number of domains transferred * Prelim Rec 6: ICANN would send a notice to the ROs with reported numbers and corresponding percentages of domain names involved in the bulk transfer. * “According to registrar’s fee schedule” is this language still appropriate? * Prelim Rec 7: the Gaining Registrar MUST be responsible for paying the relevant Registry’s fee (if any). BTAPPA/Change of Sponsorship Recommendations * Prelim Rec 1: Opening BTAPPA to include circumstances where a reseller/service provider wants to transfer its portfolio of domain names to a new Gaining Registrar * Prelim Rec 2: WG recommendation to notify affected registrants approximately 1 month before the change of sponsorship is expected to occur. * “by X date if desired” should that be before the transfer occurs? Let’s try to fill that in. * To clarify ICANN does not approved BTAPPA, it is a service provided by the registry * Prelim Rec 3: update to boilerplate BTAPPA language, confirming status quo that * Prelim Rec 4: RO must reject a change if there is evidence * The WG has been talking about the macro changes, but we have recommendations on micro language. We haven't come to an agreement whether BTAPPA is going to be required or not. * Either these recommendations go into BTAPPA boilerplate or they go into Transfer Policy. Where they will go is our only open question in bulk transfers, but the recs themselves still apply either way. So these are building block recommendations, like pre-preliminary recommendations? * No matter where they go, these are our recommendations. The group agreed to these, but not yet to where they go * Prelim Rec 5: Relevant agreements need to permit this type of transfer if using BTAPPA service * Prelim Rec 6: RO MAY charge a fee for a change of sponsorship, but ROs MUST provide notice to Registrars of any fees associated with a change of sponsorship * Prelim Rec 7: Notes that the gaining registrar must not impose a new inter-registrar transfer lock as this was not initiated by registrants ACTION ITEM: Please review these recap materials in advance of our next call, so if there are questions or concerns you can bring them up during the call. Recap materials will be distributed, covering the recommendations from WG Group 2, 1(a), and 1(b). The next call is on November 7. We also strongly encourage you to listen to the 17 January Zoom call<https://icann.zoom.us/rec/play/M9Q6l-3ucT4SL0OiDJ0zQc9EmlMzB84MywmdUKDQqgAq…> before going into recommendation text and swimlane.

1 0

Agenda and action items: TPR WG Meeting #108 on 21 Oct at 0830 UTC
by Christian Wheeler Oct. 17, 2023

Oct. 17, 2023

Hello TPR WG members, The TPR Working Group will be meeting this Saturday, 21 October, at 08:30 UTC (10:30 Hamburg time) for ICANN78. Please find the proposed meeting agenda below. As a reminder, today is the deadline to submit comments on the Changes to Bulk Transfer Recommendations Google Doc<https://docs.google.com/document/d/1_T41SQAH3duIPS9qhYE71iM5CAxpA3KUpgy55DK…>. If you have any substantive concerns regarding these preliminary recommendations, please submit them by end of day. Thank you, and we look forward to seeing you in Hamburg/virtually! Kind regards, Christian, Caitlin, Berry and Julie Transfer Policy Review - Meeting #108 Proposed Agenda 21 October 2023 1. Welcome and Chair updates 1. Recommendations from ICANN-approved transfer (bulk transfers) are now in a stable condition 2. We will be briefly revisiting some open questions from other Group 2 topics before transitioning back to a recap of what the WG has agreed to date, and then moving to Group 1(b), which is Change of Registrant (Part II of the Transfer Policy). 3. Working Group Member updates or Stakeholder updates 2. Transfer Dispute Resolution Policy (“TDRP”) – Registrant Access 1. Reminder of current draft recommendation * Relevant charter question: g3) If the TDRP is considered to be insufficient: i. Are additional mechanisms needed to supplement the TDRP? ii. Should the approach to the TDRP itself be reconsidered? * Current Draft Preliminary Recommendation: The Working Group recommends the GNSO request an Issues Report or other suitable mechanism to further research and explore the pros and cons of (i) expanding the TDRP to registrant filers and (ii) creating a new standalone dispute resolution mechanism for registrants who wish to challenge improper transfers, including compromised and stolen domain names. In making this recommendation, the Working Group recognizes that if such an effort were ultimately adopted by the GNSO Council, this request could be resource-intensive and will require the Council to consider the appropriate timing and priority against other policy efforts. * ALAC message re: registrant access to TDRP<https://mm.icann.org/pipermail/gnso-tpr/2023-July/000945.html> 1. Options in light of ALAC feedback and previous discussion · Require registrar-provided rationale in the event registrar refuses to file TDRP · Registrant responsibility for TDRP fee · Open TDRP to registrant filers (where registrant is responsible for payment of fee, irrespective of outcome – similar to UDRP). In this case, also similar to UDRP, the registrars would be responsible for registrar verification of data. · Leave recommendation as is · Other Options? 3. TDRP updates in light of EPDP – Temp Spec – Phases 1, Recommendation 27 1. Refresher of EPDP Team Recommendation #27. “The EPDP Team recommends that as part of the implementation of these policy recommendations, updates are made to the following existing policies / procedures, and any others that may have been omitted, to ensure consistency with these policy recommendations as, for example, a number of these refer to administrative and/or technical contact which will no longer be required data elements: · Registry Registration Data Directory Services Consistent Labeling and Display Policy · Thick WHOIS Transition Policy for .COM, .NET, .JOBS · Rules for Uniform Domain Name Dispute Resolution Policy · WHOIS Data Reminder Policy · Transfer Policy · Uniform Rapid Suspension System (URS) Rules · Transfer Dispute Resolution Policy 1. Proposed updates to TDRP in light of Rec. 27 · Relevant Excerpt from ICANN Impact Paper: “TDRP section 3.2.4 provides that a panel appointed by a TDRP provider will “review all applicable documentation and compare registrant/contact data with that contained within the authoritative Whois database and reach a conclusion not later than thirty (30) days after receipt of Response.” This provision relies on comparison with the "authoritative Whois database," which does not have a clear analogue in the new Registration Data Policy.” · ICANN Impact Paper notes: o Data could be requested by the panel (similar to UDRP), though that may result in duplicative data; OR o Requirements could be written at a higher level o In the current draft<https://docs.google.com/document/d/12ncsCc_sYiBs2cRZVOPCrBes92aV0p-6S-7hNBk…>, both are included – thoughts? o Further discussion 4. If time allows, presentation of Group 2 – ICANN-approved transfers recommendations and any feedback received 5. AOB

1 0

Final Review of Changes to Bulk Transfer Recommendations
by Christian Wheeler Oct. 12, 2023

Oct. 12, 2023

Dear TPR WG members, Please take the time to review the Changes to Bulk Transfer Recommendations Google Doc<https://docs.google.com/document/d/1_T41SQAH3duIPS9qhYE71iM5CAxpA3KUpgy55DK…> and submit any comments or concerns by COB Tuesday, 17 October. Please note that at this point, we are looking for substantive concerns, rather than mere textual edits. If no issues remain, then these preliminary recommendations will be considered stable. As a reminder, we will not be meeting on Tuesday, 17 Oct. The next TPR WG meeting will be during ICANN78 on Saturday, 21 October, at 08:30 UTC. More details to come. Kind regards, Christian, Caitlin, Berry and Julie

1 0

Notes and action items: TPR WG Meeting #107 on 10 Oct at 1600 UTC
by Christian Wheeler Oct. 10, 2023

Oct. 10, 2023

Dear TPR WG members, Please find below the brief notes and action items from today’s meeting. The next meeting will be during ICANN78 in Hamburg, on Saturday 21 October at 08:30 UTC (10:30 local time) Kind regards, Christian, Caitlin, Berry and Julie ACTION ITEMS/HOMEWORK: 1. Staff to update the draft recommendations based on today’s discussion 2. WG members to review the updated recommendations and provide any feedback by COB Tuesday, 17 Oct Transfer Policy Review - Meeting #107 Proposed Agenda 10 October 2023 1. Welcome and Chair updates * We will not have our usual Tuesday meeting next week. * Our next meeting will be in Hamburg for ICANN78, at 10:30 local time, Saturday 21 October. * Ken Herman (NCSG): I have had consultations with the Non-Commercial community regarding the 30 day notification. 6 weeks (calendar days) is the preferred length of time for our community. * We will revisit that recommendation again for WG discussion. * Jim Galvin (RySG): I have had consultations with RySG regarding the two ICANN-Approved Transfer charter questions. The RySG would prefer to leave the policy as is, but with two updates: 1. The trigger for bulk transfer fee should remain at 50,000 domains, but based on the number of domains leaving the Registrar, not going into the Registry. The apportioning of the fee should be based on the number of domains going into each Registry. 2. Regarding BTAPPA scope being expanded or made uniform, the current preference is to remain as is. Given that BTAPPA is currently a fast-track RSEP, the RySg is open to considering additional uniformity around that. * We have been focussing on portfolio transfers involving a single RO, but that is not common. There are usually several ROs, so I agree with the approach of considering all ROs and basing totals on a per Registrar basis. Will need to discuss more with Registrar colleagues. * There is another minor BTAPPA wording change ROs would like to see around “merger” or “acquisition”. 2. Continued discussion of Charter Question i1 (Full Portfolio Transfers AKA Bulk Transfers) and Charter Question i2 (Change of Sponsorship AKA Partial Bulk Transfers) Discussion of updated recommendations [docs.google.com]<https://urldefense.com/v3/__https:/docs.google.com/document/d/1_T41SQAH3duI…> (updated as a result of last week’s meeting): i1) In light of these challenges described in section 3.1.7.2 of the Final Issue Report [gnso.icann.org]<https://urldefense.com/v3/__https:/gnso.icann.org/sites/default/files/file/…>, should the required fee in Section I.B.2 of the Transfer Policy<https://www.icann.org/resources/pages/transfer-policy-2016-06-01-en> be revisited or removed in certain circumstances? Full Portfolio Transfers Prelim Rec. #xx.1: (i) The Working Group recommends that a Registry Operator MAY charge a fee to implement a full domain name portfolio transfer of 50,000 or more domain names from one ICANN-accredited registrar to another ICANN-accredited registrar, provided the conditions described in sections I.B.1.1 and I.B.1.2 are satisfied. (ii) The Registry MAY waive the fee associated with full portfolio transfers; however, in full portfolio transfers resulting from an involuntary registrar termination, i.e., where a registrar is terminated by ICANN due to non-compliance with the Registrar Accreditation Agreement, the Working Group recommends the Registry MUST waive any fee associated with a full portfolio transfer. Discussion: * The text says “from one ICANN-accredited registrar to another ICANN-accredited registrar”; does this allow for it to be split among multiple ICANN-accredited registrars? * Overwhelming preference is to move all domains to one Registrar, but there may be an instance where a Registrar does not offer all the relevant TLDs, so domains would need to be split among Registrars. * I think that it’s happened... but a registry only experiences one full transfer. I’ve never seen a registrar’s per-TLD portfolio being split * It could be hard to find a registrar that is accredited for ALL TLDs in the future * ICANN pays attention early to which gTLDs a registrar is accredited when considering the termination process and the Compliance breach process Prelim. Rec. #xx.2: The Working Group recommends retaining both (i) the current minimum number of domain names that trigger the fee at 50,000 names and (ii) the current price ceiling of USD $50,000. If the full portfolio transfer involves multiple Registry Operators, the affected Registry Operators MUST ensure the collective fee does not exceed the recommended ceiling of USD $50,000, and the fee MUST be apportioned based on the number of domain names transferred. Discussion: * I am confused how this is going to work unless ICANN gets involved earlier. * There are two kinds of full portfolio transfers: voluntary and involuntary. With voluntary portfolio transfers, if it is greater than 50,000 names then you can charge, that will be apportioned. We are changing the way that $50,000 limit works, so it doesn't go to any one Registry, it gets apportioned. And still the Registry MAY charge the fee. * The “notice” is that if there are more than 50,000 names, the registrar could pay up to $50,000. Partial Portfolio Transfers Prelim. Rec. #xx.1: The Working Group recommends that [the standard Bulk Transfer After Partial Portfolio Acquisition (BTAPPA)] be expanded to include circumstances where an agent of the Registrar, such as a Reseller or service provider, elects to transfer its portfolio of domain names to a new gaining registrar, and the registration agreement explicitly permits the transfer. Discussion: * Question: is that the Losing Registrar’s registration agreement or the Gaining Registrar’s? If it is the Losing Registrar, that could be a problem. * I believe that it would be the Losing Registrar. * The Gaining and Losing Registrar usually come to an agreement. BTAPPA was conceived as a partial portfolio from the Losing Registrar, so it is different. The RO isn’t checking, the Registrars would be making sure the notifications and agreements are completed, then they communicate to the RO. * In contracts there is already an advance consent of the registrant. Similar to the Designated Agent and resellers. But BTAPPA is not offered everywhere, so it needs to be allowed whether going in or out. * The registration agreement (of the Losing Registrar) has to explicitly allow this so the registrant is aware this can happen to them. * The IRT may be confused by the current language. We need to be very precise and specific with this text. Currently, do the agreements not prohibit transfers or do transfers need to be explicitly permitted? * They may not be prohibited, but having it allows registrant to be more informed. * I believe the language “agent of the Registrar, such as a Reseller or service provider” should be put on the registrant, i.e. as an “agent of the registrant”. * A reseller can be both the agent of the Registrar and the registrant. * This change of sponsorship is not initiated by the registrant, why the need to add registrant into this? * Staff understanding was that if a reseller wants to change Registrar it must transfer the domains manually one-by-one, and that this WG wanted the BTAPPA to be expanded to allow this to happen in a bulk scenario, which is not currently allowed in BTAPPA. If this is not the intention, please let us know. * The current fast-track wording implies the RO is not allowed to do a BTAPPA unless there is a merger, acquisition, or similar. The concern is that even though the involved registrar/registry is agreeable, they may be running afoul of the RSEP. We want the boilerplate language to allow agreeable actors to do what they want to do in the RSEP. * We have done BTAPPAs before where we signed an agreement with the Losing Registrar that we would buy the right to manage the portfolio, therefore it was a portfolio acquisition and was granted by the registry. That is a scenario we have done in the past, but that might not always fit or be possible. * As to the language, I would probably just expand on it where it says, where an agent of the registrant, such as the reseller service provider “acting under the authority or on behalf of the registrant”, elects to transfer… * I would be hard pressed to lose the last line, but I think we should make sure that it has language that basically states that this is the portfolio managed by an agent/service provider of the registrar losing those domain names, and is going to be transferred as a whole portfolio. Where previously only entire portfolios were able to be merged, this is a partial portfolio transfer for that registrar, but a full portfolio transfer for that reseller or agent. * Perhaps updating to “Agent of the Registrar OR registrant” to account for both scenarios? * Rec 1 looks good, just add some clearer language to it. Prelim. Rec. #xx.2: The Working Group recommends that in the event a change of sponsorship is permitted by the Registry Operator, Registrars shall either notify or ensure their Resellers (where applicable) notify affected Registrants approximately one month* before the change of sponsorship is expected to occur. This notification must provide instructions on (i) how to opt out (if applicable) (ii) how to transfer the name to a Registrar other than the Gaining Registrar [by x date] if desired], (iii) the expected date of the change of sponsorship, (iv) the name of the Gaining Registrar, and (v) a link to the Gaining Registrar’s (or their Reseller’s) terms of service * The WG recognizes that some flexibility is required in the timing of Change of Sponsorship (BTAPPA) notifications. As such, one month should be treated as no less than 26 and no more than 35 days. A registrar is not precluded from sending additional notifications earlier or later than this required one month notification. Discussion: * We would prefer no less than 30 calendar days, another 2 weeks would help. * To initiate a transfer, Registrars have to respond within a certain amount of time, also time for the registrant to read and understand it. * Current policy is 15 days, WG originally converged on expanding to 30 days to give more time and for consistency with other periods * These are voluntary negotiated transfers, so there doesn’t seem to be an urgency or emergency to reduce that time. Are there any objections to 45 days? * BTAPPA is not initiated by the registrant but the reseller or Registrar, there is no requirement to inform them and no change to the expiration date. Consider that when deciding the number of days. * One month makes sense but 45 days is too long. Many registrars will provide multiple notifications to remind them anyway. If the bare minimum is only 45 days, that is too far in advance. The registrant may forget or disregard because it is so far out. * My experience with resellers is the notification is sent and most people do not care, they did not choose their Registrar to begin with. Most people do not read this. * In many cases, the impact on the registrant is negligible. The notification will more likely cause confusion to the registrant. * Some non-commercial entities are concerned about where their domain sits, so they need to be alerted. * Let’s leave this as it is for now, but everyone give it some more thought. Prelim. Rec. #xx.7: In the case of a change of sponsorship, the Losing Registrar MAY have to prevent certain locked domain names from proceeding with the sponsorship change: specifically, names that are locked due to: (i) Pending UDRP proceeding that the Registrar has been notified of by the Provider in accordance with the UDRP Rules, (ii) a court order by a court of competent jurisdiction, (ii) a pending dispute under the Transfer Dispute Resolution Policy, or (iv) Pending URS proceeding or URS suspension that the Registrar has been notified of by the Provider in accordance with the URS Procedure. Rationale: The Working Group notes that the majority of domain name locks, including registrant-applied locks and EPP lock statuses, will remain in place following a change of sponsorship/BTAPPA scenario. However, domain names with locks applied as a result of the above specifically-named dispute proceedings/court orders involve jurisdictional challenges, and accordingly, will not be transferred to the Gaining Registrar. Discussion: * This reflects what we want but it may be an operational challenge to implement. * Aren’t they operational challenges today? Does this make it more challenging? * The law always supercedes the contract. We don’t need to make a list of all the things that may get in the way of this, we probably don’t need to say anything at all. * In current cases where Registrars are losing their accreditations, what happens to those domains that are mandated to be locked? * That issue is separate from this BTAPPA scenario. I think we remove the language listing all the caveats that we have to do already and instead focus on what we are trying to achieve with this rec; that there is no change to the locks or EPP statuses. * Perhaps a confirmation statement rather than a recommendation? Prelim. Rec. #xx.8: In the case of a change of sponsorship, the Gaining Registrar MUST NOT impose a new inter-registrar transfer lock preventing affected registrants from transferring their domains to another Registrar. Rationale: The Working Group notes that a change of sponsorship is not initiated by registrants and does not affect their domain name expiration dates; therefore, the transfer lock that would otherwise follow a typical inter-registrar transfer should not apply in this instance. Transfer locks that are triggered by other means set out in the Transfer Policy would still apply. Discussion: * No WG disagreement. * Continue to think about whether BTAPPA changes should be reflected in the boilerplate or Transfer Policy. * Staff will make small changes to the recommendations based on the conversation today. * Once they are updated, please review these recommendations again, if no comments are received by COB Tuesday, we will assume they are stable enough to be included in the Initial Report. Meeting concluded

1 0

Post Call | Transfer Policy Review PDP WG | Tuesday, 10 October 2023
by Devan Reed Oct. 10, 2023

Oct. 10, 2023

Dear all, All recordings for the Transfer Policy Review PDP WG call held on Tuesday, 10 October 2023 at 16:00 UTC can be found on the agenda wiki page <https://community.icann.org/x/hYjxDg> (attendance included) and the GNSO Master calendar<https://urldefense.com/v3/__https:/gnso.icann.org/en/group-activities/calen…>. These include: * Attendance * Audio recording * Zoom recording (including audio, visual, rough transcript, and chat.) * Transcript * Agenda and Notes/Action Items As a reminder only members and alternates can join the call as a Panelist, observers can join as an Attendee to listen. For additional information, you may consult the mailing list archives <https://mm.icann.org/pipermail/gnso-tpr/> and the main wiki page<https://community.icann.org/x/P4aUCQ>. Thank you. With kind regards, Devan

1 0

Meeting Invitation | Transfer Policy Review PDP WG call | Tuesday, 07 November 2023
by Devan Reed Oct. 10, 2023

Oct. 10, 2023

NOTE: The next time the TPR PDP WG meets is during ICANN78: Wiki page: https://community.icann.org/x/UQDCDw Please remember to register for ICANN78 Zoom participation links will be published here <https://meetings.icann.org/en/icann78> 24 hours before the session starts. Dear all, The next Transfer Policy Review PDP WG call is scheduled for Tuesday, 07 November 2023 at 16:00 UTC for 90 minutes. * If unable to attend, members must communicate their alternate replacement using this google form<https://urldefense.com/v3/__https:/docs.google.com/forms/d/e/1FAIpQLScXP3-H…>. To join - Zoom Information: Main Zoom Webinar link: https://icann.zoom.us/j/95363727469?pwd=N3A3OWFSaTlUME9wZzlGajk5VUI3QT09 <https://urldefense.com/v3/__https:/icann.zoom.us/j/95363727469?pwd=N3A3OWFS…> Passcode: @TP/^*4wg# If you are joining via audio only: One tap mobile: US: +19294362866,,95363727469#,,,,*7490739013# or +13017158592,,95363727469#,,,,*7490739013# Telephone: Dial (for higher quality, dial a number based on your current location): US: +1 929 436 2866 or +1 301 715 8592 or +1 312 626 6799 or +1 669 900 6833 or +1 253 215 8782 or +1 346 248 7799 or 888 788 0099 (Toll Free) or 877 853 5247 (Toll Free) Webinar ID: 953 6372 7469 Passcode: 7490739013 International numbers available: https://icann.zoom.us/u/acdLFXPLp6 <https://urldefense.com/v3/__https:/icann.zoom.us/u/acdLFXPLp6__;!!PtGJab4!v…> Members, alternates, and observers all have different access and participation directions, please read below! ALL: Before joining the call: * Please send apologies and dial out requests to gnso-secs(a)icann.org<mailto:gnso-secs@icann.org> only * Please be sure you have read the ICANN Expected Standards of Behavior<https://www.icann.org/resources/pages/expected-standards-2016-06-28-en> * Visit the Wiki Agenda meeting page: https://community.icann.org/x/P4BFE * Time conversion link: https://tinyurl.com/2htzcfpy ONLY FOR MEMBERS & ALTERNATES: * Staff will promote members and alternates to panelist once joined. * Chat: Please select Everyone so everyone can see your chat, and so it’s captured in the recording. * If unable to attend, members must communicate their alternate replacement using this google form<https://urldefense.com/v3/__https:/docs.google.com/forms/d/e/1FAIpQLScXP3-H…>. * Alternate assignments will be publicly posted to the Alternate Log-Transfer Policy Review PDP<https://community.icann.org/x/V4aUCQ> wiki page. * Alternates (not replacing a member): Rename your line by adding 3 Zs (zzz) before your name and add, your affiliation - alternate after your name. * Alternates (not replacing a member) are not allowed to engage in the chat or use any of the other zoom room functionalities such as raising hands or agreeing/disagreeing. ONLY FOR OBSERVERS: * Observers will have ability to view member chat and information shared in the zoom webinar room. * Observers will not be able to use chat or raise hands. Thank you. Kind regards, Devan

1 0

15 MINUTES **REMINDER** Meeting Invitation | Transfer Policy Review PDP WG call | Tuesday, 10 October 2023
by Devan Reed Oct. 10, 2023

Oct. 10, 2023

**15 Minutes Dear all, The next Transfer Policy Review PDP WG call is scheduled for Tuesday, 10 October 2023 at 16:00 UTC for 90 minutes. * If unable to attend, members must communicate their alternate replacement using this google form<https://urldefense.com/v3/__https:/docs.google.com/forms/d/e/1FAIpQLScXP3-H…>. To join - Zoom Information: Main Zoom Webinar link: https://icann.zoom.us/j/95363727469?pwd=N3A3OWFSaTlUME9wZzlGajk5VUI3QT09 <https://urldefense.com/v3/__https:/icann.zoom.us/j/95363727469?pwd=N3A3OWFS…> Passcode: @TP/^*4wg# If you are joining via audio only: One tap mobile: US: +19294362866,,95363727469#,,,,*7490739013# or +13017158592,,95363727469#,,,,*7490739013# Telephone: Dial (for higher quality, dial a number based on your current location): US: +1 929 436 2866 or +1 301 715 8592 or +1 312 626 6799 or +1 669 900 6833 or +1 253 215 8782 or +1 346 248 7799 or 888 788 0099 (Toll Free) or 877 853 5247 (Toll Free) Webinar ID: 953 6372 7469 Passcode: 7490739013 International numbers available: https://icann.zoom.us/u/acdLFXPLp6 <https://urldefense.com/v3/__https:/icann.zoom.us/u/acdLFXPLp6__;!!PtGJab4!v…> Members, alternates, and observers all have different access and participation directions, please read below! ALL: Before joining the call: * Please send apologies and dial out requests to gnso-secs(a)icann.org<mailto:gnso-secs@icann.org> only * Please be sure you have read the ICANN Expected Standards of Behavior<https://www.icann.org/resources/pages/expected-standards-2016-06-28-en> * Visit the Wiki Agenda meeting page: https://community.icann.org/x/hYjxDg * Time conversion link: https://tinyurl.com/5fjsbdwp [tinyurl.com]<https://urldefense.com/v3/__https:/tinyurl.com/5fjsbdwp__;!!PtGJab4!84D6sYF…> ONLY FOR MEMBERS & ALTERNATES: * Staff will promote members and alternates to panelist once joined. * Chat: Please select Everyone so everyone can see your chat, and so it’s captured in the recording. * If unable to attend, members must communicate their alternate replacement using this google form<https://urldefense.com/v3/__https:/docs.google.com/forms/d/e/1FAIpQLScXP3-H…>. * Alternate assignments will be publicly posted to the Alternate Log-Transfer Policy Review PDP<https://community.icann.org/x/V4aUCQ> wiki page. * Alternates (not replacing a member): Rename your line by adding 3 Zs (zzz) before your name and add, your affiliation - alternate after your name. * Alternates (not replacing a member) are not allowed to engage in the chat or use any of the other zoom room functionalities such as raising hands or agreeing/disagreeing. ONLY FOR OBSERVERS: * Observers will have ability to view member chat and information shared in the zoom webinar room. * Observers will not be able to use chat or raise hands. Thank you. Kind regards, Julie

1 0

ICANN78 GNSO Sessions - How to Get Organized / Remote Participation Details
by Julie Bisland Oct. 9, 2023

Oct. 9, 2023

Dear all, With ICANN78<https://meetings.icann.org/en/icann78> just around the corner, please take a moment to read the information below for a seamless and successful meeting. REGISTER NOW! DEADLINE TO REGISTER IS 20 October 2023! * Sign into Your ICANN Account or create an account here<https://account.icann.org/login>. * Register by selecting the Meeting Registration tile. * Click on the Registration link. NOTE: There will be no onsite registration facilities this year so you must register in advance. In-person, advance registration will close on 20 October 2023. After that point in time, only virtual participation will be open for continued registration. Walk-up and late registrations will not be accepted after the in-person advance registration closes. All walk-up and late registered attendees will only have access to virtual participation. Before creating your schedule, please read this page carefully: https://meetings.icann.org/en/remote-participation. If participating on-site, please read the Health and Safety page<https://meetings.icann.org/en/78healthandsafety>. CREATE YOUR MEETING SCHEDULE * Access the schedule here<https://icann78.sched.com/>. The schedule shows up with blank circular radial buttons to the left of each session. Hover over the radial button and click “ADD TO MY SCHEDULE” or just click to add the checkmark. * Once you’ve selected all sessions, click the My Schedule link in the lower left corner or hover over your profile and select My Schedule. * Click the Phone icon (located on the right side of the page) * In the bottom section, “Export Calendar”, click the link next to “My Schedule”. When the .ics is exported, add it to the appropriate calendar. OR, after exporting, drag and drop the .ics file into your calendar. * Please remember, for security purposes, participation links will be posted 24-hours prior to the session start times. There will be no calendar invitations sent, as the meeting schedule allows you to download all sessions of interest to your individual calendars Review the Participation Tools and update Zoom * All sessions will use Zoom rooms. Access details are available 24hrs prior. * Visit the Participation Tools page<https://meetings.icann.org/en/remote-participation> for links to download the latest version of Zoom for access to the ICANN Meeting sessions. * Please see the ICANN Meeting Virtual Participation How-To Guide for more information on how to get the most out of the virtual meeting tools. Links to Bookmark ICANN78 Meeting Schedule<https://icann78.sched.com/> GNSO ICANN78 GNSO Remote Participation Wiki Page<https://community.icann.org/x/igBgDw> GNSO Session agendas<https://community.icann.org/x/dIfxDg> For all GNSO meeting-related queries (RP or others), please email us at: gnso-secs(a)icann.org<mailto:gnso-secs@icann.org> and we will be more than happy to assist! Kind regards, GNSO SO/AC Support team -- Julie Bisland Policy Operations Sr. Coordinator (GNSO) Internet Corporation for Assigned Names and Numbers (ICANN) Skype ID: 79613b691cb8a6c1 Find out more about the GNSO by visiting: https://learn.icann.org/<https://urldefense.proofpoint.com/v2/url?u=https-3A__learn.icann.org_&d=DwM…> Follow @GNSO on Twitter: https://twitter.com/ICANN_GNSO<https://urldefense.proofpoint.com/v2/url?u=https-3A__twitter.com_ICANN-5FGN…> Transcripts and recordings of GNSO Working Group and Council events are located on the GNSO Master Calendar <https://urldefense.proofpoint.com/v2/url?u=https-3A__gnso.icann.org_en_grou…> [signature_2046185555]

1 0