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

Input requested: More additional security measures
by Emily Barabas Oct. 29, 2021

Oct. 29, 2021

Dear WG members, As a follow-up to Tuesday’s session, staff has created a new section of the Additional Security Measures Working Document for members to list other potential security measures for the group to discuss. Please add your notes on page 8 of the working document<https://docs.google.com/document/d/1q7xaJuxi50Q6TDD26H92P6wOfZ8luap1wdWOtIg…>. We look forward to continuing the discussion on 9 November. Wishing everyone a restful break from WG activities until then. Kind regards, Caitlin, Berry, Julie, and Emily From: GNSO-TPR <gnso-tpr-bounces(a)icann.org> on behalf of Julie Hedlund <julie.hedlund(a)icann.org> Date: Tuesday, 26 October 2021 at 21:04 To: "gnso-tpr(a)icann.org" <gnso-tpr(a)icann.org> Subject: [GNSO-TPR] Notes and action items - TPR WG Meeting #23 - 26 Oct 2021 Dear TPR WG Members, Please find below the notes and action items from today’s call. The next TPR WG meeting will be in two weeks on Tuesday, 09 November at 16:00 UTC. Best regards, Emily, Julie, Berry, and Caitlin Action Items 1. ACTION ITEM: WG members to contribute to a list of additional security measures and provide other comments/suggestions in the Google doc for Additional Security Measures Working Document [docs.google.com]<https://urldefense.com/v3/__https:/docs.google.com/document/d/1q7xaJuxi50Q6…>. Transfer Policy Review Phase 1 - Meeting #23 Tuesday 26 October 2021 at 17:30 UTC 1. Chair Update 2. About the PDP and Status Update (20 minutes) -- Slides attached * About the Transfer Policy: “ICANN consensus policy governing the procedure and requirements for registrants to transfer their domain names from one registrar to another.” * Formerly called the Inter‐Registrar Transfer Policy (IRTP) * Went into effect in November 2004 * GNSO reviewed the policy once before, shortly after implementation * Mission and Scope: PDP to conduct a holistic review of the Transfer Policy and determine if changes to the policy are needed to improve the ease, security, and efficacy of inter-registrar and inter-registrant transfers. * Conducted in 2 Phases under a single Charter<https://community.icann.org/display/TPRPDP/2.%2BWG%2BCharter> <https://community.icann.org/display/TPRPDP/2.%2BWG%2BCharter> & covering 8 topics. * PDP began Phase 1(a) in May 2021: * Phase 1(a) Topics: Forms of Authorization and AuthInfo Codes * The working group has now conducted initial deliberations on each of the Phase 1(a) topics and has begun to develop “candidate recommendations” and draft responses to charter questions. * While members and alternates are limited to representatives designated by SO/AC/SG/Cs, anyone can sign up to observe. * Topics: * AuthInfo Code Management * Gaining & Losing Registrar Form of Authorization (FOA) * FOA: Further Work Needed * EPDP included the workaround from the Temporary Specification in its recommendations, which were adopted by the ICANN Board. * Registrars identified challenges in ICANN org’s position that a Gaining Registrar is required to send a Gaining FOA where the email address “is available”, as there is no guarantee that the email goes directly to the registrant. * ICANN Board passed a resolution to defer contractual compliance enforcement of the Gaining FOA requirement pending further work in this area. * Contracted Party House Tech Ops Subcommittee has developed a proposal for a proposed transfer process. * Status: Potential Recommendations Under Consideration * Eliminate requirement for the Gaining Registrar to send the Gaining FOA and obtain consent from the Registered Name Holder before it may proceed with the transfer. * Eliminate requirement for the Losing Registrar to send the Losing FOA to the Registered Name Holder. * New notifications from the Losing Registrar to the Registered Name Holder when key changes are made to the account, some mandatory for the Losing Registrar to send, others optional. * Additional security for the AuthInfo Code, which the group is recommending be called the “Transfer Authorization Code” (TAC). Highlights: * ➔ Minimum requirements for TAC syntax/complexity, adherence to requirements confirmed by registry * ➔ Losing Registrar generates TAC upon request * ➔ TAC may only be used once * ➔ TAC is valid for a limited period of time (Time to Live) * ➔ Registry must securely store the TAC using a one-way hash that protects the TAC from disclosure * After the WG has reviewed the elements relating to single transfers, the WG will consider issues relating to bulk transfers. 3. Deliberations on Additional Security Measures (60 minutes) -- see: Additional Security Measures working document [docs.google.com]<https://urldefense.com/v3/__https:/docs.google.com/document/d/1q7xaJuxi50Q6…> Overview: * Staff and leadership developed a chart of an overview of inter-registrar transfer locks following last week’s discussion. * To help everyone understand what locks we are talking about. * Where we are unsure of the origin of a lock staff has inserted an asterisk (*). * Looking for feedback to make sure this is complete and accurate. Discussion: * A lot of registrars apply locks by default to protect against unauthorized transfers. * Not all domain locking is an additional security measure – whether it prevents hijacking depends on good account security – it is a dependency. If you lose control of the account it doesn’t matter if there is a lock or not. Need to capture these details. * The key is if we say that there is a mandatory lock and if someone gets ahold of someone’s account, it doesn’t matter since it can’t be transferred for 60 days. It becomes a more difficult hack if you have to hack both the registrar and registry accounts. * The concern with these stated security features is that there is a relationship between them – we need to capture and recognize that. Challenging to talk about them in isolation. * Question: What do the asterisks mean? Answer: It denotes uncertainty on the staff support side as to the origin of a lock – indicating that the origin is a guess. * First row: If this lock that many registrars do upon creation: the charter question a6 is whether this should be mandatory or just allowed as it is today. Leaning towards keeping it optional, but focusing on trying to keep it as consistent as possible across registrars. * Is there an opportunity to get more information about the impact/concerns relating to inconsistency of application of locks? * The charter question being specific to this first row – seems that we have answered that, but we need to resolve the 60-day creation. * “Lock means a set of measures that a registrar applies to a domain name, which prevents at a minimum any modification to the registrant and registrar information by the Respondent, but does not affect the resolution of the domain name or the renewal of the domain name. (UDRP Rules, Section 1)” * The UDRP lock is different than EPP code clientTransferProhibited (which can allow change of registrant info). * There is an issue that some registrars may be imposing a UDRP lock that also locks the nameservers in place, which can prevent removal of allegedly infringing content etc. * Question: Any ideas on additional security measure we could be doing to improve this? Should we put in requirements around registrar and registry locks? * Question: Is this a place where people want to talk about multi-factor authentication? Answer: Not sure we want to include this in our policy. * Question: Is there a multi-factor piece of transfers that is possible? * We shouldn’t make assumptions about any one feature because they do have dependencies. * Multi-factor authentication is a security feature and if it is present it may help. We could note that it may or may not be present, and we could say something about it if it is present in transfers. We can mention that it adds to the security features if it is present. Different registrar models have different use cases for multi-factor authentication. * Should not make it too difficult for a registrar to do it if it wishes to use MFA. * In terms of scope and deliberation on additional security measures as they relate to transfer policy is in scope, although it might not be a consensus policy. Looking at the WG Guidelines there is nothing that would prevent the WG from providing implementation guidance. Perhaps there is language that is not consensus policy but could help the implementers. * What we could consider doing is for it to be allowed to have MFA on the TAC, but not on other actions. That would be in scope. * It’s important that we put boundaries on either side of this – can’t make it too easy to transfer a domain name but also can’t make it too hard. * Steinar Grøtterød-TPR Member (At-Large) to Everyone (2:46 PM): <COMMENT> I am in favor or adding wording that describes a requirement for registrars to make access to their control panel in a secure way. Of importance is also the distribution of the TAC to the Registrant/DNH. I find it strange that 2FA is enabled for accessing a control panel and then the TAC is sent in unsecured way (email).<COMMENT> * Question: Should we brainstorm a list of security measures? * Shouldn’t be prescriptive on the mechanism. ACTION ITEM: WG members to contribute to a list of additional security measures and provide other comments/suggestions in the Google doc for Additional Security Measures Working Document [docs.google.com]<https://urldefense.com/v3/__https:/docs.google.com/document/d/1q7xaJuxi50Q6…>. 4. AOB (5 minutes) * Next meeting: In two weeks on Tuesday, 9 November 2021 at 16:00 UTC (no meeting next week).

1 0

Notes and action items - TPR WG Meeting #23 - 26 Oct 2021
by Julie Hedlund Oct. 26, 2021

Oct. 26, 2021

