March 2022 - GNSO-TPR - lists.icann.org

Post Call | Transfer Policy Review PDP WG | Tuesday, 22 March 2022
by Julie Bisland March 23, 2022

March 23, 2022

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

3 2

Meeting Invitation | Transfer Policy Review PDP WG call | Tuesday, 29 March 2022
by Julie Bisland March 22, 2022

March 22, 2022

Dear all, The next Transfer Policy Review PDP WG call is scheduled for Tuesday, 29 March 2022 at 16:00 UTC for 90 minutes. Zoom Room Information: Main Zoom Webinar link: https://icann.zoom.us/j/95363727469?pwd=N3A3OWFSaTlUME9wZzlGajk5VUI3QT09 <https://urldefense.com/v3/__https:/icann.zoom.us/j/95363727469?pwd=N3A3OWFS…> Passcode: @TP/^*4wg# If you are joining via audio only: One tap mobile: US: +19294362866,,95363727469#,,,,*7490739013# or +13017158592,,95363727469#,,,,*7490739013# Telephone: Dial (for higher quality, dial a number based on your current location): US: +1 929 436 2866 or +1 301 715 8592 or +1 312 626 6799 or +1 669 900 6833 or +1 253 215 8782 or +1 346 248 7799 or 888 788 0099 (Toll Free) or 877 853 5247 (Toll Free) Webinar ID: 953 6372 7469 Passcode: 7490739013 International numbers available: https://icann.zoom.us/u/acdLFXPLp6 <https://urldefense.com/v3/__https:/icann.zoom.us/u/acdLFXPLp6__;!!PtGJab4!v…> Members, alternates, and observers all have different access and participation directions, please read below! ALL: Before joining the call: * Please send apologies and dial out requests to gnso-secs(a)icann.org<mailto:gnso-secs@icann.org> only * Please be sure you have read the ICANN Expected Standards of Behavior<https://www.icann.org/resources/pages/expected-standards-2016-06-28-en> * Visit the Wiki Agenda meeting page: https://community.icann.org/x/KhAiCw * Check your time zone: https://tinyurl.com/42rdpvy9 ONLY FOR MEMBERS & ALTERNATES: * Please join via the Main Zoom Webinar link above; 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

Notes and action items - TPR WG Meeting #39 - 22 Mar 2022
by Julie Hedlund March 22, 2022

March 22, 2022

