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

Proposed agenda for meeting #12 on Tuesday 10 August 2021 at 16.00 UTC
by Emily Barabas Aug. 5, 2021

Aug. 5, 2021

Dear Working Group members, Please find below the proposed agenda for the meeting scheduled to take place on Tuesday 10 August 2021 at 16.00 UTC. Before the meeting, please take time to read the early written input received to date from SO/AC/SG/Cs: https://community.icann.org/x/tIT8CQ. All members will be responsible for familiarizing themselves with the input to help determine the impacts of these comments on the Working Group’s deliberations. Members representing groups who have submitted written input should be prepared to speak to the comments and answer questions from other WG members. Comments regarding AuthInfo Codes and Losing FOA have been added in orange text to the relevant working documents for easy reference. Please also review the working document for the topic Losing FOA, which will be discussed under agenda item 4: https://docs.google.com/document/d/1wCUMe9ii6g05kUZ558IuUvJaS6K2t0GZJYvlfOy… Kind regards, Emily, Julie, Caitlin, and Berry Transfer Policy Review Phase 1 - Meeting #12 Proposed Agenda Tuesday 10 August 2021 at 16.00 UTC 1. Roll Call & SOI Updates (5 minutes) 2. Welcome & Chair updates (5 minutes) 3. Continued discussion of AuthInfo Codes (15 minutes): Focus relevant SO/AC/SG/C written input: * AuthInfo Codes working document<https://docs.google.com/document/d/1O9PAnxWFUuPofLQCWIQXz8lT7KEj1HgH3b_obh0….> * Early input<https://community.icann.org/x/tIT8CQ> 4. Discussion of Losing FOA (60 minutes) * Losing FOA working document<https://docs.google.com/document/d/1wCUMe9ii6g05kUZ558IuUvJaS6K2t0GZJYvlfOy…> 5. AOB (5 minutes) - Next meeting: 17 August 2021 @ 16.00 UTC

1 0

Fwd: SAC119: Feedback to the GNSO Transfer Policy Review PDP WG
by Steve Crocker Aug. 5, 2021

Aug. 5, 2021

Folks, Attached is the formal SSAC report, SAC 119, that covers the feedback Jim Galvin and I have been providing regarding security of the authcode and preservation of resolution and validation when a change of registrar also requires a change of DNS service. Thanks, Steve ---------- Forwarded message --------- From: Andrew McConachie <andrew.mcconachie(a)icann.org> Date: Thu, Aug 5, 2021 at 7:05 AM Subject: SAC119: Feedback to the GNSO Transfer Policy Review PDP WG To: Merike Kaeo <merike(a)doubleshotsecurity.com>, merike.kaeo(a)board.icann.org <merike.kaeo(a)board.icann.org>, steve(a)shinkuro.com <steve(a)shinkuro.com> Cc: SSAC Admin Committee <ssac-exec-comm(a)icann.org> Dear Merike and Steve, Please find SAC119: Feedback to the GNSO Transfer Policy Review PDP WG and its Board coverletter attached. Please forward it to the ICANN Board and the GNSO Transfer Policy Review PDP WG. I will publish it on the SSAC website Monday. Thanks, Andrew

2 1

Post Call | Transfer Policy Review PDP WG | Tuesday, 03 August 2021 at 16:00 UTC
by Julie Bisland Aug. 3, 2021

Aug. 3, 2021

Dear all, All recordings for the Transfer Policy Review PDP WG call held on Tuesday, 03 August 2021 at 16:00 UTC can be found on the agenda wiki page<https://community.icann.org/x/YgTpCQ> (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

Notes and action items - TPR Meeting #11 - 03 August 2021
by Julie Hedlund Aug. 3, 2021

Aug. 3, 2021