Dear TPR WG Members, Please find below the notes and action items from today’s call. The next TPR WG meeting will be in two weeks on Tuesday, 09 November at 16:00 UTC. Best regards, Emily, Julie, Berry, and Caitlin Action Items 1. ACTION ITEM: WG members to contribute to a list of additional security measures and provide other comments/suggestions in the Google doc for Additional Security Measures Working Document<https://docs.google.com/document/d/1q7xaJuxi50Q6TDD26H92P6wOfZ8luap1wdWOtIg…>. Transfer Policy Review Phase 1 - Meeting #23 Tuesday 26 October 2021 at 17:30 UTC 1. Chair Update 2. About the PDP and Status Update (20 minutes) -- Slides attached * About the Transfer Policy: “ICANN consensus policy governing the procedure and requirements for registrants to transfer their domain names from one registrar to another.” * Formerly called the Inter‐Registrar Transfer Policy (IRTP) * Went into effect in November 2004 * GNSO reviewed the policy once before, shortly after implementation * Mission and Scope: PDP to conduct a holistic review of the Transfer Policy and determine if changes to the policy are needed to improve the ease, security, and efficacy of inter-registrar and inter-registrant transfers. * Conducted in 2 Phases under a single Charter<https://community.icann.org/display/TPRPDP/2.%2BWG%2BCharter> <https://community.icann.org/display/TPRPDP/2.%2BWG%2BCharter> & covering 8 topics. * PDP began Phase 1(a) in May 2021: * Phase 1(a) Topics: Forms of Authorization and AuthInfo Codes * The working group has now conducted initial deliberations on each of the Phase 1(a) topics and has begun to develop “candidate recommendations” and draft responses to charter questions. * While members and alternates are limited to representatives designated by SO/AC/SG/Cs, anyone can sign up to observe. * Topics: * AuthInfo Code Management * Gaining & Losing Registrar Form of Authorization (FOA) * FOA: Further Work Needed * EPDP included the workaround from the Temporary Specification in its recommendations, which were adopted by the ICANN Board. * Registrars identified challenges in ICANN org’s position that a Gaining Registrar is required to send a Gaining FOA where the email address “is available”, as there is no guarantee that the email goes directly to the registrant. * ICANN Board passed a resolution to defer contractual compliance enforcement of the Gaining FOA requirement pending further work in this area. * Contracted Party House Tech Ops Subcommittee has developed a proposal for a proposed transfer process. * Status: Potential Recommendations Under Consideration * Eliminate requirement for the Gaining Registrar to send the Gaining FOA and obtain consent from the Registered Name Holder before it may proceed with the transfer. * Eliminate requirement for the Losing Registrar to send the Losing FOA to the Registered Name Holder. * New notifications from the Losing Registrar to the Registered Name Holder when key changes are made to the account, some mandatory for the Losing Registrar to send, others optional. * Additional security for the AuthInfo Code, which the group is recommending be called the “Transfer Authorization Code” (TAC). Highlights: * ➔ Minimum requirements for TAC syntax/complexity, adherence to requirements confirmed by registry * ➔ Losing Registrar generates TAC upon request * ➔ TAC may only be used once * ➔ TAC is valid for a limited period of time (Time to Live) * ➔ Registry must securely store the TAC using a one-way hash that protects the TAC from disclosure * After the WG has reviewed the elements relating to single transfers, the WG will consider issues relating to bulk transfers. 3. Deliberations on Additional Security Measures (60 minutes) -- see: Additional Security Measures working document [docs.google.com]<https://urldefense.com/v3/__https:/docs.google.com/document/d/1q7xaJuxi50Q6…> Overview: * Staff and leadership developed a chart of an overview of inter-registrar transfer locks following last week’s discussion. * To help everyone understand what locks we are talking about. * Where we are unsure of the origin of a lock staff has inserted an asterisk (*). * Looking for feedback to make sure this is complete and accurate. Discussion: * A lot of registrars apply locks by default to protect against unauthorized transfers. * Not all domain locking is an additional security measure – whether it prevents hijacking depends on good account security – it is a dependency. If you lose control of the account it doesn’t matter if there is a lock or not. Need to capture these details. * The key is if we say that there is a mandatory lock and if someone gets ahold of someone’s account, it doesn’t matter since it can’t be transferred for 60 days. It becomes a more difficult hack if you have to hack both the registrar and registry accounts. * The concern with these stated security features is that there is a relationship between them – we need to capture and recognize that. Challenging to talk about them in isolation. * Question: What do the asterisks mean? Answer: It denotes uncertainty on the staff support side as to the origin of a lock – indicating that the origin is a guess. * First row: If this lock that many registrars do upon creation: the charter question a6 is whether this should be mandatory or just allowed as it is today. Leaning towards keeping it optional, but focusing on trying to keep it as consistent as possible across registrars. * Is there an opportunity to get more information about the impact/concerns relating to inconsistency of application of locks? * The charter question being specific to this first row – seems that we have answered that, but we need to resolve the 60-day creation. * “Lock means a set of measures that a registrar applies to a domain name, which prevents at a minimum any modification to the registrant and registrar information by the Respondent, but does not affect the resolution of the domain name or the renewal of the domain name. (UDRP Rules, Section 1)” * The UDRP lock is different than EPP code clientTransferProhibited (which can allow change of registrant info). * There is an issue that some registrars may be imposing a UDRP lock that also locks the nameservers in place, which can prevent removal of allegedly infringing content etc. * Question: Any ideas on additional security measure we could be doing to improve this? Should we put in requirements around registrar and registry locks? * Question: Is this a place where people want to talk about multi-factor authentication? Answer: Not sure we want to include this in our policy. * Question: Is there a multi-factor piece of transfers that is possible? * We shouldn’t make assumptions about any one feature because they do have dependencies. * Multi-factor authentication is a security feature and if it is present it may help. We could note that it may or may not be present, and we could say something about it if it is present in transfers. We can mention that it adds to the security features if it is present. Different registrar models have different use cases for multi-factor authentication. * Should not make it too difficult for a registrar to do it if it wishes to use MFA. * In terms of scope and deliberation on additional security measures as they relate to transfer policy is in scope, although it might not be a consensus policy. Looking at the WG Guidelines there is nothing that would prevent the WG from providing implementation guidance. Perhaps there is language that is not consensus policy but could help the implementers. * What we could consider doing is for it to be allowed to have MFA on the TAC, but not on other actions. That would be in scope. * It’s important that we put boundaries on either side of this – can’t make it too easy to transfer a domain name but also can’t make it too hard. * Steinar Grøtterød-TPR Member (At-Large) to Everyone (2:46 PM): <COMMENT> I am in favor or adding wording that describes a requirement for registrars to make access to their control panel in a secure way. Of importance is also the distribution of the TAC to the Registrant/DNH. I find it strange that 2FA is enabled for accessing a control panel and then the TAC is sent in unsecured way (email).<COMMENT> * Question: Should we brainstorm a list of security measures? * Shouldn’t be prescriptive on the mechanism. ACTION ITEM: WG members to contribute to a list of additional security measures and provide other comments/suggestions in the Google doc for Additional Security Measures Working Document<https://docs.google.com/document/d/1q7xaJuxi50Q6TDD26H92P6wOfZ8luap1wdWOtIg…>. 4. AOB (5 minutes) * Next meeting: In two weeks on Tuesday, 9 November 2021 at 16:00 UTC (no meeting next week).

1 0

Agenda for TRP ICANN72 session on Tuesday 26 October 2021 at 17:30 UTC
by Emily Barabas Oct. 25, 2021

Oct. 25, 2021

Dear Working Group members, Please find below the agenda for the TPR session during ICANN72, scheduled to take place tomorrow, 26 October 2021 at 17:30 UTC. To support discussion under agenda item 3, staff has prepared a draft table providing an overview of different types of inter-registrar transfer locks for further input from the group, which is now included on pages 1-3 of the Additional Security Measures working document<https://docs.google.com/document/d/1q7xaJuxi50Q6TDD26H92P6wOfZ8luap1wdWOtIg…>. Please review this table before the session to help prepare for the discussion. Kind regards, Julie, Caitlin, Berry, and Emily Transfer Policy Review Phase 1 – ICANN72 session Proposed Agenda Tuesday 26 October 2021 at 17:30 UTC 1. Chair Welcome (5 minutes) 2. About the PDP and Status Update (20 minutes) * Slides attached 1. Deliberations on Additional Security Measures (60 minutes) * Additional Security Measures working document<https://docs.google.com/document/d/1q7xaJuxi50Q6TDD26H92P6wOfZ8luap1wdWOtIg…> 4. AOB (5 minutes) * Next meeting: Tuesday, 9 November 2021 at 16:00 UTC

1 0

Notes and action items - TPR WG Meeting #22 - 19 Oct 2021
by Julie Hedlund Oct. 21, 2021

Oct. 21, 2021

