Dear TPR WG members, Please find below the notes and action items from today’s meeting. The next meeting will be on Tuesday, 13 December at 16:00 UTC. Best regards, Emily, Julie, Berry, and Caitlin ACTION ITEMS/HOMEWORK: Ongoing Action Items: 1. Jothan Frakes, Jim Galvin, Jody Kolker, and Rick Wilhelm have volunteered to compile a list of attack vectors and how the recommendations solve for them, or where they are out of scope. 2. Recommendation 13: Question to the Community -- Small Team on TTL Enforcement: Send the proposal to the list with rationale. 3. Recommendation 22: * a) Concern: Fees and b) Concern: Sanctions: Staff to ensure that the rationale reflects the WG’s discussion and agreement. * c) Proposed edit: WG agrees to a revision to the Implementation Guidance as proposed in the Potential next step. Action Items from 08 December: None captured. Notes: Transfer Policy Review - Meeting #72 Proposed Agenda 08 December 2022 1. Roll Call & SOI updates 2. Welcome and Chair Updates * No updates. 3. Review of Small Team Proposal regarding Transfer Policy section I.A.3.7.1<https://mm.icann.org/pipermail/gnso-tpr/2022-December/000696.html> * Small Team met after the end of the last call and developed the following draft language: "Evidence of (a) fraud or (b) the domain presents an active DNS Security Threat as defined here: https://www.icann.org/dns-security-threat." * Language at the link could change so it should have to be watched. * Is it clear that “evidence” applies to both “fraud” and “active DNS Security Threat”? WG members think it is clear. * Question: This is a MAY NACK not a MUST NACK – why is that? (Question from the BC.) Answer: Reason it is MAY is because there is a question about what evidence of fraud arises to. Registrar has the discretion to decide what is evidence. The other issue is jurisdiction. * Disagree: Fraud is fraud, jurisdiction shouldn’t matter and shouldn’t leave up to the registrar. Also, should be clear for DNS security threats. * Jurisdiction does matter and depends. * Question: If a complaint comes in with an allegation of fraud, and the complainant makes reference to evidence – who determines that evidence is sufficient? What if complainant and registrar disagree? Could a registrar be put into a breach situation? * Maybe split it – make fraud a MAY and make DNS Security Threat at MUST. * What if the registrar has to prove that the domain is okay against a complaint of DNS Security Threat, so leave as a MAY. * Perhaps no reason to make DNS Security Threats discretionary since it is clear – so could make a MUST. * Registrars can choose how they want to monitor and mitigate abuse – could have conflicting determinations of DNS Security Threat from different reputation block lists. Registrars should have the discretion should be able to make their own determinations. * Where the clear evidence that there is a DNS Security Threat it should be suspended – no discretion needed. * “Clear and convincing evidence” is a higher threshold than “evidence of”. If a registrar has “clear and convincing evidence” could make it a MUST. * Keep “evidence of fraud” as a MAY because it depends on jurisdiction (porn or LGBTQ as an example). * Seems that “evidence of fraud” could stay as a MAY. In current policy, that is the only NACK reason – can’t currently NACK for abuse (or at registrars’ discretion). * Adding in “DNS Security Threat” as a MAY is a huge step. * Since registrars can block names that pose a “DNS Security Threat”, so not sure we need to make this a MUST. If there is insufficient evidence and didn’t block a name, wouldn’t they in breach of the transfer policy? * DNS abuse definition is out of scope for this group. * This discussion shows the need to include “DNS Security Threat” in the policy. * How about “A registrar MUST refuse the transfer if the registrar is satisfied that it poses a “DNS Security Threat.” So: 1) MAY for evidence of fraud and 2) MUST…”. Still at the registrar’s discretion – the registrar must be satisfied. * Doesn’t prevent registrar abuse. * Seems that most WG members agree that the “DNS Security Threat” should be a MAY. * Suggest that Mike could post to the list language and rationale for why the “DNS Security Threat” should be a MUST. * Leave this new language in for now. 4. Phase 1A Initial Report Public comment review – review of items not specifically tied to a recommendation: a. Other - Charter Questions and Report Text – see: gnso-TPR-P1A-pcrt-Initial-Report_Responses to CQs and Report Content_20220829.docx<https://community.icann.org/download/attachments/201949311/gnso-TPR-P1A-pcrt...> Comments 1-3: Discussion: * Don’t see the need to limit transfers or to allow bulk transfers; don’t think we should be suggesting technological solutions for verification. * Talk about bulk transfers later; camera for verification could cause GDPR issues. * Limiting transfers could impact the value of a domain name. * Don’t agree that we should change the policy with respect to renewals. * 30-day lock solves the problem of frequent transfers. * WG agrees that there is no need for any changes with respect to the comments. Comments 4-6: Discussion: * Re: Fees – hopefully language is clear that registrants don’t have to pay those fees to transfer. * Staff has an action to consult internally on sanctions. * Policy is also applicable to the resellers (RAAs) – registrar is responsible for the reseller. * 3.12.2 Any registration agreement used by reseller shall include all registration agreement provisions and notices required by the ICANN Registrar Accreditation Agreement and any ICANN Consensus Policies. * Also this: 3.12 Obligations Related to Provision of Registrar Services by Third Parties. Registrar is responsible for the provision of Registrar Services for all Registered Names that Registrar sponsors being performed in compliance with this Agreement, regardless of whether the Registrar Services are provided by Registrar or a third party, including a Reseller. Registrar must enter into written agreements with all of its Resellers that enable Registrar to comply with and perform all of its obligations under this Agreement. In addition, Registrar must ensure that: * Out of scope for this WG to regulate fees. * ICANN doesn’t set fees consistently anywhere else. * Need to have some leeway to increase the fees down the road. * WG did not agree to make any changes on how prominently disclosed in a DNRA, such as with renewal fees. There was nothing in our Initial Report – didn’t raise when we talked about it previously. * Still think the WG should consider an new recommendation (proposal from Mike Rodenbaugh) to require registrars to feature fees prominently. Comment 7—Table to next week to allow ICANN Org Compliance to add context. Comments 8-9: Discussion: * Covered the issue in #8 in previous discussions. * Already looking at ways to accommodate #9. * WG agrees that no changes to the recommendations are necessary. Comments 10-12: Discussion: * Current proposal is to put Losing FOA back in the NACK model, so status quo. * WG agreed that DNSSEC was out of scope (re: SSAC’s comment) and we included that in our rationale (STAFF TO REVIEW RATIONALE). * Tech Ops is looking at the suggestions in #11 and WG is preparing a write-up on threat vectors re: #12. Don’t think anything Tech Ops comes up with would affect this WG. * WG agrees that no changes are necessary in response to the comments. * b. Other - Charter Questions and Report Text– see: https://community.icann.org/display/TPRPDP/Phase+1A+-+Public+Comment+Review?... Staff note: Due to the length of this comment, please refer to the full text of the PDF here<https://itp.cdn.icann.org/public-comment/proceeding/Initial%20Report%20on%20...>. Comments quoted below are included in pages 56-57. On page 38, section 3.4.2, the term "Lock" with relation to Domain Name Locking for a UDRP should be made more precise. For greater certainty (since there is a presumption of innocence until proven guilty), registrant should be able to change nameservers during a UDRP (i.e. registrar can set clientTransferProhibited, but should NOT set clientUpdateProhibited). UDRP complainants had ample opportunity to collect evidence/screenshots before a UDRP was filed, and preventing nameservers to change might have a negative impact on a registrant. e.g. suppose a domain was hacked, and the nameservers were changed to those controlled by the "hacker". A UDRP filing shouldn't prevent a registrant from fixing those nameservers (to change them to what they were before they were hacked), all while keeping the domain at the current registrar. (registrars need to have better granularity for their locks, which they might not all do all the time, particularly when there's a UDRP). . . . . . The Swim Lane seems to also incorrectly state "TAC Securely Stored" (by the registry). It's the HASH of the TAC that is securely stored (not the TAC itself that is securely stored). Discussion: * Unless there are objections, staff with update the swimlane to state that the hash of the TAC is securely stored. * Re: the comment on “lock” in the UDRP, the UDRP states, “Lock means a set of measures that are registered applies to a domain name which prevents at a minimum any modification to the registrant and register information by the respondent, but does not affect the resolution of the domain, name or the renewal of the domain name.” * Believe we did discuss this. However, I think the conclusion the group came to earlier is that definitions with inside another policy or within another policy aren't really within the scope of this group's work. * It's not within our scope to change other policies like the UDRP rules. I think it's a plain meaning. The registrant can certainly change the name servers if they want to go to a different host or something like that. So yeah, I don't think that's that section or that the lock of concern is something that we really need to address. * Re: the hash of the TAC: I think that's a difference without a distinction, and I also think that it also over specifies, because in the future the mechanism for that secure storing, maybe something different than hashing it as technology evolves. And so I think that securely stored by whatever means necessary, as saying goes, is a better way to state it and not over specified in the policy.