- GNSO-TPR - lists.icann.org

Proposed Agenda - Meeting #113 Tuesday, 09 January 2024 at 1600 UTC
by Christian Wheeler Jan. 6, 2024

Jan. 6, 2024

Dear TPR WG members, Happy New Year! Please find below the proposed agenda for our next call, taking place on Tuesday, 09 January 2024 at 16:00 UTC. Thank you and we look forward to seeing you all virtually. Kind regards, Christian, Caitlin, Berry, and Julie ---------- Transfer Policy Review - Meeting #113 Proposed Agenda 09 January 2023 1. Welcome and Chair updates 2. Recap COR Security Measures discussion (preliminary recommendations) a. Improper CORs b. COR + TAC requests 3. Definitions discussion: Change of Registrant vs Control 4. AOB

1 0

Post Call | Transfer Policy Review PDP WG | Tuesday, 19 December 2023
by Julie Bisland Dec. 19, 2023

Dec. 19, 2023

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

1 0

Notes and action items: TPR WG on 19 Dec at 1600 UTC
by Julie Hedlund Dec. 19, 2023

Dec. 19, 2023

Dear TPR WG members, Please find below the brief notes and action items from today’s meeting. The next meeting will be in three weeks on Tuesday, 09 January 2024 at 1600 UTC. Kind regards, Christian, Caitlin, Berry and Julie ACTION ITEMS/HOMEWORK: None captured. Transfer Policy Review - Meeting #112 Proposed Agenda 19 December 2023 Notes: 1. Welcome and Chair updates * This is our last call of the year – resuming on 09 January in two weeks, same time. * Eight meetings before ICANN79; finish up COR and return to any outstanding items. * Call for updates: None provided. 2. Discussion of Security Measures: COR + Registrar Transfers – See attached slides. * Moving on from COR only to COR + TAC request. * Wrap up COR only and COR + TAC request security measures following the break and before ICANN79. * 60-day lock seems to be causing frustration and doesn’t seem to provide increased security. Discussion – option 1 (slide 3): * Question: Doesn’t the registrar do a validation/security check. Answer: 5-day window was for registrars to do due diligence/security/validation check. Some TAC request may be almost instantaneously fulfilled; other may take longer because of check. * Last bullet is an option for registrar to offer or not. * Usually not what happens: usually registrant logs into their account – don’t usually get a TAC request via email. * Thinks the intent was the above: TAC request comes in and then registrar notices it’s from a different email. * The order is usually that the registrant requests a TAC but then notice that they need to update their info. * Compliance has had lots of complaints when they need to request a TAC but can’t because they need to update their contact info. * This is not specific because it is registrar-specific. * This is one of several options. Discussion – option 2 (slide 5): * That 5-day window for the registrar allows a security check. In the Group 1A discussions we covered this. * This is combining two processes – updating contact info and requesting the TAC – that is not necessary and creates a dependency. * If we look at the example, that is not how the TAC is requested (via email). Agree not to combine processes and we already have an option for the registrar to validate. * TAC request is coming in however. * This could be a business decision by a registrar. Like the email notification but don’t require approval from both the old and new registrant. * The timing of the email change – business decision as to whether that requires validation/5-day wait. Losing registrar’s responsibility. Change of registrant does happen often around a change of contact. * We need to factor in how some registrars are processing expired deletions. Those may change contact info. * Allowing an objection by the losing registrant is an opportunity for fraud. No need for the losing registrant to be involved. * The above is an argument for this to be a registrar’s business decision. Discussion – Option 3 (slide 7): * Not seeing how this provides an added security benefit – same security as option 1, registrar to validate. * This makes a lot of sense – should verify if you change contact info, but doesn’t add security. * This can be used against registrants. Could keep a registrant from moving to a new registrar. Discussion – Option 4 (slide 9): * This option has been put up by different people. Addresses Compliance issues. * Like this option – opt out is good, that the registrar can remove the lock as long as there is agreement. * For Compliance – is there a requirement for documentation? * The extra lock doesn’t add security. * Two things: The transfer lock after COR is causing problems so if the registrant can remove that might address those complaints, but would there be more domain thefts? * Have to consider whether this adds anything. Have discussed that COR doesn’t cause domain theft. * Sounds like we are adding complexity without added security. Can we get the data we requested from Compliance? * This feels like a security measure but not sure it is and also adds cost and risk. Discussion --- Option 5 (slide 11): * Run into a whole bunch of operational issues. * Seems difficult to enforce. * Not sure the benefit outweighs the added complexity. Discussion – Option 6 (slide 13) * Any additional thoughts? * Good support for an argument to separate these processes, such as not making the 5-day window being a dependency. We aren’t solving the problem with these options, but we are creating more complexity. Seems like there is some agreement to separate COR from TAC request. 3. Poll Question 2: COR Followed by a TAC Request Of the Options discussed thus far, which can you support as a minimum requirement for Registrars when a TAC request follows a completed COR? Select your first, second, and third choices (if applicable) Option 1: No special requirements are necessary. 58% Option 2: There should be a waiting period before issuing the TAC, allowing time for objections. 58% Option 3: Before issuing the TAC, changes to RNH/Account Holder information must be verified.* 42% Option 4: Following a COR, impose a 30-day transfer lock, but allow Registrars to lift it, if agreed. 58% Option 5: Registrars must offer registrants an opt-in option for added protection. 67% Option 6: Other: _________ 83% Option 7: None of the above 42% (not making a choice) Discussion: * Looks like other/no special requirements is the favored option. * Don’t think we are looking for the exact answer today. * Last week there was agreement if there is a change of registrant the notice goes to the losing registrant. * Today it seems that there is agreement that COR is handled as a COR and a TAC request is handled separately. * Need to get some recommendations out of this. 4. AOB

