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

No TPR call tomorrow, Thursday 15 December
by Emily Barabas Dec. 14, 2022

Dec. 14, 2022

Dear working group members, With our review of the Public Comment Review Tools complete and work still underway in some of the small teams, we are going to cancel tomorrow’s TPR call and give the small teams a little more time to wrap up their work, as needed. The focus of our call on Tuesday, 20 December will be to review and consider outputs from the small teams. Please feel free to reach out on list with any questions. Kind regards, Caitlin, Berry, Julie, and Emily Emily Barabas Policy Development Support Senior Manager Internet Corporation for Assigned Names and Numbers (ICANN) Phone: +31 (0)6 84507976 www.icann.org<http://www.icann.org/>

1 0

Notes and action items - TPR WG Meeting #73 - 13 December 2022 at 16:00 UTC
by Julie Hedlund Dec. 13, 2022

Dec. 13, 2022

Dear TPR WG members, Please find below the notes and action items from today’s meeting. The next meeting will be on Thursday, 15 December at 16:00 UTC. Best regards, Emily, Julie, Berry, and Caitlin ACTION ITEMS/HOMEWORK: 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. Other - Additional Suggested Topics and Proposals – Item 7 from ICANN Org – see: gnso-TPR-P1A-pcrt-Initial-Report-Additional Topics and Proposals_20221213.docx<https://community.icann.org/download/attachments/201949311/gnso-TPR-P1A-pcr…> -- Request for ICANN Org Compliance to suggest specific language. 4. Other - Additional Input – see: gnso-TPR-P1A-pcrt-Initial-Report-General_20220829.docx<https://community.icann.org/download/attachments/201949311/gnso-TPR-P1A-pcr…> -- WG members to look at comments 12-23 and 24-33 to make sure there is something we haven’t already covered Notes: Transfer Policy Review - Meeting #73 Proposed Agenda 13 December 2022 1. Roll Call & SOI updates 2. Welcome and Chair Updates * Small Team Updates: * Recs 16 & 17 lock override: Met yesterday (12 Dec) – Developed a proposal that they can share to the full list. * Rec 13 TTL: Meeting today (13 Dec). 3. Review of additional mailing list feedback<https://mm.icann.org/pipermail/gnso-tpr/2022-December/date.html> on Small Team Proposal regarding Transfer Policy section I.A.3.7.1<https://mm.icann.org/pipermail/gnso-tpr/2022-December/000696.html> * Adding DNS Security Threat and definition to Evidence of Fraud. * Two new items on the mailing list in response: * Mike R.: Why this should be added to MUST not transfer. * Rick’s response to Mike (why it should stay as MAY). * Status: Intent is to go with this proposed language in the MAY category. Need to be able to give flexibility to registrars to have discretion. * Examples: Need to study a security threat (such a Microsoft or Facebook) – to transfer from one registrar to another. * Question: Why not just write in an exception for the above example, but keep it as a MUST? If that is the only exception. * There needs to be flexibility for various examples – not just the one exception. Leaving it broad is the better approach. * Hard to explain this clearly to those who think it should be MUST. Need a more compelling argument. * Most WG members agree to stay with the proposed language in the MAY category. 4. Phase 1A Initial Report Public comment review – review of items not specifically tied to a recommendation (please see Public Comment Review Documents in the bottom three rows of the table on the wiki page here<https://community.icann.org/display/TPRPDP/Phase+1A+-+Public+Comment+Review>): a. Other - Additional Suggested Topics and Proposals – Item 7 only from ICANN Org – see: gnso-TPR-P1A-pcrt-Initial-Report-Additional Topics and Proposals_20221213.docx<https://community.icann.org/download/attachments/201949311/gnso-TPR-P1A-pcr…> Summary: “ICANN org suggests that the policy recommendation include requirements related to the maintenance and provision to ICANN (upon reasonable notice) of records related to when/how/to whom the TAC was provided, regardless of the means the registrar chooses to use to provide the TAC.” Discussion: * Assume this goes along with transfer disputes; and when we talk about control panel access – if it was provided by the control panel the registrant still had to be notified. * Relates to the difficulty of proving who accessed the control panel. * Would be helpful to see specific language. Also would need a data processing agreement before registrars could provide personal data. * Assumed that if there's a requirement (e.g. provide TAC only to RNH) that the corresponding obligation to be able to prove we met that requirement is assumed? * This adds a new layer to previous discussions about record keeping. * Registrars need to see the benefit of logging. Registrars would need to look at costs vs. benefits and also the DPA. * ICANN Org Compliance: Registrars should be able to provide evidence [documentation? Records?] of compliance with TAC and notification provision requirements. ACTION ITEM: Request for ICANN Org Compliance to suggest specific language. b. Other - WG Process and Modalities – see: gnso-TPR-P1A-pcrt-Initial-Report-WG Process and Modalities_20220829.docx<https://community.icann.org/download/attachments/201949311/gnso-TPR-P1A-pcr…> Comments 1-10 – requests to extend the deadline (other elements are captured elsewhere). Discussion: * Leadership considered the request and extended the public comment period. Not sure there was a benefit for a longer extension. * Note comment 10 also touches on a couple of other items – concerns about registrants being underrepresented and lack of balance, which we’ll talk about below. Comments 11-14: Discussion: * Discussed participation and representation: We do report attendance and we are seeing diversity of viewpoints – between registrars as well as with non-registrars. * Attendance is also included in the monthly reports to Council. * The WG will go back to weekly meetings as of the beginning of the year. If a member cannot attend a call he or she should establish an alternate for that call. c. Other - Additional Input – see: gnso-TPR-P1A-pcrt-Initial-Report-General_20220829.docx<https://community.icann.org/download/attachments/201949311/gnso-TPR-P1A-pcr…> Comments 1, 2, 5, 6, and 11: Discussion: * Note: Many of the comments in this document are covered elsewhere and have already been dealt with (12-23, 25-33). * All raised concerns about the elimination of the Losing FOA. Discussed with Recommendation 2 and adding back in the ability to ACK or NACK. * WG agrees that these comments have been previously addressed. Comments 3 and 4: Discussion: * Don’t think we discussed this: “SSAC should also do a thorough review, in light of our own comments that highlighted the inconsistencies between their past advisories and the working group's recommendations.” * Leap of Faith provided a lot of good comments that the WG has reviewed. * Don’t know if we wanted to ask the SSAC to write a specific report. * SSAC did have the opportunity to comment (but didn’t). SSAC isn’t shy about contributing to community discussions. They have chosen not to in this case. Not sure why we would make a specific request of them; could look like we are delaying the process. Comments 7-10 (all related to security): Discussion: * A lot of the process the WG went through addressed these issues – specifically making changes to enhance security. Couldn’t find hard data on unauthorized transfers. Balance of looking through the security procedures and make sure they make sense. * Security in these comments is in a different context – we don’t know until we implement these recommendation the impact on security. * Re: Lack of data – we are confronted with the same situation that there is a lack of reporting so a lack of data. Consider a recommendation in implementation or contractual negotiations. Comment 24: Discussion: * Don’t think the comment it raising anything new, but provides some helpful points. * No further comments from the WG. ACTION ITEM: WG members to look at comments 12-23 and 24-33 to make sure there is something we haven’t already covered. 5. AOB: No meeting 22 December and last week in December; first meeting in January is Tuesday, 10 January.

