Dear TPR WG Members, Please find below the notes and action items from today’s call. The next TPR WG meeting will be on Tuesday, 30 November at 16:00 UTC. Best regards, Emily, Julie, Berry, and Caitlin Action Items Losing FOA Candidate Recommendations – see: Losing FOA Working Document <https://urldefense.com/v3/__https:/nam10.safelinks.protection.outlook.com/?u...> (beginning on p. 14); Transfer Steps and Notifications [docs.google.com]<https://urldefense.com/v3/__https:/docs.google.com/spreadsheets/d/17ADMRTYxN...> Candidate Recommendation #13: ACTION ITEMS: Staff to suggest working to replace “using email”, and concerning the timing/order and language of the notification and TAC presentation/provision. Need to make sure the RNH is notified no matter how the TAC is presented. Candidate Recommendation #14: ACTION ITEM: Ask if there are volunteers for a small team that delves into whether it’s possible to provide the Gaining Registrar name, or if the IANA ID is okay – looking at making IANA ID mandatory and the name of the Gaining Registrar optional. Also update the wording so that multiple notifications can go out regardless of different Gaining Registrars. Candidate Recommendation #15: ACTION ITEM: Make the same changes to the language to be consistent with previous related candidate recommendations. Candidate Recommendation #16: ACTION ITEM: Eliminate this candidate recommendation. Transfer Policy Review Phase 1 - Meeting #25 Tuesday 23 November 2021 at 16:00 UTC 1. Roll Call & SOI Updates * No updates provided. 2. Welcome & Chair updates * Submitting a Project Change Request to move NACKing from Phase 2 to consideration under Phase 1a as it is related to other topics in Phase 1a. * Schedule of Upcoming TPR Meetings – see attached. * Update from Steiner from CCWG members – informal poll on 60-day lock – see: https://mm.icann.org/pipermail/gnso-tpr/. Ended up with some tendencies: * Majority not it favor of the 60-day lock as policy; some agreed to keep it. * Did not agree on whether 60 days was the right timing. * Agreed that there should be some kind of consensus for registrars to treat these types of locks consistently. * Once the WG reaches consensus it would be helpful to have a presentation on the WG’s final decisions to understand the rationale. 3. Losing FOA Candidate Recommendations (60 minutes) – see: Losing FOA Working Document <https://urldefense.com/v3/__https:/nam10.safelinks.protection.outlook.com/?u...> (beginning on p. 14); Transfer Steps and Notifications [docs.google.com]<https://urldefense.com/v3/__https:/docs.google.com/spreadsheets/d/17ADMRTYxN...> Candidate Recommendation #12: * Staff suggested the following language: “ The Working Group recommends that, in place of the Losing FOA, notifications are sent to the RNH when key changes take place with their account in relation to a transfer, as detailed in recommendations 13-16.” Candidate Recommendation #13: * New language based on the discussion at the last meeting: “If the Registrar of Record provides the TAC by email, and the Registrar of Record also notifies the RNH of the TAC request using email, the two messages may be combined in a single email., the email containing the TAC and the message notifying the RNH of the TAC request must be two distinct communications.” * Owen Smigelski suggested timing for the notification in an email to the list. See: https://mm.icann.org/pipermail/gnso-tpr/. * Question: Do we really need to call out email here – “using email”? Answer: We can come up with different wording for that. * Happy for the mention of the language of the registration agreement, but it is not mandatory. Think this is a MUST. Staff will check the language in the policy concerning language. * Language from the UDRP rules: “Paragraph 11 of the UDRP provides requirements with respect to the Language of Proceedings, “(a) Unless otherwise agreed by the Parties, or specified otherwise in the Registration Agreement, the language of the administrative proceeding shall be the language of the Registration Agreement, subject to the authority of the Panel to determine otherwise, having regard to the circumstances of the administrative proceeding.” And as suggested in the working document: “This notification MUST be written in the language of the registration agreement and MAY also be provided in English or other language.” * ERRP provides that expiry notifications may be presented in one or more languages, but must be provided in the language of the registration agreement. * If there is a timeline it would have to be very short. * Consider reversing the order of the notifications – the goal is to make sure the registrant does get notified. * Not sure there is agreement on the timing of the notification beyond “without undue delay.” * Current Transfer Policy Requirement:” 5.2 Registrars must provide the Registered Name Holder with the unique "AuthInfo" code and remove the "ClientTransferProhibited" within five (5) calendar days of the Registered Name Holder's initial request if the Registrar does not provide facilities for the Registered Name Holder to generate and manage their own unique "AuthInfo" code and to remove the "ClientTransferProhibited" status.” * Change the language that the timing should be first or together for the notifications. * Restructure so that it is in a more chronological order. Might be helpful to go back to the transfer/notification spreadsheet. Notification of TAC request could be mandatory and maybe eliminating other notification. * Think the notification can be combined and most registrars would send one notice. * There is a difference between the notification of the transfer request, and the TAC presentation. If the TAC is only presented in a certain way then the registrant/RNH may not know about it. The request is separate from the TAC presentation. We want to make sure the RNH is aware of when the TAC went out. * If it’s presented in the account then a notice should be sent to the RNH. Whoever made the request, the notification has to go to the RNH. * If the registrant is requesting, then there’s only one notification. If the requester and RNH are different then there has to be a separate notification to the RNH from the TAC presentation. * Presenting the TAC does not have to be in the form of a notification. * Timing: Providing the TAC synchronous with the request, or asynchronous. If asynchronous then two notifications. * ACTION ITEMS: Staff to suggest working to replace “using email”, and concerning the timing/order and language of the notification and TAC presentation/provision. Need to make sure the RNH is notified no matter how the TAC is presented. Candidate Recommendation #14: * On the language of the notification, make it consistent with the text in Candidate Recommendation #14. * How does the Losing Registrar know the name of the Gaining Registrar? Currently we don’t, so a method would have to be created, or to provide the IANA ID, or a link to the database. * Where does the registrant go to complain when the domain name has been transferred without authorization? How can the registrant learn the name of the Gaining Registrar. And the IANA ID is not going to give the registrant the name of the reseller. * But if you have the ID of the Gaining Registrar you have a place to go. * IANA ID: Could be solved with a reference to https://www.icann.org/en/accredited-registrars?filter-letter=a&sort-directio... or similar. * Perhaps the default is to make it mandatory to provide the IANA ID of the Gaining Registrar, unless there is interest in a small team to look at the technical feasibility to provide the Gaining Registrar. * Thoughts on changing to one notification per transfer transaction, which might be different Gaining Registrars? Is this a use case that wouldn’t come up? Should the policy allow for this aggregation? Don’t see a reason not to allow it. * ACTION ITEM: Ask if there are volunteers for a small team that delves into whether it’s possible to provide the Gaining Registrar name, or if the IANA ID is okay – looking at making IANA ID mandatory and the name of the Gaining Registrar optional. Also update the wording so that multiple notifications can go out regardless of different Gaining Registrars. Candidate Recommendation #15: * Important to keep this optional since it won’t happen all of the time. * Just a notification to the RNH that the TAC has been requested (but not provided). * ACTION ITEM: Make the same changes to the language to be consistent with previous related candidate recommendations. Candidate Recommendation #16: * This was the second optional notification. * Should there be this separate notification or can it be combined with others? * Seems that this overlaps with the notification of TAC provision. Don’t think we need it. * Maybe change it sending an alert? * Question: Does this serve a purpose separate from the purposes of previous recommendations and in particular candidate recommendation #13? Answer: Maybe, since it isn’t mandatory it doesn’t hurt to have it. * Maybe there is value in indicating what is included in the optional message. * If we don’t think there is a purpose for it we shouldn’t keep it. * Registrars can always send extra communication to the registrant, but don’t see a need to put that in the policy. * Don't think we need both a Notification of TAC Provision and also a Notification of Pending Transfer. Especially if the transfer is done almost instantaneously after the TAC is provided to the Gaining Registrar. * ACTION ITEM: Eliminate this candidate recommendation. 4. Rationale for Elimination of the Gaining FOA (15 minutes – time permitting) – see: Gaining FOA Working Document [docs.google.com]<https://urldefense.com/v3/__https:/docs.google.com/document/d/1QOCzbLh7w4hdi...> (beginning on p. 16) * Take this up at the next meeting. 5. AOB (5 minutes): Next call: Tuesday 30 November 2021 at 16:00 UTC