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

Proposed agenda for meeting #11 on Tuesday 3 August 2021 at 16.00 UTC
by Emily Barabas July 29, 2021

July 29, 2021

Dear Working Group members, Please find below the proposed agenda for the meeting scheduled to take place on Tuesday 3 August 2021 at 16.00 UTC. As a reminder, please review and think about the principles and strawman list beginning on page 8 of the AuthInfo Codes Working Document<https://docs.google.com/document/d/1O9PAnxWFUuPofLQCWIQXz8lT7KEj1HgH3b_obh0…>. Please add comments and suggested edits, including “pros” and “cons” of the proposed principles/security measures, considerations the WG should take into account, clarifications to the text, and potential alternatives. This input will be discussed on Tuesday’s call. Please also come prepared to share any input you have about draft recommendations 1 and 2 on page 2 of the AuthInfo Codes Working Document<https://docs.google.com/document/d/1O9PAnxWFUuPofLQCWIQXz8lT7KEj1HgH3b_obh0…>. Kind regards, Emily, Julie, Caitlin, and Berry Transfer Policy Review Phase 1 - Meeting #11 Proposed Agenda Tuesday 3 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 (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…>. 4. AOB (5 minutes) - Next meeting: 10 August 2021 @ 16.00 UTC Emily Barabas GNSO Policy Development Support Manager Internet Corporation for Assigned Names and Numbers (ICANN) Phone: +31 (0)6 84507976 www.icann.org<http://www.icann.org/>

1 0

Post Call | Transfer Policy Review PDP WG | Tuesday, 27 July 2021 at 16:00 UTC
by Andrea Glandon July 27, 2021

July 27, 2021

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

1 0

Notes and action items - TPR Meeting #08 - 27 July 2021
by Julie Hedlund July 27, 2021

July 27, 2021