Dear TPR WG Members, Please find below the notes and action items from today’s meeting. The next TPR WG meeting will be on Tuesday, 29 March 2022 at 16:00 UTC. Best regards, Emily, Julie, Berry, and Caitlin Action Items: None captured. Transfer Policy Review Phase 1 - Meeting #39 Tuesday 22 March 2022 at 1600 UTC 1. Roll Call & SOI updates (5 minutes) 2. Welcome & Chair updates (5 minutes) a. Update from Steinar Grøtterød, ALAC: Distributed results of discussion in the CPWG on locks. Based on that discussion we had a poll. There were around 40 responses. The results showed support for a 60-day period for locks as well as 30 days. Positive response to keeping the same policy for all locks. This input should be taken as informal. Questions/Comments: * Question: Noted that in the time period for the transfer locks there was equal support for 10 and 60 days, but for creation lock there was support for the 30-day period. Any explanation for that result? Answer: There was a concern about whether there was enough time for the UDRP with 10 days, so less support for that, but in general there was support for keeping the shorter period. * Question: Seems like the respondents didn’t understand the locks relating to the UDRP, would more information help? Also, isn’t a goal to standardize the time periods for the lock? * Question: Could you say what the policy was supposed to be that would be the same for all registry operators? Answer: We thought it would be more user friendly to have the same policy. That it should be the same number of days for creation and transfer locks. * There are more registries that would prefer not to have activities in this space. Need a discussion as to whether there should be a requirement on registry operators. This has not been decided in this WG. * Steinar: Would like to hear if 10 days is a real show stopper for the UDRP policy. * 60 days seems far too long and 10 days seems to have general support. * Question: Are we asking whether 10 days from creation enough time to file a UDRP? Answer: In post-create and post-transfer is 10 days enough time to complete a UDRP? * Once a UDRP is notified the name is locked until settled, so the creation or transfer lock no longer applies. * Don’t think the creation or transfer locks had anything to do with the UDRP. The lock for the UDRP on notification is separate. The length of a creation lock shouldn’t have any bearing on how long it takes to complete a UDRP. These locks should be mutually exclusive. * The brand protection services are pretty quick to file a UDRP. Once settled, the creation lock would still apply. * This seems a non-issue… very few UDRPs filed within first 30 days as there would rarely be any usage by then, plus time to prepare and file. * Once the creation lock expires, the UDRP lock still applies. If we are looking at 10 days, if a UDRP is filed in 12 days then the name might have been transferred, in which case some of the UDRP filing would have to be updated to reflect the transfer. This was also an issue that WIPO brought up. If a complaint is filed, but the domain is not locked in time, and transferred to a new Registrar, then the admin process has to reset as owner(RNH)/Registrar have changed. * Even if they were to change the registrar, another 10-day transfer lock would apply. * Question: If we were to standardize a post-creation or transfer lock, would this be a registry lock or a registrar lock? Answer: Roger’s assumption was that the lock was enforced at the registrar level. Registries would only be brought in if there was a court case. The post-creation and post-transfer would be the registrar handling the locking of the domain during that period. * Question: There this also an open question as to how registry lock is handled during the transfer process? When is a registry lock removed or put back on? * Think the registry lock is outside the transfer policy. * Question: While the registry lock service is out of scope, there still is an issue of when the registry lock is dealt with? Seems like that point is in scope for this WG. * If the registry lock doesn’t come off, then the losing registrar will deny the transfer to the gaining registrar. * Seems that it would be good to have a stated policy on this – even if the statement is that the policy does not address this. But think the registrars would want to know what are their obligations. * Don’t see why it needs to be treated differently than any other lock? If the domain owner who requested it in the first place asked for it to be removed, then it gets removed. if not, isn't the whole point of the lock to prevent a transfer? * In the swimlane it is the sponsoring registrar’s responsibility to address any locks, including registry locks. * Seems that we’ll need another swimlane review session. In relation to who does what and when, if we look at this in the swimlane in general the moment the TAC is provisioned (which is an automated step), if there are any locks that the sponsoring registrar determines would prevent the transfer they shouldn’t be provisioning the TAC, the losing/sponsor registrar should resolve any locks. If all the locks are not cured there is an out to kick it back to the losing registrar. * The registry still has to do that final check. * The locks that we are talking about are in terms of EPP statuses being set. There really is no such thing as a “registry lock”, but a set of EPP statuses. Should talk in terms of service statuses. * “5. Registry Lock: Registry Operator may offer the Registry Lock service, which is a registry service that allows an authorized representative from the sponsoring Registrar to request the activation or deactivation of any of the following EPP statuses: serverUpdateProhibited, serverDeleteProhibited and⁄or serverTransferProhibited.” * A registry will set these EPP statuses as part of a registry lock service in order to protect registrants. There is an interaction with these registry lock statuses with the transfers that we need to understand. A registry to create a lock service that a RNH could ask for a transfer, registrar handles the client statuses that they have to cure, but the registry statuses stay in place. The registry gets a transfer request, but how do they distinguish that from an attack? The registrar of record would get a notification and then would have to notify the RNH, cure the lock, get the name transferred, and then the registry would reinstitute the lock. * Maybe the Registry which offers the lock service could include in the lock removal process that the RNH should tell them the correct gaining registrar and the Registry only allows the transfer to that registrar. * Don’t think we should treat registry lock as any special. Could simplify it by looking just at the EPP status. * The window of vulnerability is the time period between when the registry lock status is removed until it is restored. That’s a vulnerability for the registrant, since the TAC is at risk of getting lost or stolen. b. Update From ICANN Org Compliance re: “3.9.3 Domain name in Registrar Lock Status, unless the Registered Name Holder is provided with the reasonable opportunity and ability to unlock the domain name prior to the Transfer Request.” * Compliance invokes 3.9.3 when the domain has an internal lock applied. Example is an internal lock for additional security. The registrant had to follow some steps to request for the lock to be disabled. Generally, the registrar can’t deny a transfer if an internal lock has been applied without giving an opportunity for the registrant to request that the internal lock is removed. Helpful if the policy could provide clarification on what is “reasonable.” 3. Begin discussion on bulk use cases (60 minutes) Related charter question: “b5) Should the ability for registrants to request AuthInfo Codes in bulk be streamlined and codified? If so, should additional security measures be considered?” See AuthInfo Codes Working Document<https://docs.google.com/document/d/1O9PAnxWFUuPofLQCWIQXz8lT7KEj1HgH3b_obh0…>, page 9. * Theo Geurts: In the Netherlands, if you want to transfer your portfolio from one registrar to another, you provide the names to the gaining registrar, the registry contacts the losing registrar to get the necessary verifications, then the registry moves the database. Pretty easy and cost effective. Dutch registry charges 50 Euro for a database switch. Current bulk transfers are overly complex. * For a lot of TLDs it’s even easier as the transfer is instant. * Would like to see an additional security level and claw back because of the number of domains. * Think we should be aware that this already happens in the gTLD space. As long as there can be a transfer that doesn’t go against the transfer policy, those transfers can happen. * We are talking about large-scale transfers outside of BTAPPA. * Overall the bulk transfer process should be similar to the single-domain transfer. * Question: Have we talked about the contact information – how would that be handled for bulk transfers? Couldn’t find recommendations on contact information in the AuthInfo Code working document. * I don’t think that contact info is needed… because the gaining registrar literally has to know the registrant. * Think that the BTAPPA is a fast-track registry service. There is pre-approved boilerplate language, so we would have to make sure that our recommendations don’t interfere with things that already exist. Also, not clear in the charter question what “bulk” means, but it is defined in the BTAPPA process. * Think we are going to discuss what “bulk” is. * So areas that could be different are (1) how the TAC is obtained, (2) if the notice of TAC provision needs to be sent once or multiple times, (3) if multiple domains + TACs can be submitted in one order to the registry (does it matter?) (4) how is it verified that they should all go together, (5) does the contact info all have to be the same pre-transfer, (6) does the contact info all have to be the same post-transfer. * Need to think also about whether a year is added to the extension. * Need to separate this out from BTAPPA. 4. AOB (5 minutes) * Next call: ICANN73 session on Tuesday 29 March 2022 at 16:00 UTC

