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

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

March 8, 2022

Dear TPR WG Members, Please find below the notes and action items from today’s session at ICANN73. The next TPR WG meeting will be on Tuesday, 22 March 2022 at 16:00 UTC. Note that there will be no meeting next week on Tuesday, 15 March. Best regards, Emily, Julie, Berry, and Caitlin Action Items: Continued deliberations on Denial of Transfers (NACKing) (60 minutes) -- see: Working document [docs.google.com]<https://urldefense.com/v3/__https:/docs.google.com/document/d/1L2bZnhJUY3Vx…> 3.7.1: If we want to expand beyond “fraud” or clarify. WG members should suggest new language. 3.7.2: WG members to review and suggest language relating to clarify the dispute and requested by issue. 3.8.1: Staff to add the suggestion to remove “pending” and to change “informed of” to “notify”. 3.9.3: Add language to be more explicit on the order of applicability and reorder the list as MUST, MAY, MAY NOT. WG members are requested to suggest edits to make it more clear. 3.9.3: Staff to research where the language of 3.9.5 was developed and the context/rationale. In general staff to review the entire list (MAY, MUST, MAY/MUST NOT) as a package and see which might be combined/eliminated/changed. Bulk Use Cases: WG members to look at bulk transfer charter questions in the charter<https://gnso.icann.org/sites/default/files/file/field-file-attach/draft-cha…> on bulk use of AuthInfo codes, specifically b5, b6, and b7. Transfer Policy Review Phase 1 - Meeting #39 Tuesday 08 March 2022 at 14:30 UTC 1. Roll Call & SOI updates (5 minutes) 2. Welcome & Chair updates (5 minutes) * Just a couple of items left to talk about in Phase 1 before starting on drafting the recommendations. * The WG is on schedule. * RySG is looking at a couple of questions for us and will provide an update when ready. 3. Continued deliberations on Denial of Transfers (NACKing) (60 minutes) -- see: Working document [docs.google.com]<https://urldefense.com/v3/__https:/docs.google.com/document/d/1L2bZnhJUY3Vx…> Charter Question: h1) Are the current reasons for denying or NACK-ing a transfer sufficiently clear? Should additional reasons be considered? For instance, ICANN Contractual Compliance has observed difficulties from registrars tying transfer denials involving domain names suspended for abusive activities to the denial instances contemplated by the Transfer Policy; or should any reasons be removed? In considering this question, the WG may wish to consider: * Should any or all of the reasons that registrars MAY NACK a transfer be changed to MUST NACK to promote consistency and reduce potential registrant confusion?Contractual Compliance has noted that many registrars and registrants remain confused by the terminology used in I.3.9.1, “Instances when the requested change of Registrar MAY NOT be denied include, but are not limited to: 3.9.1 Nonpayment for a pending or future registration period.” Does the Working Group have suggestions for clarifying this language, or does it believe it should remain as is? Discussion of Comments (beginning on page 1): 3.7.1 Evidence of fraud. * Does “fraud” need to be further defined to distinguish between “fraud” as it refers to the legitimacy of the transfer itself vs. “fraud” in related to the content of the website? It was noted that there is not currently evidence that this provision has been problematic to implement with the current language, so fraud may not need to be further defined. * Agree we need more than just “fraud” because some abuse might not considered fraud. * Abuse is an undefined concept at ICANN. Why would we try to define it here? * There are other types of abuse such as spam might not be fraud but might be abuse and still blocked. * RAA could be too broad and provide too many reasons for denial of transfer. * Broad terms like “abuse” and “fraud” could lead to too many reasons for denial. * In theory the registration agreement can say the customer must send weekly messages to registrar by carrier pigeon. Does not violate RAA/Consensus policies, but then failure to send the pigeon message could lead to denial of transfer. * But getting very specific doesn’t allow the policy to grow, but if “fraud” as currently referenced in the policy has not been a problem then leave it? Or is there better language? Maybe work on the scope of the words. ACTION ITEM: If we want to expand beyond “fraud” or clarify. WG members should suggest new language. 3.7.2 Reasonable dispute over the identity of the Registered Name Holder or Administrative Contact. * Potential edits: “reasonable concern [over the identity of the Registered Name Holder], that the transfer was not requested by the RNH, [or that the transfer request is otherwise not valid].” * Say something like if the transfer was done against the will of the RNH (or intent). * We should word it as "Reasonable concern that the transfer…" * Look at this language and suggest revisions. ACTION ITEM: WG members to review and suggest language relating to clarify the dispute and requested by issue. 3.7.3 Edits are acceptable. 3.7.4 and 3.7.5 Support for moving to MUST. 3.8.1 – 3.8.4 – Support to keep in this section. 3.8.1 A pending UDRP proceeding that the Registrar has been informed of. * Remove “pending”. Want to make sure there is an active UDRP in process, a potential dispute is not a reason to block. * Some prefer the original language. ACTION ITEM: Staff to add the suggestion to remove “pending” and to change “informed of” to “notify”. Poll to aid in discussion (continued from meeting #38): NOTE: Some of the provisions below are only displayed in part due to character limits in the polling tool. In such cases, the text ends with “. . .” Reasons that the Registrar of Record MAY NOT deny a transfer request (Cont.) 3.9.2 No response from the Registered Name Holder or Administrative Contact. * Leave as MAY NOT and keep language as-is – 35% * Leave as a MAY NOT but make edits – 29% * Remove from list – 24% * Other/don’t know – 12% Discussion: * There is no requirement for a direct response from the RNH. * Prior to the acknowledgement – think we can remove it from the list. Don’t think it’s needed, but might keep it if revised. No response is required so it is redundant? * Think we could keep it but at least remove the Administrative Contact. WG members review to see how we can make it more clear. 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. * Leave as MAY NOT and keep language as-is – 50% * Leave as a MAY NOT but make edits – 22% * Remove from list – 11% * Other/don’t know – 17% Discussion: * We can still have the ability to block abusive domain names. * Should try to use standardized terms. Use “ClientTransferProhibited” – use the EPP status. * ICANN has kept it flexible rather than requiring a specific EPP status – could interfere with some business models. * Do need to find a common understanding. * Do we want the lock to be specific or flexible? * What is our goal with this item. If the RNH can unlock the domain but didn't, then it's OK to deny the transfer because the domain is locked. If the RNH has no way to unlock the domain, then the lock can't prevent the transfer. * From an ICANN perspective the ClientTransferProhibited prevents the transfer, but from a gaining registrar's perspective it can also mean that it will be retried as they would expect the Registered Nameholder to be able to remove the lock at the losing registrar. * Thought the concern was, if the Registrar locks for abuse that lock should prevent the transfer, regardless of what the RNH wants to do. * We have to make these clear as to why you can do this or not – what type of lock are we talking about? We should be clear. * Make it clear that if there is a lock for abuse then it is not eligible for transfer. These don’t apply. * 3.18.1 Registrar shall maintain an abuse contact to receive reports of abuse involving Registered Names sponsored by Registrar, including reports of Illegal Activity. Registrar shall publish an email address to receive such reports on the home page of Registrar's website (or in another standardized place that may be designated by ICANN from time to time). Registrar shall take reasonable and prompt steps to investigate and respond appropriately to any reports of abuse. * If one supersedes the other we should make that explicit. Don’t think any of these MAY NOT items supersedes a MAY or MUST. * This still is applicable but maybe we need to change the language. Change the order – MUST, MAY, MAY NOT. The prior sections override. * Could we ask ICANN Compliance for an example of this item, or where there’s been a disagreement on how to apply them. * ICANN Compliance: Example – registrant comes to Compliance and says they can’t unlock a domain name and registrant is not responding. Registrant does not have access to the account. From Compliance failed access to the account is out of scope for transfer policy. Respond that the registrar has provided the unlocking via the account. Educate the registrant and registrar. * [Additional Candidate Recommendation xx: If a Gaining Registrar requests a transfer and an inter-registrar transfer lock is in place, the transfer must not proceed.] ACTON ITEM: Add language to be more explicit on the order of applicability and reorder the list as MUST, MAY, MAY NOT. WG members are requested to suggest edits to make it more clear. 3.9.4 Domain name registration period time constraints, other than during the first 60 days of initial registration, during the first 60 days after a registrar transfer, or during the 60-day lock following a COR pursuant to Section II.C.2. * Leave as MAY NOT and keep language as-is – 47% * Leave as a MAY NOT but make edits – 42% * Remove from list – 0% * Other/don’t know – 11% Discussion: * Is there an example of this? ICANN Compliance: 2 years after renewal – don’t fall into the allowed non-transfer period. * Has anybody tried to deny? Think this is a catch-all situation – the only time constraints are those that we have explicitly enumerated. * So this is saying that except for the no-transfer times we already agreed on, the Rr can't deny a transfer due to what time it is? * Poll shows strong support for leaving it on the list but with edits. * Based on where we sit today this item seems like a catch all for the inconsistencies that exist in the market today. The WG seems to be coalescing that there is going to be a standard create lock of X duration and a post-transfer lock of X duration, and if assume that core doesn’t change except duration and all will be MUST, wonder if this item will need to be necessary. * If we agree on the timelines maybe we revisit this. * Picked 2nd option, I think that will let us adjust the time period and also maybe consider including that expired domains can be transferred. Not sure if that goes here or if it is a new one? * Do we need to specify if we agree on the timeframes where we can deny. If not in those then you can’t deny. Or do we need to be explicit? * It might not be intuitive that you can’t deny a transfer during expiry, so I feel like it should be mentioned. * Maybe add as an implementation note? * Think about adding a footnote to this but keeping it. 3.9.5 General payment defaults between Registrar and business partners / affiliates in cases where the Registered Name Holder for the domain in question has paid for the registration. * Leave as MAY NOT and keep language as-is – 59% * Leave as a MAY NOT but make edits – 35% * Remove from list – 0% * Other/don’t know – 6% Discussion: * Poll shows strong support for keeping this with edits. * Need clarification on this scenario. * Maybe use the language that is in the RAA. This wording here is old and predate reseller. * In practice, some registrar may advise not to transfer (but not deny) before 45 days after renewal so that they do not lose renewal period. * Steinar posted to the list about registrars charging for the transfer – what if RNH cannot pay? Should a registrar be able to block a transfer even if the registration is paid for? * Maybe an open question here is whether this should be even more general. * From the policy: .10 The Registrar of Record has other mechanisms available to collect payment from the Registered Name Holder that are independent from the Transfer process. Hence, in the event of a dispute over payment, the Registrar of Record must not employ transfer processes as a mechanism to secure payment for services from a Registered Name Holder. Exceptions to this requirement are as follows: (i) In the case of non-payment for previous registration period(s) if the transfer is requested after the expiration date, or (ii) In the case of non-payment of the current registration period, if transfer is requested before the expiration date. * Charging a fee is no explicitly prohibited. * Think this should be changed to MUST NOT deny. * But registrar cannot block for failure to pay the transfer fee. * MUST NOT seems more appropriate, but ask staff to research where this language came from/context/rationale. * What we may be seeing is an artifact from years ago before there was a transfer policy. * Staff next step will be to review these as a package including reordering. ACTION ITEM: Staff to research where the language of 3.9.5 was developed and the context/rationale. In general staff to review the entire list (MAY, MUST, MAY/MUST NOT) as a package and see which might be combined/eliminated/changed. 4. Begin discussion on bulk use cases: ACTION ITEM: WG members to look at bulk transfer charter questions in the charter<https://gnso.icann.org/sites/default/files/file/field-file-attach/draft-cha…> on bulk use of AuthInfo codes, specifically b5, b6, and b7. 5. AOB (5 minutes) * Next call: 22 March 2022 1600 UTC. Note that there will be no meeting next week on Tuesday, 15 March.