1 0

Post Call | Transfer Policy Review PDP WG | Tuesday, 13 December 2022
by Devan Reed Dec. 13, 2022

Dec. 13, 2022

Dear all, All recordings for the Transfer Policy Review PDP WG call held on Tuesday, 13 December 2022 at 16:00 UTC can be found on the agenda wiki page <https://community.icann.org/x/_QnVD> (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 recording (including audio, visual, rough transcript, chat) * 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, Devan

1 0

Meeting Invitation | Transfer Policy Review PDP WG call | Thursday, 15 December 2022
by Devan Reed Dec. 13, 2022

Dec. 13, 2022

Dear all, The next Transfer Policy Review PDP WG call is scheduled for Thursday, 15 December 2022 at 16:00 UTC for 90 minutes. * If unable to attend, members must communicate their alternate replacement using this google form<https://urldefense.com/v3/__https:/docs.google.com/forms/d/e/1FAIpQLScXP3-H…>. To join - Zoom 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/cYIFDQ * For other places see: https://tinyurl.com/33ke8na4 ONLY FOR MEMBERS & ALTERNATES: * Staff will promote members and alternates to panelist once joined. * Chat: Please select Everyone so everyone can see your chat, and so it’s captured in the recording. * Alternate assignments 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, your affiliation - alternate after your name. * 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, Devan

1 0

Draft proposal re: exemption for Recs. 16 & 17
by Owen Smigelski Dec. 13, 2022

Dec. 13, 2022

Hi all, Keiron, Zak, and I have a draft proposal regarding the post-create and post-transfer locks in Recommendations 16 and 17. We considered the desire to enhance security and provide a consistent experience across registrars, as well as the counter position that this can delay legitimate transfers and can be an unnecessary restriction on registrants. Our proposal is to add the option for registrars to opt out of the lock for “Established Customers”. This should reduce the chance of domains transferring to multiple registrars as part of hijacking, while allowing existing registrants to better manage their domains. A draft definition for “Established Customer” is: An established customer is a registrant who has previously received continuing services from a registrar for a period of more than 30 days and has an established relationship with the registrar. This typically refers to a customer who has a history of regular interactions with the registrar and has demonstrated a willingness to continue receiving services from the registrar in the future. We’re happy to discuss during our next call (including the amusing story of how we finalized this definition) or via the list. A big thanks to ICANN staff for organizing and facilitating our calls! Regards, Owen

1 0

15 MINUTES REMINDER | Meeting Invitation | Transfer Policy Review PDP WG call | Tuesday, 13 December 2022
by Devan Reed Dec. 13, 2022