1 0

**STARTING IN 15 MINUTES** Meeting Invitation | Transfer Policy Review PDP WG call | Tuesday, 22 March 2022
by Julie Bisland March 22, 2022

March 22, 2022

**STARTING IN 15 MINUTES** Dear all, The next Transfer Policy Review PDP WG call is scheduled for Tuesday, 22 March 2022 at 16:00 UTC for 90 minutes. Zoom Room Information: Main Zoom Webinar link: https://icann.zoom.us/j/95363727469?pwd=N3A3OWFSaTlUME9wZzlGajk5VUI3QT09 <https://urldefense.com/v3/__https:/icann.zoom.us/j/95363727469?pwd=N3A3OWFS…> Passcode: @TP/^*4wg# If you are joining via audio only: One tap mobile: US: +19294362866,,95363727469#,,,,*7490739013# or +13017158592,,95363727469#,,,,*7490739013# Telephone: Dial (for higher quality, dial a number based on your current location): US: +1 929 436 2866 or +1 301 715 8592 or +1 312 626 6799 or +1 669 900 6833 or +1 253 215 8782 or +1 346 248 7799 or 888 788 0099 (Toll Free) or 877 853 5247 (Toll Free) Webinar ID: 953 6372 7469 Passcode: 7490739013 International numbers available: https://icann.zoom.us/u/acdLFXPLp6 <https://urldefense.com/v3/__https:/icann.zoom.us/u/acdLFXPLp6__;!!PtGJab4!v…> Members, alternates, and observers all have different access and participation directions, please read below! ALL: Before joining the call: * Please send apologies and dial out requests to gnso-secs(a)icann.org<mailto:gnso-secs@icann.org> only * Please be sure you have read the ICANN Expected Standards of Behavior<https://www.icann.org/resources/pages/expected-standards-2016-06-28-en> * Visit the Wiki Agenda meeting page: https://community.icann.org/x/KBAiCw * Check your time zone: https://tinyurl.com/fh6m7max [tinyurl.com]<https://urldefense.com/v3/__https:/tinyurl.com/fh6m7max__;!!PtGJab4!tKeGu8Y…> ONLY FOR MEMBERS & ALTERNATES: * Please join via the Main Zoom Webinar link above; 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