Dear TPR Working Group, Please find below the notes and action items from today’s TPR meeting. The next meeting will be Tuesday, 03 August at 16:00 UTC. Best regards, Emily, Caitlin, Berry, and Julie -- Action Items ACTION ITEM: Homework for WG members – add comments and suggested edits to the principles and strawman list at: https://docs.google.com/document/d/1O9PAnxWFUuPofLQCWIQXz8lT7KEj1HgH3b_obh0… including anything that might be missing, clarifications/changes to terminology, impacts on use cases, etc. Also see the project workplan [docs.google.com]<https://urldefense.com/v3/__https:/docs.google.com/spreadsheets/d/1FunWaz3g…> for action items. Notes: Transfer Policy Review Phase 1 - Meeting #08 Proposed Agenda Tuesday 27 July at 16.00 UTC 1. Welcome & Chair updates 2. Presentation of outputs from the small group and continued discussion of Auth-Info Codes: See new section at the end of the Working Document (beginning on page 7): https://docs.google.com/document/d/1O9PAnxWFUuPofLQCWIQXz8lT7KEj1HgH3b_obh0… [docs.google.com]<https://urldefense.com/v3/__https:/docs.google.com/document/d/1O9PAnxWFUuPo…>. * Small Team has been meeting for the last two weeks on Auth-Info Codes. They will present their thoughts to us. There is some additional work that will need to happen in the full WG. * Project Plan was introduced to the GNSO Council at the meeting on 22 July. There were no questions from Council. Presentation from Jim Galvin on Principles: * “Transfer Authorization Code (TAC) is an Identity Credential that upon presentation by a registrant identifies that registrant as the owner of its corresponding domain name.” * This is very important and we should try to come to agreement on it. * “Should only exist at registry when a transfer is in progress”: * This suggests that regardless of when a registrar creates a TAC, it is not passed to the registry unless a transfer is in progress. * “Must be unique per registrant and per domain name”: * The value must be safe and secure and not reproducible outside of the registrar, i.e., one-time password. If there is a request for another one just generate a new password. * “Must not be retrievable from the registry”: * A registrar can set it but a registry will never respond with it, other than to validate if an accurate one was submitted (rate limits to avoid brute force). * A registrar would set a “NULL” or send new TAC to remove it from the registry or update the existing TAC. * “Registrars should manage any TTL scheme”: * Important principle that registrar is completely in control of the transfer process. * “SHOULD be updated at the registry upon completion of owner change process.”: * This is up for discussion. * Important part is the first principle: If you have this code you are the owner for the purpose of transfer. There was discussion on the Small Team about AuthInfo Codes for purposes other than transfers. Look at those to see if these purposes are still legitimate and if there’s another way to achieve the purpose. Presentation from Jody Kolker on the Strawman List: * The registrar creates Auth-Info code and it is hashed at the registry. * It’s not stored at the registrar and stored at the registry. * Discussed issues of how it would be stored if not at the registry. If the registrar doesn’t have the Auth-Info Code then it can’t prove identity. This is up for discussion. * Two-factor authentication, not necessarily using cell phone number, could be a security question. * Discussed that the registrant would have to have a second form of technology, such as a smart phone. * 32-character min [Alternative: 16 characters]. * This is what we wanted to get to. Aren’t there right now. * Require uppercase and lowercase letters, numbers, and special characters. Prohibit use of dictionary words. +Homoglyph consideration (0 vs O) see below.** * Discussed homoglyphs and said they shouldn’t be able to use those. * Registry check to ensure Auth-Code meets minimum requirements -- to discuss with the full group. * We would like them to check, but this needs to be discussed with the full WG. * Timeout after a certain number of requests to initiate a transfer. (Why: Adds integrity to legitimate xfer [slow manual incumbent, automated gaining process], guards against illegitimate [brute force]. What: ServerTransferLock at threshold x, notice to incumbent registrar, other) * This needs to be discussed. Not sure “timeout” is the right word. This would require work by the registry to alert the registrar. * Can Transfer Lock status affect requesting/updating auth code in addition to just blocking a transfer request? * There are open questions on a lot of these. Discussion: * Seems that there are two competing factors: 1) is the Auth-Info Code strong enough? 2) is it useable? In pushing for very long strings and raising the prospect that these will have to be typed by hand (not copied) this would cause errors. Both considerations should be included. For example, you could have 16-characters broken into groups of 4. * Small Team was thinking about how to be secure and still make it useable. If it is too secure it may not be usable, but too usable it may not be secure. * Need to ask ourselves how many entities in between do we want to have access to the Auth-Info Codes – resellers? Other service providers? Or only allow directly to the registrant. Need to decide this first before other questions. * Don’t think we can say “no storage” but need to set parameters around storage. * When we talk about two-step authentication, we need to talk about when that is appropriate. The two-step now is at the registrar panel. There is no two-step after getting the Auth-Info Code. * The most important point is the discussion about the ecosystems outside of the registrars and registries. They are outside the ICANN contracts. They are using a chain of resellers. So there are questions about storage of the Auth-Info Code. They might be stored and retrieved many times by many people. Second, if we make technical difficulties in accessing the code we will lose many people. * Need to come up with good practice around storing and keeping it safe. * The registrar creates Auth-Info code and it is hashed at the registry. * It's not stored at the registrar and stored at the registry. * Two-factor authentication, not necessarily using cell phone number, could be a security question. * 32 character min [Alternative: 16 characters]. * Require uppercase and lowercase letters, numbers, and special characters. Prohibit use of dictionary words. +Homoglyph consideration (0 vs O) see below.** * Registry check to ensure Auth-Code meets minimum requirements -- to discuss with the full group. * Timeout after a certain number of requests to initiate a transfer. (Why: Adds integrity to legitimate xfer [slow manual incumbent, automated gaining process], guards against illegitimate [brute force]. What: ServerTransferLock at threshold x, notice to incumbent registrar, other) * Can Transfer Lock status affect requesting/updating auth code in addition to just blocking a transfer request? * Bulk transfers could be an issue, but this WG could work on alternatives/solutions. * On multifactor authentication and locking the domain name: Issue is that a lot of us already offer MFA, but user adoption is very low. Have to consider how to encourage adoption. Could require increased support. * On transfer lock needing to be removed before a transfer: what we see is that resellers or their customers they turn it on and off for no obvious reason. Some resellers turn it off as a default. Lot of use cases regarding when a transfer lock is present or not. * This is more of a timing issue: should you be able to receive an Auth-Info Code when a lock is on it. * The transfer lock being on might impact whether you can request an Auth-Info Code from the registrar. * Re: the second principle (comment from Sarah Wyld): “How does the losing Rr know when to send the TAC to the Ry? E.g. RNH unlocks domain on Monday; on Tuesday they obtain the authcode from the Rr (how? by viewing it in CP? clicking a button that triggers it to be emailed to them? Some of this is known to the Rr and some is not). On Friday they go to the gaining Rr to initiate the transfer, including providing the authcode to them. At what point was the losing Rr supposed to send the authcode to the Ry? If the code is always existing in the Rr system and always visible to the RNH via their CP, nothing notifies the losing Rr that the transfer is being initiated until it's already happened.” * This doesn’t seem to align with the second item on the strawman list: * When the transfer request has started, when the TAC is provided to the registrant that’s when it is stored at the registry. * In a lot of different provider control panels the Auth-Info Code is always visible. We would change that to only seeing it when the registrant requests one. Yes, the intent of the principle is that the TAC is only viewable when the registrant requests it. * A larger point to keep in mind is that this a proposal and it doesn’t match 100 percent what everyone is doing now. Need to highlight points of use that might be impacted by the principles/strawman. Some people may need to change some things to align with the principles. Question: do these principles conflict with where you are that would make you want to seek a different solution? * We could improve security if the Auth-Info code only exists for a limited period of time, is a one-time password with a TTL, and handled in the registry system, not the registrars. * Auth-Info Code is used for transfers between resellers at the same registrar. * Keep in mind that although we are talking about Auth-Info Codes in isolation, this leads into the discussion on gaining and losing FOAs. * Primary principle: If someone has this code then someone can transfer it. Need to look at all these items and what is missing in between as well as other uses. * Comment: Need to look at what is going on at the gaining and losing registrar, and what is going on at the registry, and the user interface in each instance. These principles may not be 100-percent aligned, but we tried to gather up the ideas and put them on the table for the WG. * Staff did some digging to see what diagrams we have on the current process, but some of what we have is not up-to-date. Staff could try to update it to develop a working draft reflecting the current state. What might be most useful is after we formulate recommendations that we then develop a diagram to reflect those. * Not sure if going back to all the use cases is a good way to spend our time. Instead make sure that we put out our goals and make sure that our language around those goals are technology and policy agnostic, so there is enough room for all registrars to achieve those goals without limiting use cases. * Might be helpful to have some data - high level - on what the things are that registrants complain about … as mentioned earlier, there is a use sophistication hurdle that might taint that info. * One thing that came up in the Small Team’s discussion is that there are pieces that are going to be interdependent. Such as bulk-type transfers. There are real-world scenarios where someone might be consolidating domain names. We may need to talk about whether that use case is or isn’t covered. * Goal between now and the next call is to look at the principles and strawman and add their ideas/comments and how use cases may be impacted. * Re: second principle: suggest changing to “Should only exist at registry when a transfer is [eligible to be] in progress”. New text in brackets. * Re: TTL – could have registrar manage minimum and registry manage maximum; or registrar could manage TTL or registry could manage it. Could be more manageable with the fewer parties that are doing it. * The TTL should be allowed be very short for high value domains, but it should not be common to set to 15 minutes. * A TTL should have a minimum value no less than 1-2 days. Would not want a sticky registrar to set it to 5 minutes. * Looking across registrars, the transfer lock is guarding the name. * Re: TTL could see that a registrar could set the TTL low to make it hard for a registrant to transfer. There would have to be some kind of minimum. * On this issue of whether there should be a TTL at the registry and enforced there. Need to change the way we are thinking about this: What is it we are trying to achieve, what is the goal, and who benefits? What is the security feature we get with one approach or another? If the registry controls TTL then the registrar loses control. Also, the registry can just turn it off and the registrar will get the customer service issue. Focus less on the failure points, and on what is the benefit in terms of security that the registrant gets? * Most important to decide whether to have a TTL on the Auth ID. Registry can only validate the Auth ID based on whether it’s expired or now and so that Auth ID needs to be in the registry. * If we think TTL is a needed feature – seems most agree that there should be an upper and lower limit; we should set those bounds. * If we set a TTL we always place some part of the risk with the registrant, such as registrar failure, reseller failure, etc. * The domain name has to be unlocked at the registry. If the registrar fails then the domain name can’t be transferred. If the registrar has the domain name locked, then there is no way to transfer. * It’s not actually true that if you have the Auth-Info Code you can transfer, you can’t if the registrar has locked the name. Once an Auth-Info code is set at the registry then the locks have to come off. * Seems agreement that we should have TTLs with a maximum and minimum but have not agreed on the management of the TTL. * Possible new principle: Be sure that we can override the TTL with an Auth-Info Code. Need to be able to invalidate it. ACTION ITEM: Homework for WG members – add comments and suggested edits to the principles and strawman list at: https://docs.google.com/document/d/1O9PAnxWFUuPofLQCWIQXz8lT7KEj1HgH3b_obh0… including anything that might be missing, clarifications/changes to terminology, impacts on use cases, etc. 3. AOB (5 minutes) - Next meeting: 3 August 2021 @ 16.00 UTC