Dear TPR WG Members, Please find below the notes and action items from today’s call. The next TPR WG meeting will be Tuesday, 26 October at 17:30 UTC. Best regards, Emily, Julie, Berry, and Caitlin Action Items 1. WG members to review the attached revised slides for the ICANN72 session, in particular the updated the definition on slide 8 based on the discussion on the mailing list, as well as slide 12 with the potential recommendations. Transfer Policy Review Phase 1 - Meeting #22 Tuesday 19 October 2021 at 16:00 UTC 1. Roll Call & SOI Updates (5 minutes): No updates provided. 2. Welcome & Chair updates (5 minutes) * ICANN72 meeting next week on Tuesday, 26 October at 17:30. * Will send around revised slides. * WG member updates: No updates provided. 3. Deliberations on Additional Security Measures (60 minutes) – See: Additional Security Measures Working Document<https://docs.google.com/document/d/1q7xaJuxi50Q6TDD26H92P6wOfZ8luap1wdWOtIg…> Overview: * Kind of a broad topic, with a focus on locking. * How to make the TAC a more consistent standard. * Locking – mandatory or suggested; if allowed what and how. * Some registrars impose a 60-day lock and some don’t, and some do something in between. * Trying to get something that is consistent. Charter Question: a6) Survey respondents noted that mandatory domain name locking is an additional security enhancement to prevent domain name hijacking and improper domain name transfers. The Transfer Policy does not currently require mandatory domain name locking; it allows a registrar to NACK an inter-registrar transfer if the inter-registrar transfer was requested within 60 days of the domain name’s creation date as shown in the registry RDDS record for the domain name or if the domain name is within 60 days after being transferred. Is mandatory domain name locking an additional requirement the Working Group believes should be added to the Transfer Policy? Discussion: * Question: Are we dealing with locking in Phase 1 or Phase 2? Answer: We may bring some Phase 2 items into Phase 1. If we get into a certain level of detail we may hold off. Let’s open up the discussion and see where it goes. * Context behind the question about what is in Phase 1 and Phase 2: The Additional Security Measures document is asking if domain name locking should be mandatory. In Phase 2 we also consider reasons for NACKing. The Phase 1 question is a result of survey input. * These things are linked, so it’s difficult to see how we can discuss this in a limited context. Do want to make sure that this issue receives its due addition. * It is open for discussion here and if people think we are getting to detailed we can pull back. * We need to look at all of the different reasons for domains to be locked; we might want to keep some and take others away. * Question: What would be the purpose of a mandatory lock? Is it to prevent that a domain name is transferred multiple times – against an attack? Answer: That is one reason to have the lock, as the charter question notes “to prevent domain name hijacking and improper domain name transfers.” * Suggest that the first order of business is to look at what the current policy says. It currently isn’t mandatory. Then we should consider whether they should be mandatory and have some consistency. * Also consider other questions, such as whether or not there is anything else that needs to happen, who has control, what is the timing? * Question: Do we have the numbers for domain names that were hacked and were pushed from registrars to others? Answer: Don’t think we have that specific data, but ICANN Compliance can check. * Looking back in time, this lock for 60-days was part of IRTP Part B or C. It would mitigate the hops to multiple registrars. The intent of the lock for 60 days was somewhat watered down or lessened. You had the ability to opt out of the lock, which causes confusion in the marketplace. * Maybe we should start with whether post-creation registration locks should be mandatory. Have heard from registrars that this lock is at the behest of registries, but not sure that is the case. Would like to know more about the policy rationale for this particular kind of lock. * We should think about recommendations for how we can obtain the data to help inform a review of the policy, since we don’t have this level of specific data now. * RegistryLock is a service that has to be approved by ICANN as a RSEP (still so if I call correct). Locks set by the registrar must be changed by the sponsoring registrar. registry lock is very difficult to remove, requires passphrases etc, it's separate from the "Client Transfer Prohibited" EPP status which is applied to domains. * We should explicitly link the post-transfer-lock to the Dispute-Policy and make it mandatory for exactly this purpose. Giving a rationale does increase the acceptance. * We can look at the discussions around the last IRTP around the 60-day lock. * Another reason for low numbers of complaints – not all registrants know about ICANN or how to complain. So some unauthorized transfers are not being reported. * These unauthorized transfers do happen, although there aren’t many of them. Still, the impact is large. We should look at the impact. * The big concern is when it gets to 5 different registrars in 5 different countries, so the claw-back process is complicated. * Some of the pressure on registrars in clawing back these domain names could be ameliorated – if the actual registrant could invoke. We could consider who should be initiating the different processes. * When we are talking about the claw-back, what are we talking about? It could be getting certain assurances from the registrant – perhaps creating a type of form for registrants, whether mandatory or not. To put the registrar at ease to make this move faster and improve the coordination between registrars. * The main point of this charter question is whether there should be a required lock on a transfer. Specifically, “Is mandatory domain name locking [on a create or transfer] an additional requirement the Working Group believes should be added to the Transfer Policy?” We aren’t talking about a Registry Lock, but a client lock by registrars. * The lock after registration and after transfer are two different things and should be treated differently. Identifying what those differences are is important. * The issue for many registrants is not whether locks should be mandatory or not, it is the inconsistent application. It should be consistent or the registrar’s policy should be transfer. * Understanding of the current policy is that registrars MAY deny a transfer if a domain name has been transferred in 60 days. Registrars have the discretion – and the charter question is asking if this lock instead should be mandatory. There are certain instances where the registrar MUST NACK the transfer, such as in UDRP cases. * Verisign prevents domain names from being transferred for 60 days after being created as part of our system. We don’t get complaints from registrars during this locking period. Can’t speak for other registries. * Good to know where the 60-day creation lock came from. * How do we standardize on the various options with that discretion? * If there is text somewhere else that prevents a transfer we should look into it. Not that we would change that if it’s not policy. * It seems it was a legacy – there being systematic enforcement of restricting transfers for 60 days post creation. * Seems that some WG members agree that the lock should not be mandatory, but discretionary. Questions from the Transfer Policy Status Report Survey: Q7) What methods do you use to mitigate domain name hijacking outside of the IRTP framework? * We’ve kind of talked around this. Maybe a registrar has a reason to lock this. * Are there a finite number of scenarios? * If you want to have good security you have to make sure everything is locked at the account level – start with the basics (the account) and that is something only the registrar can do. * One of our outcomes is not only determining whether or not a lock should be mandatory or optional, but also to make sure we are using the proper or precise term. * Homework: Start to review the different EPP status codes and when we are talking about a lock – what part of the EPP status codes are being used. Are there opportunities to make it more precise? * Can’t always see if there is a lock. Q13) Do you lock domains by default upon registration of a name? Q21) What do you think the ideal transfer process should look like from a policy and a technical perspective? – Seems that we’ve covered these questions. 4. Review: Summary of “Potential Recommendations Under Consideration” to be presented to the community during ICANN72 session (15 minutes) -- See attached revised slides. ACTION ITEM: WG members to review the attached revised slides for the ICANN72 session, in particular the updated the definition on slide 8 based on the discussion on the mailing list, as well as slide 12 with the potential recommendations. 5. AOB (5 minutes): ICANN72 session: Tuesday, 26 October 2021 at 17:30 UTC

2 1

Post Call | Transfer Policy Review PDP WG | Tuesday, 19 October 2021
by Julie Bisland Oct. 19, 2021

Oct. 19, 2021

Dear all, All recordings for the Transfer Policy Review PDP WG call held on Tuesday, 19 October 2021 at 16:00 UTC can be found on the agenda wiki page <https://community.icann.org/x/MgA_Cg> (attendance included) and the GNSO Master calendar [gnso.icann.org]<https://urldefense.com/v3/__https:/gnso.icann.org/en/group-activities/calen…>. These include: * Attendance (please let me know if your name has been left off the attendance list) * Audio recording * Zoom chat archive * Zoom recording (including audio, visual, rough transcript) * Transcript 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, Julie

1 0

Meeting Invitation | Transfer Policy Review PDP WG call | Tuesday, 09 November 2021 at 16:00 UTC
by Julie Bisland Oct. 19, 2021

Oct. 19, 2021

Reminder: The next call will be during ICANN72, Tuesday, 26 October at 10:30-12:00 local time (17:30 UTC). The zoom URL will be posted here<https://72.schedule.icann.org/meetings/arGuTDNFKAgHQCgpE> shortly before the meeting. Be sure you have registered! Below is the next call taking place after the ICANN72 meeting. Dear all, The next Transfer Policy Review PDP WG call is scheduled for Tuesday, 09 November 2021 at 16:00 UTC for 90 minutes. Zoom Room Information: Main Zoom Webinar link: https://icann.zoom.us/j/95363727469?pwd=N3A3OWFSaTlUME9wZzlGajk5VUI3QT09 [icann.zoom.us]<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 [icann.zoom.us]<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/dwiHCg * Check your time zone: https://tinyurl.com/4bmm2fpp ONLY FOR MEMBERS & ALTERNATES: * Please join via the Main Zoom Webinar link above and staff will promote you to panelist. * Chat: Members (and alternates replacing members), please select Everyone so everyone can see and so it’s captured afterwards. * Alternate replacement confirmations – For tracking alternate replacements, use the google form [docs.google.com]<https://urldefense.com/v3/__https:/docs.google.com/forms/d/e/1FAIpQLScXP3-H…> to communicate the replacement (alternate) and the duration. This information 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 THREE Zs (zzz) before your name and add, in parentheses (your affiliation - alternate) after your name. To rename in Zoom, hover over your name and click ‘rename’. * 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

**REMINDER TO REGISTER** ICANN72 GNSO Sessions - How to Get Organized / Remote Participation Details
by Julie Bisland Oct. 19, 2021

Oct. 19, 2021

Dear all, ICANN72 is right around the corner! This email provides some information to help you prepare and organize. Please note: You will need to register for ICANN72 to access the meeting schedule. Mandatory Registration for ICANN72 * Sign into your ICANN Account, or create an account here [account.icann.org]<https://urldefense.com/v3/__https:/account.icann.org/login__;!!PtGJab4!tF4x…>. * Register for ICANN72 by selecting Meeting Registration and click on the ICANN72 Registration link. Click here [gnso.icann.org]<https://urldefense.com/v3/__https:/gnso.icann.org/sites/default/files/polic…> for detailed instructions. Access the ICANN72 Schedule * ICANN72 schedule: https://72.schedule.icann.org/ [72.schedule.icann.org]<https://urldefense.com/v3/__https:/72.schedule.icann.org/__;!!PtGJab4!tF4xw…> For security purposes, participation links will be posted 24-hours prior to the session start times. * ICANN72 GNSO Sessions have been grouped on the ICANN72 GNSO wiki page<https://community.icann.org/x/CAFmCg>. Create your own schedule: * The ICANN Meeting website allows you to download all GNSO-related meetings to your inbox calendar in one go. For detailed instructions on how to create your personalized ICANN72 schedule and import your schedule to your calendar, click here [gnso.icann.org]<https://urldefense.com/v3/__https:/gnso.icann.org/sites/default/files/polic…>. Review the Participation Tools and update Zoom * All sessions will use Zoom rooms. Access details are available 24hrs prior on the ICANN72 Meeting Schedule [72.schedule.icann.org]<https://urldefense.com/v3/__https:/72.schedule.icann.org/__;!!PtGJab4!tF4xw…>. * Visit the Participation Tools page [72.schedule.icann.org]<https://urldefense.com/v3/__https:/72.schedule.icann.org/participation-tool…> for links to download the latest version of Zoom for access to the ICANN72 sessions. * Please see the ICANN Meeting Virtual Participation How-To Guide [72.schedule.icann.org]<https://urldefense.com/v3/__https:/72.schedule.icann.org/attend*:*:text=vir…> for more information on how to get the most out of the virtual meeting tools. Links to Bookmark ICANN72 Meeting Schedule [72.schedule.icann.org]<https://urldefense.com/v3/__https:/72.schedule.icann.org/__;!!PtGJab4!tF4xw…> GNSO ICANN72 Wiki Page<https://community.icann.org/x/CAFmCg> GNSO Session agendas<https://community.icann.org/x/iIH8CQ> For all GNSO meeting-related queries (RP or others), please email us at: gnso-secs(a)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…>