Dear TPR Working Group, Please find below the notes and action items from today’s TPR meeting on Tuesday, 03 August 2021 at 16:00 UTC. The next meeting will be Tuesday, 10 August at 16:00 UTC. Best regards, Emily, Caitlin, Berry, and Julie -- Action Items ACTION ITEM: WG members to provide comments in the Auth-Info Codes Working Document on the draft recommendations 1 and 2 (page 2), and the Small Team principles (start at page 8) and strawman list (start at page 10) at: https://docs.google.com/document/d/1O9PAnxWFUuPofLQCWIQXz8lT7KEj1HgH3b_obh0… [docs.google.com]<https://urldefense.com/v3/__https:/docs.google.com/document/d/1O9PAnxWFUuPo…>. Notes: Transfer Policy Review Phase 1 - Meeting #11 Proposed Agenda Tuesday 03 August at 16.00 UTC 1. Roll Call & SOI Updates (5 minutes) 2. Welcome & Chair updates (5 minutes) 3. Continued discussion of Auth-Info Codes (75 minutes): Focus on Small Group Outcomes beginning on page 8: https://docs.google.com/document/d/1O9PAnxWFUuPofLQCWIQXz8lT7KEj1HgH3b_obh0… [docs.google.com]<https://urldefense.com/v3/__https:/docs.google.com/document/d/1O9PAnxWFUuPo…>. Poll Results: 1. The registrar creates the TAC and it is hashed at the registry. (17 responses) * Support as requirement -- 88% * Support as industry practice -- 12% * Do not support -- 0% 1. It’s not stored at the registrar and it is stored at the registry [but it only exists at the registry when the transfer is in progress]. (18 responses) * Support as requirement -- 22% * Support as industry practice -- 39% * Do not support -- 39% Discussion: * Some voted “no support” as needing more discussion, particularly about implementation. * Some concepts of not storing it – there are some reasons that would change that. * Second part of this was interesting – gets back to one of the questions the Small Group came up with as to whether there are other reasons for which people are using the Auth-Info code today. * Language is misleading. It should be in the registry and if it is it should be hashed. Agree with storing it only during the transfer process. * Could split this up into multiple concepts. * Problem for reseller registrars if they can’t store it. 1. Two-factor authentication, by whatever means the registrar sees fit. (21 responses) * Support as requirement -- 24% * Support as industry practice -- 57% * Do not support -- 19% Discussion: * Change to “industry standard, or optional” since industry standards can be mandates. Some registrars might not be able to follow the standard. * Don’t think we should use the wording “two-factor authentication” as it could be misleading in future. Change to “AuthID needs to be transferred to the registry in a secure manner.” * “Secure manner” is too vague. * The idea of two-factor on the system level is tricky – don’t think that is what we are suggesting. * When it comes to the security that is required to make things safe it should be completely up to the registrar, so it should not be a requirement. Technology will change very quickly, so what works now may be obsolete in a couple of years. Industry practices also will dictate. * How to handle it if it’s not written in policy? * If you put specifics into the requirements then you will allow a registrar to put those in. If you leave it up to industry practices then it isn’t part of the ICANN requirements. * “Secure Mechanism” is in the current Transfer Policy and is defined. * The Transfer Policy with respect to Change of Registrant uses the term "secure mechanism" and defines it in implementation notes as: Secure Mechanism: The policy recommendations by the GNSO recognize that some flexibility is required in how registrars process a Change of Registrant. As a non-limiting example, Registrars may want to consider "out of band" authentication based on information that cannot be learned from within the registrar account or publicly available resources such as Whois. Examples may include, but are not limited to: * sending an email requiring an affirmative response through a tool-based authentication method such as providing a unique code that must be returned in a manner designated by the Registrar; or * calling or sending an SMS to the Registered Name Holder's telephone number providing a unique code that must be returned in a manner designated by the Registrar; or * calling the Registered Name Holder's telephone number and requiring the Registered Name Holder to provide a unique code that was sent to the Registered Name Holder via web, email or postal mail. * Don’t try to define the specifics right now. * Think we should say state of the art secure authentication technology which is at the moment multi factor authentication. * If reseller is getting the TAC from registrar, then giving it to registrant, then what is the issue here? It is still more secure if registrars are required to use 2FA before giving out a TAC. * If we are too broad and vague about concepts we are not really making policies here. 1. Minimum character count for the TAC. (18 responses) * Support as requirement -- 89% * Support as industry practice -- 0% * Do not support -- 11% Discussion: * Wonder how you develop a minimum character count for the TAC and when does it become obsolete. * How do we future proof this? For example, is 4-character enough to eliminate the FOA? Should be a minimum. Hard to set the maximum. * Not sure that there is an industry standard. There are several. * Nice to have a minimum and maximum to be able to do a quick validation. * What happens when the maximum is insecure? How do we change it? * 32 or any length ICANN may prescribe from time to time. * General agreement that a minimum could be set. Not get detailed but wording should support flexibility. 1. Require uppercase and lowercase letters, numbers, and special characters. Prohibit use of dictionary words. (20 responses) * Support as requirement -- 65% * Support as industry practice -- 35% * Do not support -- 0% Discussion: * Seems to be support for making this at least a good practice or a requirement. * The Small Team wanted to ensure further uniqueness of the string. Avoid a password that is “123…”. * Making say “restricted words” instead of “dictionary words”? * If you say, “don’t do dictionary” then you have to check against a dictionary. It’s tough because you have to decide whose dictionary it is; requirements could change between registrars. * This concept should be encouraged, but I do not see how a requirement could realistically be drafted or enforced * Could look to NIST standards. 1. Registry check to ensure TAC meets minimum requirements. (16 responses) * Support as requirement -- 75% * Support as industry practice -- 13% * Do not support -- 13% Discussion: * Seems like the check should be done at the registry before sending over to the registry. * The thought was to discourage fringe registrar actors from not doing what they are supposed to do. Could be just a syntax check. * The registry would be the location of central enforcement logically... it would happen at the registrar due to it being a registry requirement. * Skeptical that registries should provide oversight … we don’t want police registries … * Registries to validate that the TAC matches requirements. Like, some checks and balances? * it depends on what we mean by ensuring TAC meets minimum requirements… 1. Failed attempt identification/notification after a certain number of requests to initiate a transfer. (17 responses) * Support as requirement -- 76% * Support as industry practice -- 18% * Do not support -- 6% Discussion: * Good support for requirement or industry practice. * Don’t support because not clear what the failed attempts should be. * This needs to be fleshed out. * Could see how it could be useful, but not as a requirement. * What if the registry tracked it and just alerted the registrar when the threshold is met – optional for the registrar to do it. * Registrar should be able to set up its own threshold and notification system – total control over the number of attempts. * Good option since a registrar wouldn’t be able to see attacks on domains registered to us. * Seems like a good idea, but think about whether it should be a requirement or practice. 1. Lock needs to be off for TAC to be requested/updated. (18 responses) * Support as requirement -- 39% * Support as industry practice -- 0 % * Do not support -- 61 % Discussion: * Not sure of the timing of when you get the Auth Code and when you release the lock. Why would you need to release the lock to get the Auth Code? * Don’t see why it would be a requirement to have it on or off. * Why not allow the flexibility? Why does it have to be on or off? * rather it be possible to keep the domain locked right up until the transfer itself gets initiated * concept on the lock use extending to code request was to add a layer of safety * Do get an Auth Code the lock don’t have to be off, but they do for the transfer to be executed. * The process should be standard across all registrars and registries, as to when locks must be on or off. 1. Maximum TTL for the TAC. (19 responses) * Support as requirement -- 79% * Support as industry practice -- 11% * Do not support -- 11% Discussion: * Majority supported as a requirement. * Need to think about the maximum TTL – would the registry be involved in enforcing it? * Note that the WG discussed this topic under Charter Question b4, for those referencing the document during the discussion * Should there be two questions? 1) should there be a TTL? 2) what should the maximum TTL be? * In the Small Team the majority accepted the concept of a TTL, but the details needed to be sorted out. * If there is a TTL but not a maximum, one could just set it for 10 years, which would not make sense. * Maximum helps to prevent registrars from keeping them for a long time. * If there is a maximum TTL you can avoid a lot of problems. * What the maximum is, is a good discussion. * There is also an inter-dependency within the Auth Code discussion itself related to a concept of there being no Authcode set and how that would work, plus the more meta discussions around bulk-transfer within this WG. * Auth TTL max/min interplays with those conceptually. 1. Minimum TTL for the TAC. (18 responses) * Support as requirement --83 % * Support as industry practice -- 11% * Do not support -- 6% Discussion: * General support for a minimum requirement. * As long as it possible to overwrite/invalidate it if it’s compromised then everything is good. * Definitely needs to be something in there that is something is hacked to ensure that the registrar can fix it – so don’t have the minimum as a requirement in the case of security breaches. Draft Recommendations: Draft Recommendation 1: The Working Group recommends that the Transfer Policy use the term “Transfer Authorization Code (TAC)” in place of the currently-used term “AuthInfo Code.” Draft 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 to validate that a generic top-level domain (gTLD) transfer request 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.” * WG members to review and comment. 4. AOB (5 minutes) - Next meeting: 10 August 2021 @ 16.00 UTC * Goal is to continue at the same time into September and beyond. * Staff will send out invites.