1 0

Meeting Invitation | Transfer Policy Review PDP WG call | Tuesday, 03 August 2021 at 16:00 UTC
by Andrea Glandon July 27, 2021

July 27, 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 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

**Meeting begins in 15 minutes** Meeting Invitation | Transfer Policy Review PDP WG call | Tuesday, 27 July 2021 at 16:00 UTC
by Andrea Glandon July 27, 2021

July 27, 2021

Dear all, The next Transfer Policy Review PDP WG call is scheduled for Tuesday, 27 July 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/YATpCQ Check your time zone: https://tinyurl.com/upysw9e6 [tinyurl.com]<https://urldefense.com/v3/__https:/tinyurl.com/upysw9e6__;!!PtGJab4!sycQoPM…> 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 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

Proposed agenda for meeting #08 on Tuesday 27 July 2021 at 16.00 UTC
by Emily Barabas July 26, 2021

July 26, 2021

Dear Working Group members, Please find below the proposed agenda for the meeting scheduled to take place tomorrow, Tuesday 27 July 2021 at 16.00 UTC. For those who would like to review the notes and recording from the small group call that took place today, and updated document is attached including these materials. Kind regards, Emily, Julie, Caitlin, and Berry Transfer Policy Review Phase 1 - Meeting #08 Proposed Agenda Tuesday 27 July 2021 at 16.00 UTC 1. Roll Call & SOI Updates (5 minutes) 2. Welcome & Chair updates (5 minutes) 3. Presentation of outputs from the small group and continued discussion of AuthInfo Codes (75 minutes): See new section at the end of the Working Document (beginning on page 7): https://docs.google.com/document/d/1O9PAnxWFUuPofLQCWIQXz8lT7KEj1HgH3b_obh0…. 4. AOB (5 minutes) - Next meeting: 3 August 2021 @ 16.00 UTC Emily Barabas GNSO Policy Development Support Manager Internet Corporation for Assigned Names and Numbers (ICANN) Phone: +31 (0)6 84507976 www.icann.org<http://www.icann.org/>