1 0

Meeting Invitation | Transfer Policy Review PDP WG call | Tuesday, 09 January 2024
by Julie Bisland Dec. 19, 2023

Dec. 19, 2023

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

1 0

**15-MINUTE REMINDER** Meeting Invitation | Transfer Policy Review PDP WG call | Tuesday, 19 December 2023
by Julie Bisland Dec. 19, 2023

Dec. 19, 2023

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

1 0

**REMINDER** Meeting Invitation | Transfer Policy Review PDP WG call | Tuesday, 19 December 2023
by Julie Bisland Dec. 18, 2023

Dec. 18, 2023

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

1 0

Proposed Agenda - Meeting #112 Tuesday, 19 December 2023 at 1600 UTC
by Christian Wheeler Dec. 14, 2023

Dec. 14, 2023

Dear TPR WG members, Please find below the proposed agenda for our next call, taking place on Tuesday, 19 December 2023 at 16:00 UTC. Thank you and we look forward to seeing you all for our last call of the year. Kind regards, Christian, Caitlin, Berry, and Julie ---------- Transfer Policy Review - Meeting #112 Proposed Agenda 19 December 2023 1. Welcome and Chair updates 2. Discussion of Security Measures: COR + Registrar Transfers 3. Poll Questions 4. AOB

1 0

Notes and action items: TPR WG on 12 Dec at 1600 UTC
by Julie Hedlund Dec. 12, 2023

Dec. 12, 2023

