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/1clAqB1wBeOf9Z...>) 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/1clAqB1wBeOf9Z...>) 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