1 0

**Reminder** Meeting Invitation | Transfer Policy Review PDP WG call | Tuesday, 27 July 2021 at 16:00 UTC
by Andrea Glandon July 26, 2021

July 26, 2021

Dear all, The next Transfer Policy Review PDP WG call is scheduled for Tuesday, 27 July 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/YATpCQ Check your time zone: https://tinyurl.com/upysw9e6 [tinyurl.com]<https://urldefense.com/v3/__https:/tinyurl.com/upysw9e6__;!!PtGJab4!sycQoPM…> 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 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

Meeting Recordings and Notes - Small Group on AuthInfo Codes
by Emily Barabas July 23, 2021

July 23, 2021

Dear Working Group members, For those of you who are interested in catching up with the work of the small group focused on AuthInfo Codes, please find attached recordings of the three small group meetings held over the last two weeks, as well as notes from those meetings. The small group will have one more meeting on Monday 26 July at 14:00 UTC to wrap up its work for delivery to the full group. The full group will be discussing the small group’s outputs during Tuesday’s call (27 July). After the small group call this coming Monday, staff will share the additional notes and the recording, as well as the agenda for Tuesday’s full group call and supporting materials. Kind regards, Emily, Julie, Caitlin, and Berry Emily Barabas Policy Manager, GNSO Policy Development Support Internet Corporation for Assigned Names and Numbers (ICANN) Phone: +31 (0)6 84507976 www.icann.org<http://www.icann.org/>

