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

Notes and action items - TPR WG Meeting #46 - 10 May 2022 at 16:00 UTC
by Julie Hedlund May 10, 2022

May 10, 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, 17 May 2022 at 16:00 UTC. Best regards, Emily, Julie, Berry, and Caitlin Action Items: REMINDER: Deadline for submitting input on the draft Initial Report is 14 May 2022. Please see instructions via separate email for additional details. Items in the preliminary recommendations flagged for further discussion (see items highlighted in blue here [docs.google.com]<https://urldefense.com/v3/__https:/docs.google.com/document/d/1clAqB1wBeOf9…>) ACTION ITEMS: Recommendations 7, 9.2, 13.1/13.2: Return to these items. Notes: Transfer Policy Review Phase 1 - Meeting #46 Tuesday, 10 May 2022 at 16:00 UTC Proposed Agenda 1. Roll Call & SOI updates 2. Welcome and Chair Updates * Reminder of the homework of WG members going through the Initial Report draft to flag items that need to be discussed by the group. Deadline is 14 May. 3. Items in the preliminary recommendations flagged for further discussion (see items highlighted in blue here [docs.google.com]<https://urldefense.com/v3/__https:/docs.google.com/document/d/1clAqB1wBeOf9…>) 4.3: The following elements MUST be included in the “Notification of Transfer Completion”: * Domain name(s), [IANA ID(s) of Gaining Registrar(s) and link to ICANN-maintained webpage listing accredited registrars and corresponding IANA IDs. If available, the name of the Gaining Registrar(s) MAY also be included.] [Recommendation regarding Registry provision of the IANA ID/Gaining Registrar name to the Losing Registrar?] * Recall a lot of discussion that this would be nice to have, but not sure how to get those data. Registries were going to check to see if it was feasible. * IANA is an affiliate of ICANN – wondering if we could get an update from them. * Isn’t it a purely technical enhancement – it’s not available in the EPP. We need feedback from RySG. * Don’t believe the RySG has discussed this yet. Think the registries know that the information is available. Believe that it is known because that is the origin of the transfer request. Not sure if that would require a change to the EPP code. Sounds like the registries would have to provide a link to a web page for every transfer request and that seems redundant. Why not just the domain name and IANA ID of the gaining registrar. * Assumed that the registry would include that IANA ID in the EPP response to the registrar, and then the registrar would use that IANA ID and add in the website when notifying the RNH. * Maybe make this an option line item when we go to public comment and then the registries can comment. * Only one registrar uses the client ID as the IANA ID. For some registrars it’s just a number and not related to the IANA ID. We would need every client ID to become the IANA ID. * Don’t think we will get this resolved in the next month – either eliminate it or take it to public comment as a question. * The group should think about how we would want to present this in public comment. Cleanest is to remove it from the recommendation and then have a question in public comment. [Recommendation regarding retention and maintenance of records?] * Seems like the processes we have suggested to be created have covered this item? * ICANN Compliance: Support including this requirement because it is important to investigate complaints and to enforcement. As Compliance we have seen multiple complaints when resellers transfer the TAC without authorization and notification. We would need to document when and by whom the control panel was accessed. We are facing challenges in obtaining records from the registrar. We will need all of the transfer documentation. * Note that the registrar is not allowed to store the TAC, and the registry can’t retrieve it – make sure that the records requirement doesn’t require storage or retrieval. * Compliance would be requesting time-stampled logs that show that they were provided to RNH, not the TAC themselves. * Holida's comments also touch on charter question b7: Should required differentiated control panel access also be considered, i.e., the registered name holder is given greater access (including access to the auth code), and additional users, such as web developers would be given lower grade access in order to prevent domain name hijacking? * Just pointing out the challenge; logging of sensitive data is an ongoing issue in the technical realm. Preliminary Recommendation 7: [The working group recommends that ICANN org establish minimum requirements for the composition of the TAC (for example, minimum length, syntax, or entropy value) based on current applicable technical security standards. ICANN org MAY change these requirements in response to new or updated standards, but any changes to the requirements MUST go in effect with sufficient notification and time for contracted parties to implement the necessary updates. ] OR [The Working Group recommends that Registrars and Registry Operators follow best practices for the composition of the TAC (for example, minimum length, syntax, or entropy value) based on current applicable technical security standards such as RFC9154 or subsequent or similar RFCs. These best practices may be updated in response to new or updated standards as appropriate.] * Wait for Jim Galvin to join the call when this is discussed. * Jothan Frakes: We just received some feedback about TAC storage / Auth-Info expirations in the RrSG that I am reviewing. Storage could be radically affected by the changes we are proposing to the TAC. Looks like there is a requirement to store the TAC at the registrar – there is a timing issue. Also when it is used to validate the RNH. * We talked about how this field is being used and by whom – good to know if there are specific uses, but not sure if using the field on its own basis is in scope for this group. * Using the TAC for other purposes that in this policy should not stop us in defining the way TAC should be used in the inter-registrar transfers. ACTION ITEM: Return to this item for the next meeting. Preliminary Recommendation 9: The working group recommends that: 9.2: When the Registrar of Record sets the TAC at the Registry, the Registry MUST securely store the TAC using a one-way hash that protects the TAC from disclosure. * Wait for Jim Galvin to join the call when this is discussed. * Don’t know how prescriptive we want to get with this recommendation. ACTION ITEM: Return to this item for the next meeting. 13.2: The Registrar of Record MAY set the TAC to null: * At any time in response to a request from the RNH. * After a period of less than 14 days by agreement by the Registrar of Record and the RNH. [Recommendation setting a policy requirement that the RNH has at least a minimum period of time to complete the transfer?] * WG settled on having one standard TTL of 14 days. * Discussed having a policy requirement with a minimum time for transfer. * Think we have the handled, but don’t know if we need a minimum. * Think we can remove this item. * Probably want to allow the Registrar of Record to set the TAC to null in case of fraud. This is a reason to NACK. * These can be denial reasons at any point in the process. * For 13.1 there was a question about whether there could be non-standard TTLs longer than 14 days? Don’t recall that the WG agreed to that. * Suggest adding text to 13.2: “As part of denying a transfer request in accordance with the reasons listed in Recommendations 19 – 22.” * Does this allow for a shorter TTL? That is covered in 13.2. * RySG is not agreeing with “enforced by the Registries” in 13.1. ACTION ITEM: Revisit this. Note change to I.A.3.7.3 from last meeting: Change “No payment” to “Non payment” in “Non payment for previous registration period (including payment disputes or credit card charge-backs) if the domain name is past its expiration date at the current Registrar of Record or for previous or current registration periods if the domain name has not yet expired.” 4. Updated swimlane diagram (see attached document) Some points: * Conceptual way to document the transfer – objective is to broadly develop a visual aid for the reader of the report. * Some things aren’t directly in scope but we needed them as a means to an end. * CQh1, Rec 16 – 30-day restriction to transfer. * TAC is not disclosed until transfer. * In future, if there are no issues, the domain transfers seamlessly. Idea then to represent the “frictions to cure”. * If there are “frictions to cure” (the challenge box): * Whether the domain is locked (client panel, UDRP, registry lock) – figure out how to resolve the issue. * General task: are there any other issues preventing the transfer? You are attempting to cure any of the issues. * If you can proceed with the transfer you are provisioning the TAC and providing it to the RNH. * If not then you go back to the beginning. * Still challenged on how to represent setting the TAC to null. (CQb4, Rec 13.2). Is there a better way to represent this? * Questions to consider: * Based on how the landscape has changed and the TAC is not revealed until provisioned – there used to be a representation of the registry and registrar curing issues with the transfer – now captured by the friction to cure. In future would there even be an interaction between the registry and registrar? * Is this useful as a tool for the reader of the Initial Report as an appendix? Or just for the WG to use? Discussion: * One of the challenges is to get exact equivalent between written text and the diagram. Would need to make sure there are no contradictions that could be misleading. * Largely a “sunny day” as opposed to “rainy day” view. * What about having a diagram for an “easy transfer” process and another similar to this with the more complex scenarios? * Staff will do another sanity check on the text versus the boxes and publish it with a disclaimer -- the recommendation text is authoritative. 5. AOB

1 0

**STARTS IN 10 MINUTES** Meeting Invitation | Transfer Policy Review PDP WG call | Tuesday, 10 May 2022
by Julie Bisland May 10, 2022

May 10, 2022

**AT THE TOP OF THE HOUR** Dear all, The next Transfer Policy Review PDP WG call is scheduled for Tuesday, 10 May 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/4hB1Cw * Check your time zone: https://tinyurl.com/3uu85cn7 [tinyurl.com]<https://urldefense.com/v3/__https:/tinyurl.com/3uu85cn7__;!!PtGJab4!vP5h5kj…> 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** Meeting Invitation | Transfer Policy Review PDP WG call | Tuesday, 10 May 2022
by Julie Bisland May 9, 2022

May 9, 2022

Dear all, The next Transfer Policy Review PDP WG call is scheduled for Tuesday, 10 May 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/4hB1Cw * Check your time zone: https://tinyurl.com/3uu85cn7 [tinyurl.com]<https://urldefense.com/v3/__https:/tinyurl.com/3uu85cn7__;!!PtGJab4!vP5h5kj…> 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

Proposed agenda for meeting #46 on Tuesday 10 May 2022 at 16:00 UTC
by Emily Barabas May 7, 2022

May 7, 2022

Dear Working Group members, Please find below the proposed agenda for the meeting scheduled to take place on Tuesday 10 May 2022 at 16:00 UTC. For agenda item 3, the updated swimlane document will be provided in advance of the meeting. Kind regards, Julie, Caitlin, Berry, and Emily Transfer Policy Review Phase 1 - Meeting #46 Proposed Agenda 1. Roll Call & SOI updates 2. Welcome and Chair Updates 3. Items in the preliminary recommendations flagged for further discussion (see items highlighted in blue here<https://docs.google.com/document/d/1clAqB1wBeOf9ZC5RMMxKrrUTs3N2WyaVYTIyVy_…>) 1. Updated swimlane diagram 2. AOB * Next call: Tuesday 17 May 2022 at 16:00 UTC

2 1

Post Call | Transfer Policy Review PDP WG | Tuesday, 03 May 2022
by Julie Bisland May 3, 2022

May 3, 2022

Dear all, All recordings for the Transfer Policy Review PDP WG call held on Tuesday, 03 May 2022 at 16:00 UTC can be found on the agenda wiki page <https://community.icann.org/x/4BB1Cw> (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 chat archive * Zoom recording (including audio, visual, rough transcript) * Transcript As a reminder only members and alternates can join the call as a Panelist, observers can join as an Attendee to listen. For additional information, you may consult the mailing list archives <https://mm.icann.org/pipermail/gnso-tpr/> and the main wiki page<https://community.icann.org/x/P4aUCQ>. Thank you. With kind regards, Julie

1 0

Meeting Invitation | Transfer Policy Review PDP WG call | Tuesday, 10 May 2022
by Julie Bisland May 3, 2022

May 3, 2022

Dear all, The next Transfer Policy Review PDP WG call is scheduled for Tuesday, 10 May 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/4hB1Cw * Check your time zone: https://tinyurl.com/3uu85cn7 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 #45 - 03 May 2022 at 16:00 UTC
by Julie Hedlund May 3, 2022

May 3, 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, 10 May 2022 at 16:00 UTC. Best regards, Emily, Julie, Berry, and Caitlin Action Items: Draft recommendations on NACK Charter Question h1 produced by the small group (see working document pages 16-23 here [docs.google.com]<https://urldefense.com/v3/__https:/docs.google.com/document/d/1L2bZnhJUY3Vx…>) For I.A.3.7.3 -- Change “No payment” to “Non-payment”. For I.A.3.9.1 -- WG members who have suggestions for text to address this situation should send them to the list. Composition of the TAC (see attached document): Recommendation 7: 1. Staff to consult with ICANN org Compliance as to whether there are issues with enforcement to reference an RFC without context. 2. WG members to review the suggested text from Sarah and Jim and provide comments on the list. Recommendation 11: Jim Galvin and WG members to consider suggested change to the language as follows: “The working group recommends that the TAC as created by the Registrar of Record according to Preliminary Recommendation 7, must be “one-time use. In other words, it MUST be used no more than once per domain name. The Registry Operator MUST clear the TAC as part of completing the successful transfer request.” Notes: Transfer Policy Review Phase 1 - Meeting #45 Tuesday, 03 May 2022 at 16:00 UTC Proposed Agenda 1. Roll Call & SOI updates 2. Welcome & Chair updates * Homework: Review Initial Report and identify those items that need extra work in coordination with your groups as much as possible. * Only other reminder is that we have 6 sessions now to work diligently, avoiding bringing up settled discussions. 3. Draft recommendations on NACK Charter Question h1 produced by the small group (see working document pages 16-23 here [docs.google.com]<https://urldefense.com/v3/__https:/docs.google.com/document/d/1L2bZnhJUY3Vx…>) Overview: * Reminder: the goal is to take the small group outputs as they are unless something is really broken or wrong in what they produced. * Thank the members of the small team and the staff support, particularly the summary table. * Focus was the finalize the input from the full WG. Recommendation 19: The working group recommends revising the following reasons that the Registrar of Record MAY deny a transfer request as follows: I.A.3.7.1: Evidence of fraud or violation of the Registration Agreement. Implementation Guidance: The intent of “violation of the Registration Agreement” is not to allow the blocking of transfers due to minor violations, but to allow action in case of substantive contravention of the Registration Agreement. I.A.3.7.2: Reasonable dispute over the identity of concern that the transfer was not requested by the Registered Name Holder or Administrative Contact. * Identity is not the goal. I.A.3.7.3: No payment for previous registration period (including payment disputes or credit card charge-backs) if the domain name is past its expiration date at the current Registrar of Record 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. Comment from Jothan re: “for previous or current registration periods if the domain name has not yet expired…” I was asked if this addresses explicit renewals in addition to those within add-grace Recommendation 20: The working group recommends changing the following reasons that the Registrar of Record currently MAY deny a transfer into reasons that the Registrar of Record MUST deny a transfer and revising the text as follows: I.A.3.7.4: Express objection to the transfer by the authorized Transfer Contact Registered Name Holder. Objection could take the form of specific request (either by paper or electronic means) by the authorized Transfer Contact Registered Name Holder to deny a particular transfer request, or a general objection to all transfer requests received by the Registrar, either temporarily or indefinitely. In all cases, the objection must be provided with the express and informed consent of the authorized Transfer Contact Registered Name Holder on an opt-in basis and upon request by the authorized Transfer Contact Registered Name Holder, the Registrar must remove the lock or provide a reasonably accessible method for the authorized Transfer Contact Registered Name Holder to remove the lock within five (5) calendar days. I.A.3.7.5: The transfer was requested within 60 30 days of the creation date as shown in the registry Whois RDDS record for the domain name. I.A.3.7.6: A domain name is within 60 30 days (or a lesser period to be determined) after being transferred (apart from being transferred back to the original Registrar in cases where both Registrars so agree and/or where a decision in the dispute resolution process so directs). "Transferred" shall only mean that an inter-registrar transfer has occurred in accordance with the procedures of this policy. Discussion: * Re: 1.A.3.7.3: Question: If someone has entered into a payment plan and the registrant determines to renew the domain name, you would not want the domain name to transfer away during that time. Do the sections address this? Answer: For I.A.3.7.3 – instead of “No payment” we could say “Non-payment”, but maybe it covers without that. * Seems like the registrar has extended credit to the registrant, but the domain has been paid for. Seems like a more complicated relationship, that doesn’t involve a grace-period payment. Don’t think the policy has to accommodate this. * Think it is premium names that are not addressed in the current policy. * Seems like if there was a payment plan there would be contracts to cover that? ACTION ITEM: For I.A.3.7.3 -- Change “No payment” to “Non-payment”. Recommendation 21: The working group recommends revising the reasons that the Registrar of Record MUST deny a transfer request as follows: I.A.3.8.1: A p Pending UDRP proceeding that the Registrar has been informed notified of by the Provider in accordance with the UDRP Rules. I.A.3.8.3: Pending dispute related to a previous transfer, pursuant to under the Transfer Dispute Resolution Policy. I.A.3.8.4: Pending URS proceeding or URS suspension that the Registrar has been informed notified of by the Provider in accordance with the URS Procedure. Recommendation 22: The working group recommends changing the following reasons that the Registrar of Record currently MAY NOT deny a transfer into reasons that the Registrar of Record MUST NOT deny a transfer and revising the text as follows: I.A.3.9.1: Implementation Guidance: Registrars are prohibited from denying domain name transfer requests based on non-payment of fees for pending or future registration periods during the Auto-Renew Grace Period, provided that any auto-renewal costs borne by the Registrar are reversible for future period. * Comment from Jothan: Explicit renewals do not have automatic refunds like auto-renewals. These have a unit cost that extends the renewal term for 1 year so is related to a future registration period. Is the losing registrar protected in this instance by this verbiage where a registrant extends and has funds still due? * This one might suggest that a registrant might have their transfer denied while under a payment plan. If that is covered by contract, then that’s okay. Wording could leave room for the registrant to migrate the domain away. * The question is whether we want to allow registrars to hold a transfer hostage for payment? But this could be covered by a contract. * Registrars should take this into account with the contracts with registrants. * Think we are confusing this with a title, versus a payment plan that is like an unsecured loan. This is not an apt analogy. In Jothan’s situation the entity loaning the money has made an unsecured loan. Or mechanism facilitates the situation where the registrar could be the registered name holder and leases the name, rather than the registrant holding the title so to speak. * You could structure the deal in a way that the registrar is listed as RNH until the domain is paid in full. ACTION ITEM: For I.A.3.9.1 -- WG members who have suggestions for text to address this situation should send them to the list. I.A.3.9.2: No response from the Registered Name Holder. or Administrative Contact I.A.3.9.3: A registrar-applied inter-registrar transfer lock is in place on the Ddomain name in Registrar Lock Status, for reasons other than those specified in I.A.3.7 and I.A.3.8 unless and the Registered Name Holder is not provided with the reasonable opportunity and ability to unlock the domain name prior to the Transfer Request pursuant to the requirements in sections I.A.5.1 - I.A.5.4. I.A.3.9.4: Domain name registration period time constraints, other than as defined in I.A.3.7.5 and I.A.3.7.6[1] 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 Change of Registrant pursuant to Section II.C.2. I.A.3.9.5: General payment defaults between Registrar and Reseller, as defined in the RAA, business partners / affiliates in cases where the Registered Name Holder for the domain in question has paid for the registration. 4. Composition of the TAC – Recommendations 7, 9, and 11 Recommendation 7: Current text: [The working group recommends that ICANN org establish minimum requirements for the composition of the TAC (for example, minimum length, syntax, or entropy value) based on current applicable technical security standards. ICANN org MAY change these requirements in response to new or updated standards, but any changes to the requirements MUST go in effect with sufficient notification and time for contracted parties to implement the necessary updates.] OR [The Working Group recommends that Registrars and Registry Operators follow best practices for the composition of the TAC (for example, minimum length, syntax, or entropy value) based on current applicable technical security standards such as RFC9154 or subsequent or similar RFCs. These best practices may be updated in response to new or updated standards as appropriate.] From Sarah Wyld: The Working Group recommends that Registrars and Registry Operators follow best practices for the composition of the TAC (for example, minimum length, syntax, or entropy value) based on current applicable technical security standards such as RFC9154 or subsequent or similar RFCs. These best practices may be updated in response to new or updated standards as appropriate. From Jim Galvin: The working group recommends that the minimum requirements for the composition of a TAC MUST be as specified in RFC 9154 (and its update and replacement RFCs). In addition, where random values are required by RFC 9154, such values MUST be created according to BCP 106. [Footnote: BCP 106 is a Best Current Practice and is an idempotent reference to the most recent version of the specification entitled “Randomness Requirements for Security”, currently RFC 4086, which is how it is referenced in RFC 9154.] The salient specification point from RFC 9154 is as follows. ● Using the set of all printable ASCII printable characters except space and a required entropy of 128 bits, the length of the TAC MUST be at least 20 characters. Gould, J. and R. Wilhelm, "Extensible Provisioning Protocol (EPP) Secure Authorization Information for Transfer", RFC 9154, DOI 10.17487/RFC9154, December 2021, <https://www.rfc-editor.org/info/rfc9154>. Eastlake 3rd, D., Schiller, J., and S. Crocker, "Randomness Requirements for Security", BCP 106, RFC 4086, June 2005, <https://www.rfc-editor.org/info/bcp106>. Discussion: * Seems rather technical for a policy recommendation. * Seems reasonable though. * Not sure how to balance technical with general. Not sure what to change. * Maybe we can find a way to bring in Sarah’s language. * RFC 4086 and BCP 106 are the same document. * If the PDP wants to say higher level and just refer to the IETF standards, it could refer to RFC 4086 and BCP 106 and stop there. * This seems like a good suggestion. * Are we future proofing this enough, or locking it in one place? To the extent that the technology evolves the RFCs would be updated accordingly. They would be adaptable. * In RFC 9154, it has a “SHOULD” around the 20 characters – it doesn’t make it a “MUST”. The bullet point in the suggested text makes it a “MUST”. * Seems that this text might be too technical for a recommendation, but great to have for reference? * IETF didn’t put “MUST” in because that would have been policy; this WG would have to make it a “MUST” to make it policy. * The objective is to make sure we are providing registrants a reasonable amount of security for the TAC. The specificity of the text has to be balanced with evolving technology. ACTION ITEMS: 1. Staff to consult with ICANN org Compliance as to whether there are issues with enforcement to reference an RFC without context. 2. WG members to review the suggested text from Sarah and Jim and provide comments on the list. Recommendation 9: Current text: The working group recommends that: 9.1 The TAC MUST be only generated by the Registrar of Record upon request by the RNH or their designated representative. 9.2: When the Registrar of Record sets the TAC at the Registry, the Registry MUST securely store the TAC using a one-way hash that protects the TAC from disclosure. 9.3: When the Registrar of Record provides the TAC to the RNH or their designated representative, the Registrar of Record MUST also provide information about when the TAC will expire. From Jim Galvin: 9.2 When the Registrar of Record sets the TAC at the Registry, the Registry MUST store the TAC securely, at least according to the minimum requirement set forth in RFC 9154: using a strong one-way cryptographic hash with at least a 256-bit hash function, such as SHA-256 [FIPS-180-4], and with a per-authorization information random salt with at least 128 bits. [FIPS-180-4] National Institute of Standards and Technology, U.S. Department of Commerce, "Secure Hash Standard, NIST Federal Information Processing Standards (FIPS) Publication 180-4", DOI 10.6028/NIST.FIPS.180-4, August 2015, <https://csrc.nist.gov/publications/detail/fips/180/4/final>. Discussion: * This prevents the registry from storing TACs with encryption that is reversable. The registry can never recover the TAC. If it is encrypted it could be recovered using the key. This means that the TAC is short lived and disposable. * Registry can compare them, not recreate them. * This is not current practice – this is a big improvement in security. How to make this clear. * If the TAC is transformed into something only used for the transfer it would affect registrars who use the TAC for other confirmations/authorizations. * If they are using it for something else don’t we should address that here. The TAC is supposed to be only for transfer. * Current TAC is not as private as people think it is. Recommendation 11: Current text: The working group recommends that the TAC MUST be “one-time use.” In other words, it MUST be used no more than once per domain name. The Registry Operator MUST clear the TAC as part of completing the successful transfer request. From Jim Galvin: The working group recommends that the TAC MUST be “one-time use.” In other words, it MUST be used no more than once per domain name. The Registrar of Record MUST meet this requirement by randomly creating a new TAC each time one is needed as specified in Preliminary Recommendation 7. The Registry Operator MUST clear the TAC as part of completing the successful transfer request. Discussion: * Concern that this would force people to work with other people’s patented processes. * For bulk transfers, still planning to use a TAC on a single domain – hadn’t yet recommended one TAC for multiple domains. Will be revisiting this. In this case, “bulk” means that if you have 100 names you have 100 TACs. * All Jim added was a sentence tying this to recommendation 7. * Seems like Recommendation 11 is valid without the additional text. * The current wording does not specify that the registrar of record is creating the TAC and links that to recommendation 7. Could amend to take out the word “randomly” – you don’t need it if you are referencing recommendation 7. * Do think it’s useful to tie together the related recommendation. * Don’t understand the “MUST meet”. * Suggestion from Rick Wilhelm: “The working group recommends that the TAC as created by the Registrar of Record according to Preliminary Recommendation 7, must be “one-time use.” In other words…” * Proprietary, non-standard use of Auth-Info shall be broken by this. ACTION ITEM: Jim Galvin and WG members to consider suggested change to the language as follows: “The working group recommends that the TAC as created by the Registrar of Record according to Preliminary Recommendation 7, must be “one-time use. In other words, it MUST be used no more than once per domain name. The Registry Operator MUST clear the TAC as part of completing the successful transfer request.” 5. AOB * Next call: Tuesday 10 May 2022 at 16:00 UTC

1 0

**STARTS IN 15 MINUTES** Meeting Invitation | Transfer Policy Review PDP WG call | Tuesday, 03 May 2022
by Julie Bisland May 3, 2022

May 3, 2022

**STARTS IN 15 MINUTES** Dear all, The next Transfer Policy Review PDP WG call is scheduled for Tuesday, 03 May 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/4BB1Cw * Check your time zone: https://tinyurl.com/mt3pwwny [tinyurl.com]<https://urldefense.com/v3/__https:/tinyurl.com/mt3pwwny__;!!PtGJab4!tbF9WfI…> 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

TPR-P1 // 30 Apr 2022 Project Package
by Berry Cobb May 2, 2022

May 2, 2022

Dear WG, Please find a link below to project package for the TPR-P1 PDP (30 Apr 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 – Group roster 4. Page 04 – Work and activity metrics 5. Page 05,06 – Group attendance for plenary meetings 6. Page 07 – Project Plan, Gantt chart 7. Page 08,09 – Work plan & Action items for the period Key points: * The WG is proceeding according to plan against the charter topics/questions. * The WG anticipates submitting its Initial Report for public comment on 20 Jun 2022. Please let us know if you have questions. Thank you. B Berry Cobb Policy Development – Senior Program Manager Internet Corporation for Assigned Names and Numbers (ICANN) Mobile: +1 424 443 8960 Phone: +1 202 570 7240 Fax: +1 202 789 0104 Twitter: @berrycobb www.icann.org<https://www.icann.org/>

1 0