1 0

Meeting Invitation | Transfer Policy Review PDP WG call | Tuesday, 10 August 2021 at 16:00 UTC
by Julie Bisland Aug. 3, 2021

Aug. 3, 2021

Dear all, The next Transfer Policy Review PDP WG call is scheduled for Tuesday, 10 August 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/ZQTpCQ Check your time zone: https://tinyurl.com/dyfedvzj ONLY FOR MEMBERS & ALTERNATES: * Please join via the above Main Zoom Webinar link and staff will promote you to panelist. * Members (and alternates replacing members), please select Panelists and Attendees or Everyone when posting to the chat in order for everyone to see and to be captured afterwards. * Alternate replacement confirmations – In order to keep track of 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): Please 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

Transfer Policy Review PDP WG
by ICANN Policy Calendar Aug. 3, 2021

Aug. 3, 2021

Meeting: Transfer Policy Review PDP WG Date/Time: Recurring call every Tuesday at 16:00 UTC for 90 minutes, 29 June 2021 through 31 August 2021 Join the Zoom Webinar: https://icann.zoom.us/j/95363727469?pwd=N3A3OWFSaTlUME9wZzlGajk5VUI3QT09 Passcode: @TP/^*4wg# 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 29 June Wiki Agenda meeting page: https://community.icann.org/x/VwTpCQ (see left side for other meeting dates) Check your time zone: https://tinyurl.com/5k3u34hf ONLY for Members & Alternates: * Please join via the above Zoom Webinar link and staff will promote you to Panelist * Alternate replacement confirmations – In order to keep track of alternate replacements, use the google form<https://docs.google.com/forms/d/e/1FAIpQLScXP3-H595xH4EFgaR3ydOr-1o9BLAVGUI…> to communicate who the alternate is replacing and for which period. This information will be posted to the Alternate Log-Transfer Policy Review PDP wiki page<https://community.icann.org/x/V4aUCQ>. * Members and alternates replacing members, please select Panelists and Attendees, or Everyone when posting to the chat in order for everyone to see and to be captured afterwards. * Alternates (not replacing a member): Please rename your line in Zoom by adding THREE Zs “zzz” before your name, and 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. For 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