1 0

Re: [GNSO-TPR] Transfer Policy Review PDP WG Homework
by Emily Barabas July 20, 2021

July 20, 2021

Dear Working Group members, As a reminder, there are two “homework” items for Working Group members to focus on between now and our meeting on 27 July: * Please add your comments and suggested edits to this document on the definition of the Transfer Authorization Code: https://docs.google.com/document/d/1sML9k6laK67aS-dmHSmxrf80yF_ktI0K8G_zspX… [docs.google.com]<https://urldefense.com/v3/__https:/docs.google.com/document/d/1sML9k6laK67a…> * Please begin to think about charter question a6 on Additional Security Measures (see text below). If you have any questions, please respond on the mailing list. Kind regards, Emily, Julie, Caitlin, and Berry From: GNSO-TPR <gnso-tpr-bounces(a)icann.org> on behalf of Roger D Carney via GNSO-TPR <gnso-tpr(a)icann.org> Reply to: Roger D Carney <rcarney(a)godaddy.com> Date: Monday, 12 July 2021 at 17:40 To: "gnso-tpr(a)icann.org" <gnso-tpr(a)icann.org> Subject: [GNSO-TPR] Transfer Policy Review PDP WG Homework Dear Working Group members, As discussed on our last call, we will not be meeting on the 13th or 20th of July. During this time, the small team will create proposals related to the charter questions on AuthInfo Codes/Transfer Authorization Codes (which we will review at our next meeting on July 27th), and additionally, I would like the entire group to focus on the following between now and our meeting on the 27th: * The Working Group appears to generally agree that we should use a standard term “Transfer Authorization Code” and should recommend a definition for the TAC. Staff has prepared a working document to assist with refining associated recommendation language. Please add your comments and suggested edits directly to the document: https://docs.google.com/document/d/1sML9k6laK67aS-dmHSmxrf80yF_ktI0K8G_zspX… [docs.google.com]<https://urldefense.com/v3/__https:/docs.google.com/document/d/1sML9k6laK67a…> * Please begin to think about charter question a6 on Additional Security Measures. This is the next topic on our work plan following AuthInfo Codes/Transfer Authorization Codes: a6) Survey respondents noted that mandatory domain name locking is an additional security enhancement to prevent domain name hijacking and improper domain name transfers. The Transfer Policy does not currently require mandatory domain name locking; it allows a registrar to NACK an inter-registrar transfer if the inter-registrar transfer was requested within 60 days of the domain name’s creation date as shown in the registry RDDS record for the domain name or if the domain name is within 60 days after being transferred. Is mandatory domain name locking an additional requirement the Working Group believes should be added to the Transfer Policy? If you have any questions, please share them on list. Kind regards, Roger

1 0

Transfer Policy Review PDP WG Homework
by Roger D Carney July 12, 2021

July 12, 2021

Dear Working Group members, As discussed on our last call, we will not be meeting on the 13th or 20th of July. During this time, the small team will create proposals related to the charter questions on AuthInfo Codes/Transfer Authorization Codes (which we will review at our next meeting on July 27th), and additionally, I would like the entire group to focus on the following between now and our meeting on the 27th: * The Working Group appears to generally agree that we should use a standard term "Transfer Authorization Code" and should recommend a definition for the TAC. Staff has prepared a working document to assist with refining associated recommendation language. Please add your comments and suggested edits directly to the document: https://docs.google.com/document/d/1sML9k6laK67aS-dmHSmxrf80yF_ktI0K8G_zspX… * Please begin to think about charter question a6 on Additional Security Measures. This is the next topic on our work plan following AuthInfo Codes/Transfer Authorization Codes: a6) Survey respondents noted that mandatory domain name locking is an additional security enhancement to prevent domain name hijacking and improper domain name transfers. The Transfer Policy does not currently require mandatory domain name locking; it allows a registrar to NACK an inter-registrar transfer if the inter-registrar transfer was requested within 60 days of the domain name's creation date as shown in the registry RDDS record for the domain name or if the domain name is within 60 days after being transferred. Is mandatory domain name locking an additional requirement the Working Group believes should be added to the Transfer Policy? If you have any questions, please share them on list. Kind regards, Roger

1 0