1 0

ICANN Zoom room requirements: Zoom Logins: First & Last Name/ Surname Only
by Nathalie Peregrine March 8, 2022

March 8, 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

**STARTING IN 2 MINUTES** Transfer Policy Review PDP WG call / ICANN73
by Julie Bisland March 8, 2022

March 8, 2022

Dear all, As a reminder the TPR PDP WG meeting being held during ICANN73 takes place today, Tuesday, March 08 2022 at 10:30 local time (14:30 UTC). * ICANN73 wiki agenda page: https://community.icann.org/x/ywEiCw * Please be sure you are registered for ICANN73! * Zoom participation links will be published 24 hours before the ICANN73 sessions start. For more information on how to participate, visit: https://73.schedule.icann.org/attend [73.schedule.icann.org]<https://urldefense.com/v3/__https:/73.schedule.icann.org/attend__;!!PtGJab4…> Thank you. Kind regards, Julie

1 0

Staff Action Item: Origins of language in 1.A.3.7.3
by Emily Barabas March 7, 2022

March 7, 2022

Dear Working Group members, Following Tuesday’s WG call, staff had an action item to research the origins of the following sentence, in bold, included in one of the reasons that a transfer may be denied: 1.A.3.7.3: No payment for previous registration period (including credit card charge-backs) if the domain name is past its expiration date or for previous or current registration periods if the domain name has not yet expired. In all such cases, however, the domain name must be put into "Registrar Hold" status by the Registrar of Record prior to the denial of transfer. This sentence appears in the 2002 ICANN DNSO Transfers Task Force Final Report & Recommendations<http://www.dnso.org/dnso/notes/20030212.NCTransferTF-gaining-and-losing-reg…>, under recommendation 24. In the Report section Other Observations and Considerations, the following additional text is included “9. It is recommended that the Losing Registrar use the EPP or RRP command set equivalent of “Registrar Hold” prior to receiving a transfer notification from the Registry as a mechanism to secure payment from a Registrant in the event of non-payment. The Losing Registrar should not use the EPP or RRP command set equivalent of “Registrar Lock” for this same purpose.” We found some additional discussion on page 13 of the 2008 GNSO Final Report on Inter-Registrar Transfer Policy:<https://gnso.icann.org/sites/default/files/filefield_6444/final-report-irt-…> Clarification of Reasons for Denial<https://gnso.icann.org/sites/default/files/filefield_6444/final-report-irt-…>, which was carried over from the Issue Report: “"4.2.8 The current provision in the Inter-Registrar Transfer Policy also provides that prior to denying any transfer requests for non-payment under this clause, a registrar must have placed the domain name on “Registrar Hold” status. This does not appear to be the usual practice, with many registrars using “Registrar Lock” status instead. It should be noted that “Registrar Hold” removes the name from the zone and causes it not to resolve, while a name in “Registrar Lock” may continue to function but will not be able to be transferred. As part of the discussion regarding this provision, it may be helpful to consider whether one is preferable to the other in instances of nonpayment.” It does not appear that the subsequent policy development work resulted in any changes to the language referenced above. 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/>