Dear TPR WG members, Please find below the brief notes and action items from today’s meeting. The next meeting will be on Tuesday, 19 December at 1600 UTC. Kind regards, Christian, Caitlin, Berry and Julie ACTION ITEMS/HOMEWORK: None captured. Transfer Policy Review - Meeting #111 Proposed Agenda 12 December 2023 1. Welcome and Chair updates * We have this meeting and next week and then take a break – hope is to have CoR wrapped up by ICANN79. Great discussions last couple of weeks; hope we can narrow things done. * Request for updates: None provided. 2. Discussion of additional Security Measures – See attached slides a. Improper CORs Option 1 Discussion: * Status quo – what is required today. The minimal step today; do you keep this, modify it? * Within one day of completion is different from before one day. Issue of how to stop is still up for discussion. * Also should provide reseller data. This happens all the time – change of contact info is not necessarily CoR. * One suggestion though is to be specific by saying to "provide REGISTRAR contact information for questions". * Two points: 1) Notification in first bullet should be to previous registrant and new; 2) don’t think this is responsive to an improper CoR but to any CoR. * This is just a change of registrant – change of registrar was in our Group 1a discussions/requirements. * We don’t know what it is – why there is a modification of data. Then you have a process where something isn’t right – there is a next step. Until that time you don’t know if it’s improper or not. * Something for the group to consider here: Note that there is connective tissue back to the whois accuracy specification. Wonder, as part of this of these first 3 steps, or maybe a new number 4, where the whois accuracy specification may be invoked. So I'd ask that the group consider that because it's conceivable that some of these changes to contact information will trigger that part of the specification. But I don't think we dove into the details enough about what happens when the tag is requested, and it is understood that the primary communication methods have been changed. And so the group still may want to consider that. * Group 1a was focused just on that registrar transfer. And then a change of registrar is initiated. To your point on Barry, on the whois accuracy specification in the RAA, and that's something that we're contractually obligated as registrars to do. So that has to occur no matter what this policy says. So II think that that's a good call out there. The other thing I was thinking about as you're describing it was the annual whois reminder. When we send out that reminder it'll probably trigger a lot of these notifications here. * From the registrar's perspective the less friction with these things and less notifications and emails the better, and to a large degree same for the registrant. At what point in the process would a registrar do the whois accuracy verification with a change of registrant? Would it be prior to the * registration with the new registration data? If so, that would seem to require an affirmative action of the new registrant. And if that is an email that's going out requesting an affirmative action of the new registrant, which is obviously kind of friction, and one that's unavoidable because of the whois accuracy verification requirements, then it wouldn't seem to be too much of a stretch to also require the losing registrar to make that affirmative action by, you know, either approving right away or taking some action to stop the transfer because they didn't approve it. * So there's whois accuracy policy. There's who is data reminder policy. Those both touch registration data. They could be triggered by a transfer of ownership or contact update. But although those processes overlap, we do need to be careful to keep them separate mentally. So, for example, there could be a domain where the contact info is updated. So it triggers, whatever CoR process we're going to have. But it would be updated to a data set that has already been verified because that same person’s data set is owned by a different domain. So that's a situation where we have a CoR process, but not a whois accuracy policy process being triggered. So, they overlap. But they are different, and we should keep them mentally separate. Option 2 Discussion: * This isn’t current policy; it adds a requirement. * Most away from the wording “must investigate and respond” – make sure there is an outcome (DNS abuse negotiations). * From experience there is barely anything to investigate. * So for situations where send a reply with no further action is appropriate, what can we require in the policy? * "Must investigate and take appropriate action as applicable" ? * Unless it is a very valuable domain name (million $+) there is no recourse. The piece missing is for the registrant to do something independently. * The above point is always going to be problematic. * The TDRP discussion – we talked about having a registrant option, maybe that includes CoR. * If you want a frictionless CoR you need to empower the registrant. * From the data, there are very few improper CoRs. Don’t think it’s possible to put all these red lights in policy – will likely need to be handled by the registrars. * Caution that we’ve already talked about registrants in change of registrars – disputes in change of registrant is more complex and don’t know that a registrant-initiated dispute would be the right mechanism. Maybe a short – 30 day? – lock with an opt out? * There is more than one way to give a registrant agency; what if we went with the bare minimum – then protection from ICANN is minimal so registrants purchase other protection beyond the scope of the transfer policy. So the policy says we can’t protect registrants. * What we’ve heard is the current policy isn’t working. We are responding to what people are asking for, not necessarily a minimal policy. * We have several options and they get more specific. * It’s not that (domain theft) occurs often, but that when it occurs it is destructive. * What I am hearing is option 1 makes sense and maybe that there is something the registrar should do (option 2) “as appropriate. Option 3 Discussion: * This stating registrars have to offer an appeals process; option 4 would provide more details. * Question: Why isn’t the fallback just to confirm that the registrant of record made the change and the new registrant? Answer: It can get more complicated than just going back to the prior registrant. * Sometimes these can be very complex. * Would like to know from registrars that have them why they have an appeals process and how it works – or registries. * Very small registrars can’t/won’t do this. The more policy you put in the harder it is – have to think about balance. * Should be left to registrars – not sure we need a policy; but not opposed to a requirement to offer the option as long as it’s required of all registrars. * Can’t see a lawyer advising a registrar to have an appeals process – but registrars are already doing this; you are regulating for the worst actors. * What you are trying to do with the requirement for an appeals process is having the registrar to take the role of the court. This currently is an informal process. Don’t want to have the liability (if it’s a requirement) if we get it wrong. * There shouldn’t be a policy to have a process that doesn’t say what that process is. b. COR + Registrar transfers [Deferred for lack of time]. c. Poll questions There will be two sets of poll questions, first following the 2.a. discussion, then following the 2.b. discussion. They will look like this: (2.a.) 1. Of the Options discussed thus far, which can you support as a minimum requirement for Registrars when an improper COR occurs? Select your first, second, and third choices (if applicable) Option 1: Registrars must provide contact information for questions (current policy) – 50% Option 2: Registrars must investigate/respond to reports of improper CORs - 83% Option 3: Registrars must provide a dispute/appeal process to correct improper CORs - 83% Option 4: Registrars must provide an appeal process with specific criteria to correct improper CORs - 67% Option 5: Other - 58% Option 6: None of the above 17% 2. If you selected "Other", please explain: ____________________ Poll Questions and Wrap-Up Discussion: * Option 4 would be the most prescriptive. * Sounds like people were comfortable with option 1 and maybe option 2 with wording changes. * Option 1: strike through on the lock – not strike through. One of the options to come is retaining that lock. * Are the options cumulative? (2.b.) [Deferred for lack of time]. Of the Options discussed thus far, which can you support as a minimum requirement for Registrars when a TAC request follows a completed COR? Select your first, second, and third choices (if applicable) Option 1: No special requirements are necessary. Option 2: There should be a waiting period before issuing the TAC, allowing time for objections. Option 3: Before issuing the TAC, changes to RNH/Account Holder information must be verified.* Option 4: Following a COR, impose a 30-day transfer lock, but allow Registrars to lift it, if agreed. Option 5: Registrars must offer registrants an opt-in option for added protection. Option 6: Other Option 7: None of the above 4. If you selected "Other", please explain ________________ 3. AOB

1 0

Post Call | Transfer Policy Review PDP WG | Tuesday, 12 December 2023
by Julie Bisland Dec. 12, 2023

Dec. 12, 2023

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

1 0

Meeting Invitation | Transfer Policy Review PDP WG call | Tuesday, 19 December 2023
by Julie Bisland Dec. 12, 2023

Dec. 12, 2023

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

1 0