1 0

**15-minute reminder** Meeting Invitation | Transfer Policy Review PDP WG call | Tuesday, 19 October 2021 at 16:00 UTC
by Julie Bisland Oct. 19, 2021

Oct. 19, 2021

**15-minute reminder** Dear all, The next Transfer Policy Review PDP WG call is scheduled for Tuesday, 19 October 2021 at 16:00 UTC for 90 minutes. Zoom Room Information: Main Zoom Webinar link: https://icann.zoom.us/j/95363727469?pwd=N3A3OWFSaTlUME9wZzlGajk5VUI3QT09 [icann.zoom.us]<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 [icann.zoom.us]<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/MgA_Cg * Check your time zone: https://tinyurl.com/yxztuddw [tinyurl.com]<https://urldefense.com/v3/__https:/tinyurl.com/yxztuddw__;!!PtGJab4!vd6uNmO…> ONLY FOR MEMBERS & ALTERNATES: * Please join via the Main Zoom Webinar link above and staff will promote you to panelist. * Chat: Members (and alternates replacing members), please select Everyone so everyone can see and so it’s captured afterwards. * Alternate replacement confirmations – For tracking alternate replacements, use the google form [docs.google.com]<https://urldefense.com/v3/__https:/docs.google.com/forms/d/e/1FAIpQLScXP3-H…> to communicate the replacement (alternate) and the duration. This information 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 THREE Zs (zzz) before your name and add, in parentheses (your affiliation - alternate) after your name. To rename in Zoom, hover over your name and click ‘rename’. * 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

**REMINDER** Meeting Invitation | Transfer Policy Review PDP WG call | Tuesday, 19 October 2021 at 16:00 UTC
by Julie Bisland Oct. 19, 2021

Oct. 19, 2021

Dear all, The next Transfer Policy Review PDP WG call is scheduled for Tuesday, 19 October 2021 at 16:00 UTC for 90 minutes. Zoom Room Information: Main Zoom Webinar link: https://icann.zoom.us/j/95363727469?pwd=N3A3OWFSaTlUME9wZzlGajk5VUI3QT09 [icann.zoom.us]<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 [icann.zoom.us]<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/MgA_Cg * Check your time zone: https://tinyurl.com/yxztuddw [tinyurl.com]<https://urldefense.com/v3/__https:/tinyurl.com/yxztuddw__;!!PtGJab4!vd6uNmO…> ONLY FOR MEMBERS & ALTERNATES: * Please join via the Main Zoom Webinar link above and staff will promote you to panelist. * Chat: Members (and alternates replacing members), please select Everyone so everyone can see and so it’s captured afterwards. * Alternate replacement confirmations – For tracking alternate replacements, use the google form [docs.google.com]<https://urldefense.com/v3/__https:/docs.google.com/forms/d/e/1FAIpQLScXP3-H…> to communicate the replacement (alternate) and the duration. This information 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 THREE Zs (zzz) before your name and add, in parentheses (your affiliation - alternate) after your name. To rename in Zoom, hover over your name and click ‘rename’. * 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

2 1

Re: [GNSO-TPR] Proposed agenda for meeting #22 on Tuesday 19 October 2021 at 16:00 UTC
by farzaneh badii Oct. 18, 2021

Oct. 18, 2021

Yes, please. Lets add the new definition. On Monday, October 18, 2021, Sarah Wyld <swyld(a)tucows.com> wrote: > Thanks, all! I’m happy to use the new definition, assuming the note at the > bottom of the slide will be updated to indicate the origin of it. No need > to hide that we’ve already accomplished something 😊 > > > > -- > > *Sarah Wyld*, CIPP/E > > > > Policy & Privacy Manager > > Pronouns: she/they > > > > swyld(a)tucows.com > > +1.416 535 0123 Ext. 1392 > > > > > > *From: *Emily Barabas <emily.barabas(a)icann.org> > *Sent: *October 18, 2021 3:15 AM > *To: *James Galvin <jgalvin(a)donuts.email>; Sarah Wyld <swyld(a)tucows.com> > *Cc: *gnso-tpr(a)icann.org > *Subject: *Re: [Ext] Re: [GNSO-TPR] Proposed agenda for meeting #22 on > Tuesday19 October2021 at 16:00 UTC > > > > Hi Jim and everyone, > > > > Thanks for the follow up. If the group prefers, we could use Jim’s new > proposed definition from the working document in slide 8 of the ICANN72 > deck. Here is the text Jim proposes: “A Transfer Authorization Code (TAC) > is a token created by the registrar of record and provided upon request to > the registrant or designated representative. The TAC is required to > transfer a domain name from one Registrar to another registrar and when > presented authorizes the transfer.” > > > > If there are any objections, please share them on list. > > > > Kind regards, > > Emily > > > > > > *From: *James Galvin <jgalvin(a)donuts.email> > *Date: *Sunday, 17 October 2021 at 23:08 > *To: *Sarah Wyld <swyld(a)tucows.com> > *Cc: *Emily Barabas <emily.barabas(a)icann.org>, "gnso-tpr(a)icann.org" < > gnso-tpr(a)icann.org> > *Subject: *[Ext] Re: [GNSO-TPR] Proposed agenda for meeting #22 on > Tuesday 19 October2021 at 16:00 UTC > > > > Thanks for calling this out Sarah. > > I wrote some new words for this definition expressly to deal with the > issue of the use of identify. It might have been in a comment. > > Emily, is that text still available? > > Thanks, > > Jim > > > > On 15 Oct 2021, at 9:24, Sarah Wyld wrote: > > Hi team > > > > Reviewed the ICANN72 pdf, have a comment. > > > > The page 8 definition of the AuthInfo code (“Unique code created by a > registrar on a per-domain basis to identify the registrant of the domain > name”) is not the definition we came up with, I think it’s pieces pulled > together from the current Transfer Policy. Can this be marked on this slide > as unofficial and not the long-term definition, with the source included, > and a note that updating this definition is part of our group’s work? I > just wouldn’t want this slide to lead anyone to think that this is our > current working definition, should be used in the long-term, etc. > > > > Thanks! > > > > -- > > *Sarah Wyld*, CIPP/E > > > > Policy & Privacy Manager > > Pronouns: she/they > > > > swyld(a)tucows.com > > +1.416 535 0123 Ext. 1392 > > > > > > *From: *Emily Barabas <emily.barabas(a)icann.org> > *Sent: *October 15, 2021 3:27 AM > *To: *gnso-tpr(a)icann.org > *Subject: *[GNSO-TPR] Proposed agenda for meeting #22 on Tuesday 19 > October2021 at 16:00 UTC > > > > Dear Working Group members, > > > > Please find below the proposed agenda for the meeting scheduled to take > place on Tuesday 19 October 2021 at 16:00 UTC. > > > > Kind regards, > > > > Julie, Caitlin, Berry, and Emily > > > > > > > > *Transfer Policy Review Phase 1 - Meeting #**22* > > *Proposed Agenda* > > > > > > Tuesday 19 October 2021 at 16:00 UTC > > 1. Roll Call & SOI Updates (5 minutes) > 2. Welcome & Chair updates (5 minutes) > 3. Deliberations on Additional Security Measures (60 minutes) > > > - Additional Security Measures working document [docs.google.com] > <https://urldefense.com/v3/__https:/docs.google.com/document/d/1q7xaJuxi50Q6…> > > · Review: Summary of “Potential Recommendations Under Consideration” to > be presented to the community during ICANN72 session (15 minutes) > > - See slide 12 of the attached deck > > 5. AOB (5 minutes) > > · ICANN72 session: Tuesday, 26 October 2021 at 17:30 UTC > > > > > > > > _______________________________________________ > GNSO-TPR mailing list > GNSO-TPR(a)icann.org > https://mm.icann.org/mailman/listinfo/gnso-tpr > > > -- Farzaneh

2 1

Re: [GNSO-TPR] Proposed agenda for meeting #22 on Tuesday 19 October2021 at 16:00 UTC
by James Galvin Oct. 18, 2021

Oct. 18, 2021