2 2

Registrar charging fees given out the TAC and transfer-out
by Steinar Grøtterød March 5, 2022

March 5, 2022

Dear all, I have recently been informed that some registrars charge a fee for issuing a TAC to the Registered Name Holder. The examples given to me is a fee of USD 250(!) for sending a TAC to the RNH. I have also been given examples of registrar charging for accepting a transfer out, purely for the «job» that has to be done. My question is whether this (IMHO) unfriendly practices should be discussed in our working group and (maybe) incorporated in the new Inter-Registrar Transfer Policy. Regards, Steinar Grøtterød At-Large

5 4

Proposed agenda for ICANN73 session on Tuesday 8 March 2022 at 14:30 UTC
by Emily Barabas March 4, 2022

March 4, 2022

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

1 0

IMPORTANT - Session change ICANN73: New gTLD Subsequent Procedures: Operational Design Phase
by Julie Bisland March 3, 2022

March 3, 2022

Dear all, ⚠️ Due to scheduling conflicts the ICANN73 session New gTLD Subsequent Procedures: Operational Design Phase will take place at a different time and date. ⚠️ Previously scheduled for Wednesday 9 March 2022 at 09:00 am local time (13:00 UTC), it will now take place on Monday 7 March 2022 at 12:30 local time (16:30 UTC). To update your calendars please follow the below steps: 1. Remove the entry for New gTLD Subsequent Procedures: Operational Design Phase on Wednesday 9 March 2022 09:00 am local time. 2. If you had already selected the new gTLD Subsequent Procedures: Operational Design Phase entry in your “My Agenda” on the ICANN73 website, you will not need to re-select it. You will however need to export that session once again to your own calendar. 3. Please refer to the attached “How to Get Organised” email to refresh your memories on how to download sessions! Please reach out to gnso-secs(a)icann.org<mailto:gnso-secs@icann.org> if you have any questions. Kind regards, Nathalie