AT-LARGE INPUT TO THE DISCUSSION OF POST-CREATION AND POST-TRANSFER LOCKS
by Steinar Grøtterød March 22, 2022

March 22, 2022

Dear TPR Work Group members, The Consolidated Policy Working Group (CPWG) is the At-Large forum for discussing policy related issues and giving advice to the ICANN community. At-Large is represented in the GNSO transfer Policy Review Policy Development Process (TPR-PDP) with 2 members, 2 alternates and 4 observers. The At-Large TPR-PDP members continuously inform the CPWG members about the progress in the TPR-PDP working group and seek feedback and advice in essential questions given by the work in the TPR-PDP. In order to get the CPWG input to questions connected to post-creation and post-transfer locks, an informal “poll” was held at the CPWG meeting on March 16, 2022. In front of the meeting, information about the discussion and work done by the GNSO TPR-PDP were distributed to the CPWG members. The information also included the “poll questions”. The “poll questions” were conducted based on the work done in the TRP-PDP. In addition, the “poll” included a question reflecting CPWG input to a mandatory policy for all Registry Operators. The poll questions and the results For the post-creation lock question What lock period will be of preference: * 10 days post-creation lock: 31% * 30 days post-creation lock: 59% * 60 days post-creation lock: 7% * Not sure: 0% * Abstain: 3% For the post-transfer lock question What lock period will be of preference: * 10 days post-transfer lock: 41% * 30 days post-transfer lock: 45% * 60 days post-transfer lock: 7% * Not sure: 3% * Abstain: 3% For the question regarding Registry Operator * Same policy for all Registry Operator: 76% * A Registry Operator MAY define a different transfer lock policy: 14% * Not sure: 7% * Abstain: 3% Please note that the 30 days alternative is added to the poll to get more alternatives. The 30 days locks are not discussed as an alternative in the TRP-PDP WG. The result may be seen as: * CPWG is in the opinion that the present practice with a 60 day post-creation and post-transfer lock is too long. * The poll may signal that there could be a different lock periode between the post-creations and the post-transfers. * A significant number of CPWG members favors that the updated Inter-Registrar Transfer Policy should be the same for all Registry Operators. In our opinion, this makes it more user friendly by having a level playing field across all operators. We emphasize the fact that the results of the poll and this feedback to the TRP-PDP is informal and may not reflect At-Large view when the PDP is up for vote to be finalized. Regards, Steinar Grøtterød At-Large

1 0

Proposed agenda for meeting #39 on Tuesday 22 March 2022 at 16:00 UTC
by Emily Barabas March 21, 2022

March 21, 2022