Thanks for calling this out Sarah. I wrote some new words for this definition expressly to deal with the issue of the use of identify. It might have been in a comment. Emily, is that text still available? Thanks, Jim On 15 Oct 2021, at 9:24, Sarah Wyld wrote: > Hi team > > Reviewed the ICANN72 pdf, have a comment. > > The page 8 definition of the AuthInfo code (“Unique code created by > a registrar on a per-domain basis to identify the registrant of the > domain name”) is not the definition we came up with, I think it’s > pieces pulled together from the current Transfer Policy. Can this be > marked on this slide as unofficial and not the long-term definition, > with the source included, and a note that updating this definition is > part of our group’s work? I just wouldn’t want this slide to lead > anyone to think that this is our current working definition, should be > used in the long-term, etc. > > Thanks! > > -- > Sarah Wyld, CIPP/E > > Policy & Privacy Manager > Pronouns: she/they > > swyld(a)tucows.com > +1.416 535 0123 Ext. 1392 > > > > From: Emily Barabas > Sent: October 15, 2021 3:27 AM > To: gnso-tpr(a)icann.org > Subject: [GNSO-TPR] Proposed agenda for meeting #22 on Tuesday 19 > October2021 at 16:00 UTC > > Dear Working Group members, > > Please find below the proposed agenda for the meeting scheduled to > take place on Tuesday 19 October 2021 at 16:00 UTC. > > Kind regards, > > Julie, Caitlin, Berry, and Emily > > > > Transfer Policy Review Phase 1 - Meeting #22 > Proposed Agenda > > > Tuesday 19 October 2021 at 16:00 UTC > 1. Roll Call & SOI Updates (5 minutes) > 2. Welcome & Chair updates (5 minutes) > 3. Deliberations on Additional Security Measures (60 minutes) > • Additional Security Measures working document > 4. Review: Summary of “Potential Recommendations Under > Consideration” to be presented to the community during ICANN72 > session (15 minutes) > • See slide 12 of the attached deck > 5. AOB (5 minutes) > • ICANN72 session: Tuesday, 26 October 2021 at 17:30 UTC > _______________________________________________ > GNSO-TPR mailing list > GNSO-TPR(a)icann.org > https://mm.icann.org/mailman/listinfo/gnso-tpr

3 3

Re: [GNSO-TPR] [Ext] RE: Proposed agenda for meeting #22 on Tuesday 19 October2021 at 16:00 UTC
by Emily Barabas Oct. 15, 2021

Oct. 15, 2021

Hi Sarah, Thanks for the comment. Unless anyone objects, we can certainly add a comment to that effect. Kind regards, Emily From: Sarah Wyld <swyld(a)tucows.com> Date: Friday, 15 October 2021 at 15:25 To: Emily Barabas <emily.barabas(a)icann.org>, "gnso-tpr(a)icann.org" <gnso-tpr(a)icann.org> Subject: [Ext] RE: [GNSO-TPR] Proposed agenda for meeting #22 on Tuesday 19 October2021 at 16:00 UTC Hi team Reviewed the ICANN72 pdf, have a comment. The page 8 definition of the AuthInfo code (“Unique code created by a registrar on a per-domain basis to identify the registrant of the domain name”) is not the definition we came up with, I think it’s pieces pulled together from the current Transfer Policy. Can this be marked on this slide as unofficial and not the long-term definition, with the source included, and a note that updating this definition is part of our group’s work? I just wouldn’t want this slide to lead anyone to think that this is our current working definition, should be used in the long-term, etc. Thanks! -- Sarah Wyld, CIPP/E Policy & Privacy Manager Pronouns: she/they swyld(a)tucows.com<mailto:swyld@tucows.com> +1.416 535 0123 Ext. 1392 [cid:image001.png@01D7C1DE.33B37B60] From: Emily Barabas<mailto:emily.barabas@icann.org> Sent: October 15, 2021 3:27 AM To: gnso-tpr(a)icann.org<mailto:gnso-tpr@icann.org> Subject: [GNSO-TPR] Proposed agenda for meeting #22 on Tuesday 19 October2021 at 16:00 UTC Dear Working Group members, Please find below the proposed agenda for the meeting scheduled to take place on Tuesday 19 October 2021 at 16:00 UTC. Kind regards, Julie, Caitlin, Berry, and Emily Transfer Policy Review Phase 1 - Meeting #22 Proposed Agenda Tuesday 19 October 2021 at 16:00 UTC 1. Roll Call & SOI Updates (5 minutes) 2. Welcome & Chair updates (5 minutes) 3. Deliberations on Additional Security Measures (60 minutes) * Additional Security Measures working document [docs.google.com]<https://urldefense.com/v3/__https:/docs.google.com/document/d/1q7xaJuxi50Q6…> 4. Review: Summary of “Potential Recommendations Under Consideration” to be presented to the community during ICANN72 session (15 minutes) * See slide 12 of the attached deck 5. AOB (5 minutes) * ICANN72 session: Tuesday, 26 October 2021 at 17:30 UTC

1 0

Proposed agenda for meeting #22 on Tuesday 19 October 2021 at 16:00 UTC
by Emily Barabas Oct. 15, 2021

Oct. 15, 2021

Dear Working Group members, Please find below the proposed agenda for the meeting scheduled to take place on Tuesday 19 October 2021 at 16:00 UTC. Kind regards, Julie, Caitlin, Berry, and Emily Transfer Policy Review Phase 1 - Meeting #22 Proposed Agenda Tuesday 19 October 2021 at 16:00 UTC 1. Roll Call & SOI Updates (5 minutes) 2. Welcome & Chair updates (5 minutes) 3. Deliberations on Additional Security Measures (60 minutes) * Additional Security Measures working document<https://docs.google.com/document/d/1q7xaJuxi50Q6TDD26H92P6wOfZ8luap1wdWOtIg…> 4. Review: Summary of “Potential Recommendations Under Consideration” to be presented to the community during ICANN72 session (15 minutes) * See slide 12 of the attached deck 5. AOB (5 minutes) * ICANN72 session: Tuesday, 26 October 2021 at 17:30 UTC

2 2

Notes and action items - TPR WG Meeting #21 - 12 Oct 2021
by Julie Hedlund Oct. 12, 2021

Oct. 12, 2021