1 0

TPR-P1 // 28 Feb 2022 Project Package
by Berry Cobb March 2, 2022

March 2, 2022

Dear WG, Please find a link below to project package for the TPR-P1 PDP (28 Feb 2022). 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,7 – Group attendance for plenary meetings 6. Page 08 – Project Plan, Gantt chart 7. Page 09 – Work plan & Action items for the period Key points: * The WG is proceeding according to plan against the charter topics/questions. 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

CORRECTION re: Next Call / Meeting Invitation | Transfer Policy Review PDP WG call | Tuesday, 22 March 2022
by Julie Bisland March 1, 2022

March 1, 2022

As a reminder the meeting being held during ICANN73 will take place on Tuesday, March 08 2022 at 10:30 local time (14:30 UTC). * ICANN73 wiki agenda page: https://community.icann.org/x/ywEiCw * Please be sure you are registered for ICANN73! * Zoom participation links will be published 24 hours before the ICANN73 sessions start. For more information on how to participate, visit: https://73.schedule.icann.org/attend [73.schedule.icann.org]<https://urldefense.com/v3/__https:/73.schedule.icann.org/attend__;!!PtGJab4…> Find below the meeting details for the TPR call taking place after ICANN73. ************************************************************* 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 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

Canceled: Transfer Policy Review PDP WG
by ICANN Policy Calendar March 1, 2022

March 1, 2022

Meeting: Transfer Policy Review PDP WG Date/Time: Recurring every Tuesday at 16:00 UTC for 90 minutes, 01 March 2022 through 26 April. 2022 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> Wiki Agenda meeting pages 2022: https://community.icann.org/x/Z4HOCg 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 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