Dec. 13, 2022

Dear all, The next Transfer Policy Review PDP WG call is scheduled for Tuesday, 13 December 2022 at 16:00 UTC for 90 minutes. * If unable to attend, members must communicate their alternate replacement using this google form<https://urldefense.com/v3/__https:/docs.google.com/forms/d/e/1FAIpQLScXP3-H…>. To join - Zoom 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/_QnVD * For other places see: https://tinyurl.com/yc7nbp8c [tinyurl.com]<https://urldefense.com/v3/__https:/tinyurl.com/yc7nbp8c__;!!PtGJab4!5nM9dE3…> ONLY FOR MEMBERS & ALTERNATES: * Staff will promote members and alternates to panelist once joined. * Chat: Please select Everyone so everyone can see your chat, and so it’s captured in the recording. * Alternate assignments 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, your affiliation - alternate after your name. * 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, Terri

1 0

Proposed agenda for meeting #73 on Tuesday 13 December 2022 at 16:00 UTC
by Emily Barabas Dec. 12, 2022

Dec. 12, 2022

Dear Working Group members, Please find below the proposed agenda for the next meeting scheduled to take place on Tuesday 13 December 2022 at 16:00 UTC. Prior to the call, please review the documents linked in the agenda below. Kind regards, Caitlin, Berry, Julie, and Emily ________________________________________________________________________________________________ Transfer Policy Review - Meeting #73 Proposed Agenda 13 December 2022 1. Roll Call & SOI updates 2. Welcome and Chair Updates 3. Review of additional mailing list feedback<https://mm.icann.org/pipermail/gnso-tpr/2022-December/date.html> on Small Team Proposal regarding Transfer Policy section I.A.3.7.1<https://mm.icann.org/pipermail/gnso-tpr/2022-December/000696.html> 4. Phase 1A Initial Report Public comment review – review of items not specifically tied to a recommendation (please see Public Comment Review Documents in the bottom three rows of the table on the wiki page here<https://community.icann.org/display/TPRPDP/Phase+1A+-+Public+Comment+Review>): * Other - Additional Suggested Topics and Proposals – Item 7 only * Other - WG Process and Modalities * Other - Additional Input 5. AOB

1 0

REMINDER | Meeting Invitation | Transfer Policy Review PDP WG call | Tuesday, 13 December 2022
by Devan Reed Dec. 12, 2022

Dec. 12, 2022

Dear all, The next Transfer Policy Review PDP WG call is scheduled for Tuesday, 13 December 2022 at 16:00 UTC for 90 minutes. * If unable to attend, members must communicate their alternate replacement using this google form<https://urldefense.com/v3/__https:/docs.google.com/forms/d/e/1FAIpQLScXP3-H…>. To join - Zoom 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/_QnVD * For other places see: https://tinyurl.com/yc7nbp8c [tinyurl.com]<https://urldefense.com/v3/__https:/tinyurl.com/yc7nbp8c__;!!PtGJab4!5nM9dE3…> ONLY FOR MEMBERS & ALTERNATES: * Staff will promote members and alternates to panelist once joined. * Chat: Please select Everyone so everyone can see your chat, and so it’s captured in the recording. * Alternate assignments 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, your affiliation - alternate after your name. * 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, Terri

1 0

Reason why Losing Registrar may NACK
by Sarah Wyld Dec. 12, 2022

Dec. 12, 2022

Hello team, A smaller group remained on the call after the main team wrapped up today to discuss how to adjust the 'evidence of fraud' reason for a registrar to NACK a transfer out. The updated text that we propose to be used in this area is: "Evidence of (a) fraud or (b) the domain presents an active DNS Security Threat as defined here: https://www.icann.org/dns-security-threat." We wanted to balance two things: 1. Registrars must be able to NACK transfers out in appropriate circumstances, such as when the RNH is using the domain for something illegal or that threatens the healthy functioning of the DNS. 2. Registrants need predictability (e.g. avoiding situations where a registrar changes the relevant agreement in a sudden or surprising manner), and freedom of choice for their provider. We considered referring to DNS Abuse, but with the awareness that ICANN has defined "DNS Security Threat" at the link mentioned above, and since the 5 categories of harm are essentially the same (compared to the DNS Abuse Framework), we decided to go with "DNS Security Threat". We also considered that there should be evidence of such a threat, and that it should be active as opposed to resolved (e.g. a domain that was compromised and used for abuse, but has since been restored to appropriate usage). We hope that this proposed language will be acceptable to the broader team, and look forward to feedback. I would particularly like to know if the (a) and (b) structure makes it clear that evidence is required in both cases (fraud or security threat). Thanks, -- Sarah Wyld, CIPP/E Policy & Privacy Manager Pronouns: she/they swyld(a)tucows.com

3 2

Notes and action items - TPR WG Meeting #72 - 08 December 2022 at 16:00 UTC
by Julie Hedlund Dec. 8, 2022

Dec. 8, 2022

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-pcr…> 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%2…>. 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.

1 0