Dear Working Group members, Please find below the proposed agenda for the meeting scheduled to take place on Tuesday 22 March 2022 at 16:00 UTC. Kind regards, Julie, Caitlin, Berry, and Emily Transfer Policy Review Phase 1 - Meeting #39 Proposed Agenda 1. Roll Call & SOI updates (5 minutes) 2. Welcome & Chair updates (5 minutes) 1. Begin discussion on bulk use cases (60 minutes) 2. Continued deliberations on Denial of Transfers (15 minutes) * Working document [docs.google.com]<https://urldefense.com/v3/__https:/docs.google.com/document/d/1L2bZnhJUY3Vx…> 3. AOB (5 minutes) * Next call: ICANN73 session on Tuesday 29 March 2022 at 16:00 UTC

1 0

**REMINDER** Meeting Invitation | Transfer Policy Review PDP WG call | Tuesday, 22 March 2022
by Julie Bisland March 21, 2022

March 21, 2022

Dear all, The next Transfer Policy Review PDP WG call is scheduled for Tuesday, 22 March 2022 at 16:00 UTC for 90 minutes. Zoom Room Information: Main Zoom Webinar link: https://icann.zoom.us/j/95363727469?pwd=N3A3OWFSaTlUME9wZzlGajk5VUI3QT09 <https://urldefense.com/v3/__https:/icann.zoom.us/j/95363727469?pwd=N3A3OWFS…> Passcode: @TP/^*4wg# If you are joining via audio only: One tap mobile: US: +19294362866,,95363727469#,,,,*7490739013# or +13017158592,,95363727469#,,,,*7490739013# Telephone: Dial (for higher quality, dial a number based on your current location): US: +1 929 436 2866 or +1 301 715 8592 or +1 312 626 6799 or +1 669 900 6833 or +1 253 215 8782 or +1 346 248 7799 or 888 788 0099 (Toll Free) or 877 853 5247 (Toll Free) Webinar ID: 953 6372 7469 Passcode: 7490739013 International numbers available: https://icann.zoom.us/u/acdLFXPLp6 <https://urldefense.com/v3/__https:/icann.zoom.us/u/acdLFXPLp6__;!!PtGJab4!v…> Members, alternates, and observers all have different access and participation directions, please read below! ALL: Before joining the call: * Please send apologies and dial out requests to gnso-secs(a)icann.org<mailto:gnso-secs@icann.org> only * Please be sure you have read the ICANN Expected Standards of Behavior<https://www.icann.org/resources/pages/expected-standards-2016-06-28-en> * Visit the Wiki Agenda meeting page: https://community.icann.org/x/KBAiCw * Check your time zone: https://tinyurl.com/fh6m7max [tinyurl.com]<https://urldefense.com/v3/__https:/tinyurl.com/fh6m7max__;!!PtGJab4!tKeGu8Y…> ONLY FOR MEMBERS & ALTERNATES: * Please join via the Main Zoom Webinar link above; 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

Staff action item: origins of NACKing categories MAY, MUST, and MAY NOT
by Emily Barabas March 17, 2022

March 17, 2022

Dear Working Group members, Following the most recent WG meeting, staff had an action item to research the origins of the terms “MAY”, “MUST”, and “MAY NOT” as categories related to denial of transfers in general and specifically as it relates to I.A.3.9.5. Going back to the 2002 ICANN DNSO Transfers Task Force Final Report & Recommendations<http://www.dnso.org/dnso/notes/20030212.NCTransferTF-gaining-and-losing-reg…>, recommendation 24 lists circumstances under which a Losing Registrar MAY deny a transfer. Recommendation 25 provides a non-exhaustive list of circumstances under which a transfer MAY NOT be denied (the language specifically states: “Instances when the Losing Registrar may not deny a transfer include, but are not limited to;”). The list includes “e. General payment defaults between Registrar and business partners / affiliates in cases where the Registrant for the domain in question has paid for the registration.” This same language is currently reflected in I.A.3.9.5. The introduction of a category of circumstances under which a Losing Registrar MUST deny a transfer came with the implementation of recommendations associated with IRTP Part C<https://gnso.icann.org/sites/default/files/filefield_34607/irtp-c-final-rep…>. The updated policy went into effect on December 2016<https://www.icann.org/resources/pages/transfer-policy-2016-06-01-en>. In short, the “MAY” and “MAY NOT” not categories were the two originally introduced, with the “MUST” category following via later policy development work. Staff did not find any documentation of why it was decided to use the term “MAY NOT” as opposed to “MUST NOT” in the 2002 report. Please let us know if you have any questions. Kind regards, Caitlin, Berry, Julie and Emily Emily Barabas Policy Development Support Senior Manager Internet Corporation for Assigned Names and Numbers (ICANN) Phone: +31 (0)6 84507976 www.icann.org<http://www.icann.org/>