Dear TPR WG Members, Please find below the notes and action items from today’s call. The next TPR WG meeting will be Tuesday, 19 October at 16:00 UTC. Best regards, Emily, Julie, Berry, and Caitlin Action Items 1. WG members should review the Gaining and Losing GOA working documents – including candidate recommendations for the Losing FOA and suggested changes to the Gaining FOA policy. See: Gaining FOA working document<https://docs.google.com/document/d/1QOCzbLh7w4hdijpAsg6_lybddr0nlsFDcWjdz5e…> and Losing FOA working document<https://docs.google.com/document/d/1wCUMe9ii6g05kUZ558IuUvJaS6K2t0GZJYvlfOy…>. 2. Charter Question b3 -- Staff to incorporate a recommendation to retain this policy with change from days to hours. 3. AuthInfo Code Candidate Recommendations: WG members to provide their input as suggestions in the AuthInfo Code Candidate Recommendations at: AuthInfo Codes working document [docs.google.com]<https://urldefense.com/v3/__https:/docs.google.com/document/d/1O9PAnxWFUuPo…>. 4. WG members to review and comment on the Additional Security Measures working document [docs.google.com]<https://urldefense.com/v3/__https:/docs.google.com/document/d/1q7xaJuxi50Q6…> in preparation for the discussion during the next WG meeting on 19 October. Transfer Policy Review Phase 1 - Meeting #21 Tuesday 12 October 2021 at 16:00 UTC 1. Roll Call & SOI Updates (5 minutes) - Jim Galvin will soon be occupying a new role: I have been selected to be SSAC’s liaison to the ICANN Board of Directors, a role that I will assume at the AGM. It won’t change my role on the WG as I will continue to represent the Registry Stakeholder Group. See: 2. Welcome & Chair updates (5 minutes) * The WG will meet at ICANN72 on Tuesday, 26 October at 10:30 local time. * Roger will provide an update on the WG’s work during the Policy Update webinar today, 12 October, at 20:00 UTC. * Look at the Gaining and Losing FOA working documents: Staff have added candidate recommendations. ACTION ITEM: WG members should review the Gaining and Losing GOA working documents – including candidate recommendations for the Losing FOA and suggested changes to the Gaining FOA policy. See: Gaining FOA working document<https://docs.google.com/document/d/1QOCzbLh7w4hdijpAsg6_lybddr0nlsFDcWjdz5e…> and Losing FOA working document<https://docs.google.com/document/d/1wCUMe9ii6g05kUZ558IuUvJaS6K2t0GZJYvlfOy…>. 3. Review of draft responses to charter questions and candidate recommendations for AuthInfo Codes – see end of document beginning on page 16 (60 minutes) at: AuthInfo Codes working document [docs.google.com]<https://urldefense.com/v3/__https:/docs.google.com/document/d/1O9PAnxWFUuPo…> Discussion: Charter Question b1) Is AuthInfo Code still a secure method for inter-registrar transfers? What evidence was used by the Working Group to make this determination? Candidate Recommendation 2: The Working Group recommends that the Transfer Authorization Code be defined as follows: “A Transfer Authorization Code (TAC) is a code created by a Registrar of Record to validate that a request to transfer a domain name in a generic top-level domain (gTLD) is submitted by the authorized person, which may be the RNH or another appropriate party. The individual demonstrates that they are the authorized person by providing the TAC. A TAC is required for a Registered Name Holder to transfer a domain name to be transferred from one Registrar to another.” * Question: Compliance concerns -- The term “authorized person” does not explicitly refer to the Registered Name Holder. Recommend replacing “authorized person” with “Registered Name Holder” to avoid ambiguity and arguments due to various interpretations. Concerns about the implementation of this and how it would add to security measures. Make more specific – unless we are having a positive response to the TAC, to make it more secure. Candidate Recommendation 6: [The Working Group recommends that the Registry notifies the Registrar of Record [and registrant] receive a notification after [number] failed attempts to enter the TAC. The Registrar of Record may subsequently also provide a notification to the registrant that these failed attempts have taken place. ICANN Org may change from time to time the number of failed attempts that trigger a notification.] OR [The Working Group recommends that after [number] failed attempts to enter the TAC, it is not possible to attempt a transfer for [period of time]. ICANN Org may change from time to time the number of failed attempts that trigger this result.]. * Question: Trying to understand what we are trying to achieve with Recommendation 6. Beyond the syntax what other check is going on here? There shouldn’t be any other reason for a TAC to fail. Answer: The goal should be that the correct syntax should be known to anyone. Trying to prevent a brute force attack. The syntax being right and it matching are two different things. This is when the syntax is right but it doesn’t match. The goal is to notify the registrar or record so it could notify the registrar. Question: So what Recommendation 6 refers to is the Gaining registrar. Want to acknowledge that Registries would need to talk to our team about a recommendation that the registrar can’t make transfers if they get it wrong. We’d then have to provide a process for undoing the lockdown. Answer: I don’t think we are looking for a lockdown, we are looking for a notification that someone has tried this X number of times. Question: Registries will have to discuss because this is a new notification. How would you like that notification sent? Need to specify that process. This would have to be automated, perhaps through a poll message. * Question: Has anyone encountered this? Do we have any data on brute force attack of the AuthInfo Code? Answer: Don’t know of any. This came from the recommendation that the transfer is immediate – this would be the last line of defense. Not just a brute force but perhaps also a systemic problem. * Many of these candidate recommendations came out of brainstorming of the small group. One of the questions was what are the methods to reduce brute force attacks. * Note that this are candidate recommendations – not even drafts. These are points that were pulled out of discussions on the charter questions. * Any additional protection is positive. * In the case of recommendation 6, this was framed as if there were no other restrictions, i.e. an immediate transfer, to provide protection against brute forcing. Wouldn’t apply if there was a NACK for example. Charter Question b2) The registrar is currently the authoritative holder of the AuthInfo Code. Should this be maintained, or should the registry be the authoritative AuthInfo Code holder? Why? Candidate Recommendation 7: The Working Group recommends that the registrar continue to own and generate the TAC. The Working Group further recommends that the TAC is only generated by the Registrar of Record upon request by the registrant. When the registrar provides the TAC to the registrant it should also provide information about when the TAC will expire. * Question: This could relate to bulk transfers. Are we addressing those? Answer: Yes. As a bulk operation that may not work, but let’s focus on individual transfers. We may have to clarify for bulk transfers. * For all of these recommendations the plan is just to get something on paper, but there will be further opportunities to revise them. We are trying to see where there is agreement and where more discussion is needed. Candidate Recommendation 8: The Working Group recommends that when the registry receives the TAC, the registry must securely store the TAC using a one-way hash that protects the TAC from disclosure by using a secure password-hashing function (for example, bcrypt). * Rather than being specific. WG members should suggest language. * Question: This seems to be a pretty prescriptive requirement to put on a registry. Is this really what we want? Candidate Recommendation 9: The Working Group confirms the following provision of Appendix G: Supplemental Procedures to the Transfer Policy contained in the Temporary Specification for gTLD Registration Data: “4. Registry Operator MUST verify that the "AuthInfo" code provided by the Gaining Registrar is valid in order to accept an inter-registrar transfer request.” * Question: Does this mean there's a mechanism to validate the TAC other than the transfer? * There are two kinds of validation. There registry never actually knows what the TAC is in clear text. If an incumbent registrar is concerned that the TAC is not correct it just creates a new one and stores it. It is in plain text until the registry has it, but inside an encrypted tunnel. Charter Question b3) The Transfer Policy currently requires registrars to provide the AuthInfo Code to the registrant within five [calendar] days of a request. Is this an appropriate SLA for the registrar’s provision of the AuthInfo Code, or does it need to be updated? * No candidate recommendations on this. * WG could decide to have a recommendation that there are no changes to this policy. * Could say number of hours rather than number of days. ACTION ITEM: Staff to incorporate a recommendation to retain this policy with change from days to hours. Charter Question b4) The Transfer Policy does not currently require a standard Time to Live (TTL) for the AuthInfo Code. Should there be a standard Time To Live (TTL) for the AuthInfo Code? In other words, should the AuthInfo Code expire after a certain amount of time (hours, calendar days, etc.)? Candidate Recommendation 10: The Working Group recommends that the Transfer Policy include a standard maximum Time To Live (TTL) for the TAC of [14 days]. Candidate Recommendation 11: The Working Group recommends that the Transfer Policy include a standard minimum Time To Live (TTL) for the TAC of [period]. * This was more for registrars than registries – enforced by the registry. The idea was that there was a minimum. * Important that we have a way to cancel the TTL. If the sponsoring registrar sees a problem they can change the TAC. * Need to take a question back to registries – not certain that having registries enforce the TTL is the right model. What are we trying to achieve by having the registry enforce the TTL. Don’t we want to say that the TAC can only be used once – single use. Like more discussion on this. * Should definitely get a recommendation around one-time use TAC. * The best technical solution to make sure that there aren’t registrar errors would be at least the registry verifies that the TAC is not older than 14 days – they are verifying the TTL. * Do we have some statistics from ccTLDs depending only on TAC re TTL? * Good to at least have a minimum. * What does it mean if the registry is involved in this process? Suggest that the minimum level doesn’t seem to provide protection against a registrar being a bad actor, and could cause more issues. * Minimum causes more problems than it solves. * If you are going to have SLAs then you have to promise the registrant X amount of time to do the transfer. Could have a minimum enforced TTL on the registrar (by ICANN Compliance) not enforced by the registry. * Clearer language makes it easier for Compliance to enforce it. * This would be solved if we had a standard TTL, rather than a minimum (or maximum) TTL. Just say 14 days. * Unless people want to argue for a minimum we seem to agree to drop Candidate Recommendation 11. * If we say in a policy that it has to be 14 days then blanking/nulling it would go against that policy. * The registrar should be able to null or reset a TAC even during the TTL period. * The only real benefit of a minimum is it gives you a reactive mechanism for getting at bad actors. * Seems to be agreement for a standard for 14 days, rather than maximum or minimum and for the registrar to be able to nullify the TAC during the TTL. * You want to make sure there is time for manual steps to happen. Maximum TTL has the advantage that it gets at a security consideration – a way at getting at registrars who are not providing a basic level of security service. b5) Should the ability for registrants to request AuthInfo Codes in bulk be streamlined and codified? If so, should additional security measures be considered? * [For the Working Group to confirm: This question will be addressed when bulk transfers are discussed more generally in Phase 2. ACTION ITEM: WG members to provide their input as suggestions in the AuthInfo Code Candidate Recommendations at: AuthInfo Codes working document [docs.google.com]<https://urldefense.com/v3/__https:/docs.google.com/document/d/1O9PAnxWFUuPo…>. 4. Deliberations on Additional Security Measures (15 minutes, time permitting) – see: Additional Security Measures working document [docs.google.com]<https://urldefense.com/v3/__https:/docs.google.com/document/d/1q7xaJuxi50Q6…> ACTION ITEM: WG members to review and comment on the Additional Security Measures working document [docs.google.com]<https://urldefense.com/v3/__https:/docs.google.com/document/d/1q7xaJuxi50Q6…> in preparation for the discussion during the next WG meeting on 19 October. This is the related charter question: “a6) Survey respondents noted that mandatory domain name locking is an additional security enhancement to prevent domain name hijacking and improper domain name transfers. The Transfer Policy does not currently require mandatory domain name locking; it allows a registrar to NACK an inter-registrar transfer if the inter-registrar transfer was requested within 60 days of the domain name’s creation date as shown in the registry RDDS record for the domain name or if the domain name is within 60 days after being transferred. Is mandatory domain name locking an additional requirement the Working Group believes should be added to the Transfer Policy?” 5. AOB (5 minutes) * Next meeting: 19 October 2021 @ 16.00 UTC

1 0

Post Call | Transfer Policy Review PDP WG | Tuesday, 12 October 2021
by Julie Bisland Oct. 12, 2021

Oct. 12, 2021

Dear all, All recordings for the Transfer Policy Review PDP WG call held on Tuesday, 12 October 2021 at 16:00 UTC can be found on the agenda wiki page <https://community.icann.org/x/LgA_Cg> (attendance included) and the GNSO Master calendar [gnso.icann.org]<https://urldefense.com/v3/__https:/gnso.icann.org/en/group-activities/calen…>. These include: * Attendance (please let me know if your name has been left off the attendance list) * Audio recording * Zoom chat archive * Zoom recording (including audio, visual, rough transcript) * Transcript 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, Julie

1 0

Meeting Invitation | Transfer Policy Review PDP WG call | Tuesday, 19 October 2021 at 16:00 UTC
by Julie Bisland Oct. 12, 2021

Oct. 12, 2021

Dear all, The next Transfer Policy Review PDP WG call is scheduled for Tuesday, 19 October 2021 at 16:00 UTC for 90 minutes. Zoom Room Information: Main Zoom Webinar link: https://icann.zoom.us/j/95363727469?pwd=N3A3OWFSaTlUME9wZzlGajk5VUI3QT09 [icann.zoom.us]<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 [icann.zoom.us]<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/MgA_Cg * Check your time zone: https://tinyurl.com/yxztuddw ONLY FOR MEMBERS & ALTERNATES: * Please join via the Main Zoom Webinar link above and staff will promote you to panelist. * Chat: Members (and alternates replacing members), please select Everyone so everyone can see and so it’s captured afterwards. * Alternate replacement confirmations – For tracking alternate replacements, use the google form [docs.google.com]<https://urldefense.com/v3/__https:/docs.google.com/forms/d/e/1FAIpQLScXP3-H…> to communicate the replacement (alternate) and the duration. This information 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 THREE Zs (zzz) before your name and add, in parentheses (your affiliation - alternate) after your name. To rename in Zoom, hover over your name and click ‘rename’. * 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