1 0

**10-MINUTE REMINDER** Meeting Invitation | Transfer Policy Review PDP WG call | Tuesday, 03 August 2021 at 16:00 UTC
by Julie Bisland Aug. 3, 2021

Aug. 3, 2021

**Starts in 10 minutes** Dear all, The next Transfer Policy Review PDP WG call is scheduled for Tuesday, 03 August 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/YgTpCQ Check your time zone: https://tinyurl.com/5ypz6y63 [tinyurl.com]<https://urldefense.com/v3/__https:/tinyurl.com/5ypz6y63__;!!PtGJab4!sSRtgIg…> ONLY FOR MEMBERS & ALTERNATES: * Please join via the above Main Zoom Webinar link and staff will promote you to panelist. * Members (and alternates replacing members), please select Panelists and Attendees or Everyone when posting to the chat in order for everyone to see and to be captured afterwards. * Alternate replacement confirmations – In order to keep track of 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): Please 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, Andrea

1 0

**Reminder** Meeting Invitation | Transfer Policy Review PDP WG call | Tuesday, 03 August 2021 at 16:00 UTC
by Andrea Glandon Aug. 2, 2021

Aug. 2, 2021

Dear all, The next Transfer Policy Review PDP WG call is scheduled for Tuesday, 03 August 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/YgTpCQ Check your time zone: https://tinyurl.com/5ypz6y63 [tinyurl.com]<https://urldefense.com/v3/__https:/tinyurl.com/5ypz6y63__;!!PtGJab4!sSRtgIg…> ONLY FOR MEMBERS & ALTERNATES: * Please join via the above Main Zoom Webinar link and staff will promote you to panelist. * Members (and alternates replacing members), please select Panelists and Attendees or Everyone when posting to the chat in order for everyone to see and to be captured afterwards. * Alternate replacement confirmations – In order to keep track of 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): Please 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, Andrea

1 0