1 0

Meeting Invitation | Transfer Policy Review PDP WG call | Tuesday, 22 March 2022
by Julie Bisland March 9, 2022

March 9, 2022

Dear all, The next Transfer Policy Review PDP WG call is scheduled for Tuesday, 22 March 2022 at 16:00 UTC for 90 minutes. Zoom Room Information: Main Zoom Webinar link: https://icann.zoom.us/j/95363727469?pwd=N3A3OWFSaTlUME9wZzlGajk5VUI3QT09 <https://urldefense.com/v3/__https:/icann.zoom.us/j/95363727469?pwd=N3A3OWFS…> Passcode: @TP/^*4wg# If you are joining via audio only: One tap mobile: US: +19294362866,,95363727469#,,,,*7490739013# or +13017158592,,95363727469#,,,,*7490739013# Telephone: Dial (for higher quality, dial a number based on your current location): US: +1 929 436 2866 or +1 301 715 8592 or +1 312 626 6799 or +1 669 900 6833 or +1 253 215 8782 or +1 346 248 7799 or 888 788 0099 (Toll Free) or 877 853 5247 (Toll Free) Webinar ID: 953 6372 7469 Passcode: 7490739013 International numbers available: https://icann.zoom.us/u/acdLFXPLp6 <https://urldefense.com/v3/__https:/icann.zoom.us/u/acdLFXPLp6__;!!PtGJab4!v…> Members, alternates, and observers all have different access and participation directions, please read below! ALL: Before joining the call: * Please send apologies and dial out requests to gnso-secs(a)icann.org<mailto:gnso-secs@icann.org> only * Please be sure you have read the ICANN Expected Standards of Behavior<https://www.icann.org/resources/pages/expected-standards-2016-06-28-en> * Visit the Wiki Agenda meeting page: https://community.icann.org/x/KBAiCw * Check your time zone: https://tinyurl.com/fh6m7max [tinyurl.com]<https://urldefense.com/v3/__https:/tinyurl.com/fh6m7max__;!!PtGJab4!tKeGu8Y…> ONLY FOR MEMBERS & ALTERNATES: * Please join via the Main Zoom Webinar link above; 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: ICANN Zoom room requirements: Zoom Logins: First & Last Name/ Surname Only
by Nathalie Peregrine March 9, 2022

March 9, 2022

Dear all, To ensure transparency of participation in ICANN’s multistakeholder model, please remember to sign in to Zoom sessions using your full name (e.g. First Name + Last Name/Surname). If you are in a session using the webinar format, you will need to first exit the Zoom room prior to rejoining. Please reach out to your support staff if you have any difficulties joining a Zoom session. To rename in a regular Zoom room: 1. Join the meeting. 2. Tap Participants. 3. Hover over your name on the participants list. 4. Click More. 5. Click Rename. 6. Enter the name you desire then click Rename. 7. Your name has now been changed within the meeting. To rename in a webinar Zoom room: 1. BEFORE entering the meeting, and during the login phase, update your Zoom name here: [cid:image001.png@01D83300.B8213430] 1. If you forget to do so, you can always log out of the webinar Zoom room and edit your name upon re-entering. Please contact your support staff if you run into any issues. Thank you! Kind regards, Nathalie

1 0