**Starting in 15 minutes** Meeting Invitation | Transfer Policy Review PDP WG call | Tuesday, 12 October 2021 at 16:00 UTC
by Julie Bisland Oct. 12, 2021

Oct. 12, 2021

**Starting in 15 minutes** Dear all, The next Transfer Policy Review PDP WG call is scheduled for Tuesday, 12 October 2021 at 16:00 UTC for 90 minutes. Zoom Room Information: Main Zoom Webinar link: https://icann.zoom.us/j/95363727469?pwd=N3A3OWFSaTlUME9wZzlGajk5VUI3QT09 [icann.zoom.us]<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 [icann.zoom.us]<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/LgA_Cg * Check your time zone: https://tinyurl.com/5znrvb37 [tinyurl.com]<https://urldefense.com/v3/__https:/tinyurl.com/5znrvb37__;!!PtGJab4!rByaHjr…> ONLY FOR MEMBERS & ALTERNATES: * Please join via the Main Zoom Webinar link above and staff will promote you to panelist. * Chat: Members (and alternates replacing members), please select Everyone so everyone can see and so it’s captured afterwards. * Alternate replacement confirmations – For tracking alternate replacements, use the google form [docs.google.com]<https://urldefense.com/v3/__https:/docs.google.com/forms/d/e/1FAIpQLScXP3-H…> to communicate the replacement (alternate) and the duration. This information 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 THREE Zs (zzz) before your name and add, in parentheses (your affiliation - alternate) after your name. To rename in Zoom, hover over your name and click ‘rename’. * 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

**REMINDER** Meeting Invitation | Transfer Policy Review PDP WG call | Tuesday, 12 October 2021 at 16:00 UTC
by Julie Bisland Oct. 11, 2021

Oct. 11, 2021

Dear all, The next Transfer Policy Review PDP WG call is scheduled for Tuesday, 12 October 2021 at 16:00 UTC for 90 minutes. Zoom Room Information: Main Zoom Webinar link: https://icann.zoom.us/j/95363727469?pwd=N3A3OWFSaTlUME9wZzlGajk5VUI3QT09 [icann.zoom.us]<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 [icann.zoom.us]<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/LgA_Cg * Check your time zone: https://tinyurl.com/5znrvb37 [tinyurl.com]<https://urldefense.com/v3/__https:/tinyurl.com/5znrvb37__;!!PtGJab4!rByaHjr…> ONLY FOR MEMBERS & ALTERNATES: * Please join via the Main Zoom Webinar link above and staff will promote you to panelist. * Chat: Members (and alternates replacing members), please select Everyone so everyone can see and so it’s captured afterwards. * Alternate replacement confirmations – For tracking alternate replacements, use the google form [docs.google.com]<https://urldefense.com/v3/__https:/docs.google.com/forms/d/e/1FAIpQLScXP3-H…> to communicate the replacement (alternate) and the duration. This information 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 THREE Zs (zzz) before your name and add, in parentheses (your affiliation - alternate) after your name. To rename in Zoom, hover over your name and click ‘rename’. * 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

Proposed agenda for meeting #21 on Tuesday 12 October 2021 at 16:00 UTC
by Emily Barabas Oct. 10, 2021

Oct. 10, 2021

Dear Working Group members, Please find below the proposed agenda for the meeting scheduled to take place on Tuesday 12 October 2021 at 16:00 UTC. Kind regards, Julie, Caitlin, Berry, and Emily Transfer Policy Review Phase 1 - Meeting #21 Proposed Agenda Tuesday 12 October 2021 at 16:00 UTC 1. Roll Call & SOI Updates (5 minutes) 2. Welcome & Chair updates (5 minutes) 3. Review of draft responses to charter questions and candidate recommendations for AuthInfo Codes – see end of document beginning on page 16 (60 minutes) * AuthInfo Codes working document<https://docs.google.com/document/d/1O9PAnxWFUuPofLQCWIQXz8lT7KEj1HgH3b_obh0…> 1. Deliberations on Additional Security Measures (15 minutes, time permitting) * Additional Security Measures working document<https://docs.google.com/document/d/1q7xaJuxi50Q6TDD26H92P6wOfZ8luap1wdWOtIg…> 5. AOB (5 minutes) * Next meeting: 19 October 2021 @ 16.00 UTC

1 0

Please read | ICANN72 GNSO Policy Briefing and ICANN72 Policy Outlook Report Available for Download
by Terri Agnew Oct. 6, 2021

Oct. 6, 2021

Dear All, Please find both the GNSO Policy Briefing and Policy Outlook Report links for ICANN72. GNSO Policy Briefing: https://go.icann.org/gnsobriefing [go.icann.org]<https://urldefense.com/v3/__https:/go.icann.org/gnsobriefing__;!!PtGJab4!t9…> ICANN72 Policy Outlook Report: https://go.icann.org/outlook72 [go.icann.org]<https://urldefense.com/v3/__https:/go.icann.org/outlook72__;!!PtGJab4!t9j8H…> Thank you. With kind regards, Terri --- Terri Agnew Policy Operations Specialist (GNSO) Internet Corporation for Assigned Names and Numbers (ICANN) Skype ID: terri.agnew.icann 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…>

1 0

Notes and action items - TPR WG Meeting #20 - 5 Oct 2021
by Caitlin Tubergen Oct. 5, 2021

Oct. 5, 2021

Dear TPR WG Members, Please find below the notes and action items from today’s call. The next TPR WG meeting will be Tuesday, 12 October at 16:00 UTC. Best regards, Emily, Julie, Berry, and Caitlin Action Items 1. Working Group Members to review the table on p. 14 of the Gaining FOA working document<https://docs.google.com/document/d/1QOCzbLh7w4hdijpAsg6_lybddr0nlsFDcWjdz5e…>, which sets out the purposes/functions of the pre-GDPR Gaining FOA. The purposes/functions are listed in an effort to ensure that if the Gaining FOA is ultimately eliminated, any important purpose/function is covered elsewhere or in an updated step of the transfer process by Monday, 11 October. 2. TPR Support Staff to review the transcript from today's call and document the rationales described for why the Gaining FOA may be technically feasible, but it is NOT commercially feasible or legally authorized under the current data protection landscape. 3. Working Group Members to review the TAC Candidate Recommendations, beginning on p. 17 of the Auth-Info Code working document<https://docs.google.com/document/d/1O9PAnxWFUuPofLQCWIQXz8lT7KEj1HgH3b_obh0…>, and provide comments, concerns, and proposed edits, etc., by Monday, 11 October. Transfer Policy Review Phase 1 - Meeting #20 Tuesday 5 October 2021 at 16:00 UTC 1. Roll Call & SOI Updates (5 minutes) * Tucows has recently purchased the registry platform of another company. Sarah will continue to represent the RrSG but wanted to note this. * Thomas Keller has left the RrSG, and accordingly, has left the WG. 2. Welcome & Chair updates (5 minutes) 3. Upcoming meeting schedule and ICANN72 (5 minutes) * TPR session will be Tuesday, 26 October at 10:30-12:00 UTC. This will function as a normal WG meeting. * The Tuesday, 2 November meeting immediately following ICANN72 will be cancelled. 4. Gaining FOA (40 minutes) · Gaining FOA working document [docs.google.com]<https://urldefense.com/v3/__https:/docs.google.com/document/d/1QOCzbLh7w4hd…> · In reviewing the Gaining FOA, support staff has outlined the functions of the Gaining FOA to see if the functions and security measures are covered. * 1. Provides a verification step that is distinct from any processes with the Losing Registrar. * The Gaining and Losing FOA were methods of how to transfer the domain name. These were not really a verification step. With the verification of the TAC, this would be covered. * If the Gaining FOA is removed and the team is relying on stronger security features, wonder if now is a good time to discuss what some of those additional security features may be. For example, when thinking about the entire transfer process, is it worth giving initial indications about what additional security measures could be explored in the context of the Gaining FOA being removed. With respect to Charter question a3, the Temp Spec references other secure methods – is this something that should be explored here? * The team already put in details regarding the TAC – does anyone believe this requires more discussion? * The process the WG is going through is trying to capture the deliberation and rationale that is being proposed by the WG. Part of that process is trying to consider other possible aspects. For example, Charter question a3 – until such time as the RDAP service or other secure method…the Temp Spec is pointing to RDAP and/or some secure method for transferring the data. For now, set aside the questions of lawfulness – the group needs to provide appropriate rationale for why the Gaining FOA is no longer required. As a practical matter, pre-GDPR, the Gaining Registrar got information automated via Port43, and registrars whitelisted each other to facilitate this. Could it be conceivable that now that RDAP is partially initiated that in two years – could a whitelist function be implemented that would allow registrars to still obtain the email address of an registered name holder? Or if not as simple as whitelisting, is there some sort of authentication mechanism that could be considered? This is the kind of deliberation that needs to happen here to provide the rationale for why the Gaining FOA could be removed. * The technical answer is yes – there are many ways to facilitate this; however, we must consider data protection law. * There will not be a legal basis for this transfer – the Gaining FOA is not needed. This is also probably not commercially feasible. * This could end up being very confusing for the registrant. In some jurisdictions, this is not possible, and transfers would be handled differently from registrar to registrar – this is not ideal. * Could the SSAD, if it were to be approved, be a way for registrars to gain access to the registered name holder’s data? UDRP providers are envisioned to use SSAD to verify the respondent in a UDRP complaint; similarly, could gaining registrars use SSAD to verify the identity of the registered name holder for purposes of a transfer? * Prior to GDPR, there was a system called RADAR that registrars could use. The problem would be the level of effort where you are potentially losing a paying customer could be cost-prohibitive. This does not overcome the risk of the transfer of personal information under GDPR. * Worthy to note that yes, there may be technical solutions. Is legal advice necessary to make a determination about the lawfulness of the processing of data? One member noted that there is not a lawful basis to process this data. This warrants an action by this group to document the lawfulness or lack thereof of processing this data. This is important to document for the purpose of public comment and the board. The response that this is not lawful will not be adequate. In today’s world, there is still a balancing for disclosure to UDRP providers. Recommend the group is very technically and legally precise and makes this understandable for those outside of this group. * Support Staff to pull out the relevant portions of this conversation to document rationales discussed * It is not that the gaining FOA is not obtaining the PII. It used to be that the public WHOIS was used to send the FOA to the domain owner. The Team has to ground this transfer in necessity. Unlike the UDRP, where the data is necessary, the transfer process has functioned properly without the Gaining FOA for years without instances of increased domain name theft. * ICANN community seems to be very easy going on the data that is collected and processed. The data registrars have, in general, is high level data, and it poses a huge security risk. * Transfers used to be just FOAs and then auth-info codes were added to make it more secure. Auth-info codes obviated the need for Gaining FOAs, and the last three years have additionally proven this point. * Gaining FOA also provides notice that registrant will need to enter into Registration Agreement with new Registrar * The registrant will need to enter into a registration agreement, but the Gaining FOA is not the first interaction between the gaining registrar and the registrant. The terms of service and registration agreement should happen before the Gaining FOA step. * Confirm the transfer in a 5-day window – have to actively knowledge the transfer – this may be a security feature that is not covered in future-state. * Loosely provides instructions about how to stop the transfer. * This chart is helpful – the 5-day window is already covered (item 2) and provides instructions about to stop the transfer is already covered in item 5. * Encourage members to continue adding reasons to the right side of the column so that the rationale is clearly documented. * 2. Transfer may proceed only when RNH has responded to this notification, therefore the notification is always well in advance of the transfer taking place. * 3. Gaining Rr obtains PII from Losing Rr and uses it to send Gaining FOA. * 4. Express authorization by RNH is needed for transfer to proceed. * 5. If the RNH takes no action in response to the Gaining FOA, transfer does not proceed. * 6. The Gaining FOA provides documentation that RNH has authorized the transfer. 1. Review of draft responses to charter questions and candidate recommendations for AuthInfo Codes (30 minutes) · AuthInfo Codes working document [docs.google.com]<https://urldefense.com/v3/__https:/docs.google.com/document/d/1O9PAnxWFUuPo…> · Based on the Team’s previous discussions, Support Staff drafted responses to the charter questions and accompanying candidate recommendations for the WG to review. · Note: these are not draft recommendations at this stage. · Candidate Recommendation 1: The Working Group recommends that the Transfer Policy and all related policies use the term “Transfer Authorization Code (TAC)” in place of the currently-used term “AuthInfo Code.” This recommendation is for an update to terminology only and does not imply any other changes to the substance of the policies. · Candidate Recommendation 2: The Working Group recommends that the Transfer Authorization Code be defined as follows: “A Transfer Authorization Code (TAC) is a code created by a Registrar of Record to validate that a request to transfer domain name in a generic top-level domain (gTLD) is submitted by the authorized person. A TAC is required for a Registered Name Holder to transfer a domain name from one Registrar to another.” * It is reasonable in some situations where someone other than the domain owner would have the TAC. Not sure this should be limited to authorized person. WG considered that having the TAC makes someone an authorized person. · Candidate Recommendation 3: The Working Group recommends that the Transfer Policy require that the TAC must be a minimum of [16 characters] [32 characters] in length or any alternative minimum length prescribed by ICANN from time to time. * There were two suggestions for length, so both options are included in brackets. · Candidate Recommendation 4: The Working Group recommends that the Transfer Policy require that the TAC include at a minimum of one uppercase letter, one lowercase letter, one number, and one special character. * ICANN internal colleagues noted that entropy is important – for example, 128 bits of entropy. * Instead of specifying, perhaps reference a security standard like NIST. * The problem with specifying a current standard is what happens when the standard changes – how long do registrars have to implement the new standard? * Could consider adding – or different length as prescribed by ICANN * Could the policy recommendation be for ICANN to set the specific standard as prescribed by NIST – in other words, the policy itself would be specific, but the policy recommendation would not be specific to allow for flexibility. · Candidate Recommendation 5: The Working Group recommends that the registry verify that the TAC meets the requirements specified in Recommendations 3 and 4. * When should this verification take place? If anyone has comments, please populate in the document. · Candidate Recommendation 6: [The Working Group recommends that the Registrar of Record [and registrant] receive a notification after [number] failed attempts to enter the TAC. ICANN Org may change from time to time the number of failed attempts that trigger a notification.] OR [The Working Group recommends that after [number] failed attempts to enter the TAC, it is not possible to attempt a transfer for [period of time]. ICANN Org may change from time to time the number of failed attempts that trigger this result.]. 5. AOB (5 minutes) · Next meeting: 12 October 2021 @ 16.00 UTC

1 0

Post Call | Transfer Policy Review PDP WG | Tuesday, 05 October 2021
by Julie Bisland Oct. 5, 2021

Oct. 5, 2021

Dear all, All recordings for the Transfer Policy Review PDP WG call held on Tuesday, 05 October 2021 at 16:00 UTC can be found on the agenda wiki page <https://community.icann.org/x/LAA_Cg> (attendance included) and the GNSO Master calendar [gnso.icann.org]<https://urldefense.com/v3/__https:/gnso.icann.org/en/group-activities/calen…>. These include: * Attendance (please let me know if your name has been left off the attendance list) * Audio recording * Zoom chat archive * Zoom recording (including audio, visual, rough transcript) * Transcript 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, Julie

1 0

Meeting Invitation | Transfer Policy Review PDP WG call | Tuesday, 12 October 2021 at 16:00 UTC
by Julie Bisland Oct. 5, 2021

Oct. 5, 2021

Dear all, The next Transfer Policy Review PDP WG call is scheduled for Tuesday, 12 October 2021 at 16:00 UTC for 90 minutes. Zoom Room Information: Main Zoom Webinar link: https://icann.zoom.us/j/95363727469?pwd=N3A3OWFSaTlUME9wZzlGajk5VUI3QT09 [icann.zoom.us]<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 [icann.zoom.us]<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/LgA_Cg * Check your time zone: https://tinyurl.com/5znrvb37 ONLY FOR MEMBERS & ALTERNATES: * Please join via the Main Zoom Webinar link above and staff will promote you to panelist. * Chat: Members (and alternates replacing members), please select Everyone so everyone can see and so it’s captured afterwards. * Alternate replacement confirmations – For tracking alternate replacements, use the google form [docs.google.com]<https://urldefense.com/v3/__https:/docs.google.com/forms/d/e/1FAIpQLScXP3-H…> to communicate the replacement (alternate) and the duration. This information 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 THREE Zs (zzz) before your name and add, in parentheses (your affiliation - alternate) after your name. To rename in Zoom, hover over your name and click ‘rename’. * 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

TPR-P1 // 30 Sep 2021 Project Package
by Berry Cobb Oct. 5, 2021

Oct. 5, 2021

Dear WG, Please find a link below to project package for the TPR-P1 PDP (30 Sep 2021). This package is a snap-shot at the close of each month and developed by the leadership team to report on the working group’s activities and status of the project. It is also distributed to the GNSO Council to keep them informed as managers of the PDP. The package is deposited on the wiki so that we can track access statistics. Link: https://community.icann.org/x/MQDQCQ 1. Page 01 – Summary dashboard 2. Page 02 – Project Sitrep – an extract from the Council’s Project List 3. Page 03,4 – Group roster 4. Page 05 – Work and activity metrics 5. Page 06 – Group attendance for plenary meetings 6. Page 07 – Project Plan, Gantt chart 7. Page 08-09 – Work plan & Action items for the period Key points: * The WG is proceeding according to plan against the charter topics/questions; nothing substantive to report for this period. Please let us know if you have questions. Thank you. B Berry Cobb Policy Development - Portfolio Manager Internet Corporation for Assigned Names and Numbers (ICANN) berry.cobb(a)icann.org

1 0

**On in 12 minutes** Meeting Invitation | Transfer Policy Review PDP WG call | Tuesday, 05 October 2021 at 16:00 UTC
by Julie Bisland Oct. 5, 2021

Oct. 5, 2021

Dear all, The next Transfer Policy Review PDP WG call is scheduled for Tuesday, 05 October 2021 at 16:00 UTC for 90 minutes. Zoom Room Information: Main Zoom Webinar link: https://icann.zoom.us/j/95363727469?pwd=N3A3OWFSaTlUME9wZzlGajk5VUI3QT09 [icann.zoom.us]<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 [icann.zoom.us]<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/LAA_Cg * Check your time zone: https://tinyurl.com/xj8cpk8d [tinyurl.com]<https://urldefense.com/v3/__https:/tinyurl.com/xj8cpk8d__;!!PtGJab4!rgneDUX…> ONLY FOR MEMBERS & ALTERNATES: * Please join via the Main Zoom Webinar link above and staff will promote you to panelist. * Chat: Members (and alternates replacing members), please select Everyone so everyone can see and so it’s captured afterwards. * Alternate replacement confirmations – For tracking alternate replacements, use the google form [docs.google.com]<https://urldefense.com/v3/__https:/docs.google.com/forms/d/e/1FAIpQLScXP3-H…> to communicate the replacement (alternate) and the duration. This information 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 THREE Zs (zzz) before your name and add, in parentheses (your affiliation - alternate) after your name. To rename in Zoom, hover over your name and click ‘rename’. * 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