Hi All, First, I want to reiterate my thanks to ICANN Staff for the excellent work on the public comment analysis and report. The fact that we have exited a public comment period on this with so few changes and so (SO) close to being finished is a credit to the entire IRT/IPT. Second, I support Sarah’s points. I also note that the requests under this section require manual processing, analysis and response, which necessitates more time to review. ‘Business days’ were discussed at length and chosen to adhere to Rec 18 as well as to provide clear guidance across jurisdictions. Further, the rationale in Section 3 of the Addendum to the Public Comment Report<https://protect-us.mimecast.com/s/LlJ7CADgR1H1yPqFYjmxF?domain=community.ica...>, states that in response to multiple comments the IPT did not feel the timeline reflect the nature of “urgent requests”, but it doesn’t offer a rationale to support that conclusion. We discussed this at great length during the IRT process and the team agreed upon business days. Best, Beth From: IRT.RegDataPolicy <irt.regdatapolicy-bounces@icann.org> on behalf of Sarah Wyld via IRT.RegDataPolicy <irt.regdatapolicy@icann.org> Date: Wednesday, May 10, 2023 at 1:29 PM To: irt.regdatapolicy@icann.org <irt.regdatapolicy@icann.org> Subject: [EXTERNAL] Re: [IRT.RegDataPolicy] IRT Task 236 Review updated Policy Language -post Public Comment due 20230517 CAUTION: This email came from outside your organization. Don’t trust emails, links, or attachments from senders that seem suspicious or you are not expecting. ________________________________ Hello all, As provided on the call just now, my feedback on 10.6 Urgent Responses: 24 hours is not faithful implementation of the recommendation. * The Phase 1 EPDP WG did not specify the exact timeframe but they provided a framework for the implementation team to use. * The Phase 1 EPDP WG could have settled on 24 hours but did not; we can't say this must have been their intent. * Phase 1 Rec 18 said "business days", it must be business days, not calendar days or hours. The IPT expressed concern that business days vary by region, but this could instead be the reason that the Phase 1 EPDP WG chose business days instead of calendar days. Implementing as anything other than business days is not implementing the Recommendation faithfully. * Phase 1 Rec 18 said "business days", plural, they considered a minimum of 2 to fill in that X, otherwise it would have just said "day" singular * Phase 1 Rec 18 used square brackets to indicate that the phrase "[less than X business days]" goes together as a unit and that this is the timeframe which needs to be specified. It is not (round brackets) to indicate it as a side thought or throwaway idea. * RAA requirements for Abuse Reports are for different a thing and are handled differently (and often by a different team) than disclosure reports. The Phase 1 EPDP WG was aware of this requirement and could have made urgent disclosure requests be 24 hours if they wanted to, they did not. * This is the maximum, not standard. The expectation is to respond without undue delay. We must stick with 2 business days. -- Sarah Wyld, CIPP/E Policy & Privacy Manager Pronouns: she/they swyld@tucows.com<mailto:swyld@tucows.com> From: Dennis Chang via IRT.RegDataPolicy<mailto:irt.regdatapolicy@icann.org> Sent: May 4, 2023 10:13 AM To: Anderson, Marc via IRT.RegDataPolicy<mailto:irt.regdatapolicy@icann.org> Subject: [IRT.RegDataPolicy] IRT Task 236 Review updated Policy Language -post Public Comment due 20230517 Dear IRT, We’ve completed review of all public comments and made the updates to the policy language. Prepared are the redline version and the clean version for your review. * The Registration Data Policy with redlined changes resulting from Public Comment: Registration Data Policy - Redline Version Post Public Comment<https://protect-us.mimecast.com/s/z7vOCn5j2OfmqxqcJFmCq?domain=community.ica...> * The clean version of the Registration Data Policy with changes resulting from Public Comment: Registration Data Policy - CLEAN Version Post Public Comment<https://protect-us.mimecast.com/s/c98pCo2k3ytvL8LIV5_a9?domain=community.ica...> Also prepared is the Public Comment Report Addendum that documents the analysis and responses for the comments. * Public Comment Report<https://protect-us.mimecast.com/s/lbTNCpYl42CANyNcGRNFB?domain=itp.cdn.icann...> - 20 January 2023 * Public Comment Report Addendum - Responses to Registration Data Public comment<https://protect-us.mimecast.com/s/ciEyCqxmgZSXPRPiNSbcX?domain=community.ica...> - 28 April 2023 You will find all these documents posted on the IRT wiki following our normal process. https://community.icann.org/display/RDPIRT/RegDataPolicy+Implementation+Resource+Documents<https://protect-us.mimecast.com/s/kaFICmZg1yCWK6KhGtjb7?domain=community.icann.org> We’ll go over these in the IRT meeting on 10 May 2023. -- Kind Regards, Dennis S. Chang GDD Programs Director Phone: +1 213 293 7889 Sykpe: dennisSchang www.icann.org<https://protect-us.mimecast.com/s/aNV2Crknj9F2060CNhNJH?domain=icann.org> One World – One Internet

I guess 7.1.X is a matter of the interpretation of the word "transfer". 7.1.1. Domain Name > Already in place for technical reasons.  7.1.2. Registrar URL -> out of band, registrar portal  7.1.3. Registrar -> login  7.1.4. Registrar IANA ID -> out of band, account accreditation  7.1.5. Registrar Abuse Contact Email -> out of band, registrar portal  7.1.6. Registrar Abuse Contact Phone -> out of band, registrar portal  7.1.7. Domain Status(es) -> Already in place for technical reasons. Makes me wonder if the above is really required for the policy. Best, Theo Op 11/05/2023 om 11:42 schreef Theo Geurts via IRT.RegDataPolicy:

Hi,

The policy states the following;

7. Transfer of Registration Data from Registrar to Registry Operator 7.1. Registrar MUST transfer the following data elements to Registry Operator: (See Implementation Note B.1-2) 7.1.1. Domain Name 7.1.2. Registrar URL 7.1.3. Registrar 7.1.4. Registrar IANA ID 7.1.5. Registrar Abuse Contact Email 7.1.6. Registrar Abuse Contact Phone 7.1.7. Domain Status(es)

However this is not how it technically works.

When you send a domain create to the registry using EPP it contains the following information.

1 Domain name

2 Name servers (optional)

3 Period 1-10

That is it.

The same goes for the registrar WHOIS server, this is not something registrars send to the registry.

A note on the IANA ID, only Verisign uses that. Other gTLD's use a different ID in their database and as such in the RDAP/WHOIS output.

7.5.2. Reseller This information is not send to a registry. Such information is available sometimes at an RDAP or WHOIS server.

Section 9.2.5 Proxy services. In order to make this work we need an new EPP extension to mark such registrations so the registry can identify such registrations.

From an implementation point of view. The changes at the registry and registrar level are massive. Let me boil this down to three phases of implementation.

Registry changes, backwards compatible

* admin/billing/tech optional * registrant optional if no processing agreement * thin contacts, (name, phone, email only for tech contacts) * implement epp disclose mandatory * accredited privacy epp extension

Registry changes + migration

* adjust systems * disclose update * delete admin/billing/tech * EPP extension accredited privacy

Registry changes, final

* delete admin/billing data & support * tech delete additional data?

The above is just high level, most likely I missed a few other things. However if there is an idea to implement all this within a one month time frame at a set date, that is going to be very risky and a real challenge and I advise not to go down that route.

Best,

Theo

Op 04/05/2023 om 16:08 schreef Dennis Chang via IRT.RegDataPolicy:

...

Dear IRT,

We’ve completed review of all public comments and made the updates to the policy language.

Prepared are the redline version and the clean version for your review.

* The Registration Data Policy with redlined changes resulting from Public Comment: Registration Data Policy - *Redline Version Post Public Comment* <https://community.icann.org/download/attachments/124847947/Registration%20Da...> * The clean version of the Registration Data Policy with changes resulting from Public Comment: Registration Data Policy - *CLEAN Version Post Public Comment* <https://community.icann.org/download/attachments/124847947/Registration%20Da...>

Also prepared is the Public Comment Report Addendum that documents the analysis and responses for the comments.

* Public Comment Report <https://itp.cdn.icann.org/en/files/contracted-parties/public-comment-summary...> - 20 January 2023 * Public Comment Report Addendum - Responses to Registration Data Public comment <https://community.icann.org/download/attachments/124847947/Public%20Comment%...> - 28 April 2023

You will find all these documents posted on the IRT wiki following our normal process. https://community.icann.org/display/RDPIRT/RegDataPolicy+Implementation+Reso...

We’ll go over these in the IRT meeting on 10 May 2023.

--

Kind Regards,

Dennis S. Chang

GDD Programs Director

Phone: +1 213 293 7889

Sykpe: dennisSchang

www.icann.org <http://www.icann.org> One World – One Internet

_______________________________________________ IRT.RegDataPolicy mailing list IRT.RegDataPolicy@icann.org https://mm.icann.org/mailman/listinfo/irt.regdatapolicy

_______________________________________________ By submitting your personal data, you consent to the processing of your personal data for purposes of subscribing to this mailing list accordance with the ICANN Privacy Policy (https://www.icann.org/privacy/policy) and the website Terms of Service (https://www.icann.org/privacy/tos). You can visit the Mailman link above to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on.

_______________________________________________ IRT.RegDataPolicy mailing list IRT.RegDataPolicy@icann.org https://mm.icann.org/mailman/listinfo/irt.regdatapolicy

_______________________________________________ By submitting your personal data, you consent to the processing of your personal data for purposes of subscribing to this mailing list accordance with the ICANN Privacy Policy (https://www.icann.org/privacy/policy) and the website Terms of Service (https://www.icann.org/privacy/tos). You can visit the Mailman link above to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on.

Just to clarify – I didn’t mean my comments say that Marc had suggested moving the Scope information down to the Implementation Notes; instead, I think the IPT team had moved it and Marc was saying to put it back up in the Scope section (and that’s what I was supporting). Thanks, sorry for any confusion! -- Sarah Wyld, CIPP/E Policy & Privacy Manager Pronouns: she/they swyld@tucows.com From: Sarah Wyld via IRT.RegDataPolicy Sent: May 18, 2023 12:33 PM To: Anderson, Marc; dennis.chang@icann.org; irt.regdatapolicy@icann.org Subject: Re: [IRT.RegDataPolicy] IRT Task 236 Review updated PolicyLanguage- post Public Comment due 20230517 Hello All, Thanks Marc for doing a thorough review and sending in comments, I appreciate your perspective. I support your input re moving the Scope to the Implementation Notes; the information seems best suited for the Scope section. I would also be interested especially in the answer to your question re the changes to 6.8. I agree that specifying “homepage” is not helpful and may instead cause confusion and lack of clarity. Thank you, -- Sarah Wyld, CIPP/E Policy & Privacy Manager Pronouns: she/they swyld@tucows.com From: Anderson, Marc via IRT.RegDataPolicy Sent: May 18, 2023 12:13 PM To: dennis.chang@icann.org; irt.regdatapolicy@icann.org Subject: Re: [IRT.RegDataPolicy] IRT Task 236 Review updated Policy Language- post Public Comment due 20230517 Dennis and IPT / IRT members, Here is my feedback for the task of reviewing the updated Policy Language document post public comment. Feedback: This language was in the scope section for public comment, but moved to implementation note A: Registry Operator’s and Registrar’s Processing of Personal Data contained in Registration Data for purposes other than the purposes identified in the Data Protection Agreement required by Section 5 is beyond the scope of this Policy. (See Implementation Note A.) This seems to be based on public comment feedback that “other purposes” in this section would benefit from clarity.  Simply moving the language from the scope section to the implementation note doesn’t provide any clarity, it just moves it.  The scope section seems the more appropriate place for this language.  That registries and registrar can have other purposes for processing registration data beyond the baselines set in this policy is something agreed to in the working group and has been understood throughout the IRT.  It seems important to capture that in the scope (section).  I don’t support the change of moving that language from the scope section to Implementation note A. Note: Policy Effective Data – I’ll just note that section has its own specific task, so I’ll provide my feedback to that task (and not here). Question: Can you provide a little context for why section 6.8 was changed the way it was?  I’m not sure if the changes are substantive, but they seem odd to me, and I’m not sure they are technically possible.  In a registry system, you can’t delete contact data elements.  You can add / modify / delete a contact, but you can’t delete contact data elements.  I can’t track those changes back to a public comment and I’m not sure why the change, but the original language makes more sense to me. Question: Section 9 Publication (b) of the Responses to Public comments report indicates that there was feedback to section 9.2.4 consent to publish and that following review, the IPT included suggested clarification in the implementation notes of the draft policy.  I can’t find what that is referring to.  Could I get a clarification as to what that language is.  I’ll note I’m not exactly sure what needs to be clarified as the language is 9.2.4 seems very clear and unambiguous (Registrar MUST provide the opportunity for the Registered Name Holder to provide its Consent to Publish the data element values.) Note: Section 10 Urgent requests have their owns specific task, so I’ll provide my feedback to that task (and not here). Feedback: In the implementation notes, section D (publication of registrant organization) subsection 2: the word “field’s” was replaced with “data element’s”.  To be consistent with changes made throughout the rest of the document, that should probably be “data element value’s”. Feedback: I note that the RySG feedback on section 10 specifically the “link to a page where the mechanism and process for submitting disclosure requests is detailed” did not result in changes.  The RySG pointed out that the policy recommendations deliberately do not use the word “homepage” while the policy language does and further notes that this is because the homepage is not always the best place for this link. For my company, being a registry is our primary business and the homepage makes sense as far as the location for publishing that link.  I’ve heard from other registry and registrar colleagues frustration with the “homepage” requirement as for them, being a registry or registrar isn’t necessarily their primary business and for them the “homepage” isn’t the right place for that link, and may create confusion.  I understand the IPT rejected the RySG feedback out of concern that some IRT members indicated it can be difficult finding information about disclosure requests.  Perhaps there is some middle ground that can address both concerns, for example change the language in 10.1 to “… publish on their homepage or primary page for registry and/or registrar services a direct link….” Best, Marc From: IRT.RegDataPolicy <irt.regdatapolicy-bounces@icann.org> On Behalf Of Dennis Chang via IRT.RegDataPolicy Sent: Thursday, May 4, 2023 10:08 AM To: Anderson, Marc via IRT.RegDataPolicy <irt.regdatapolicy@icann.org> Subject: [EXTERNAL] [IRT.RegDataPolicy] IRT Task 236 Review updated Policy Language - post Public Comment due 20230517 Caution: This email originated from outside the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe.  Dear IRT, We’ve completed review of all public comments and made the updates to the policy language. Prepared are the redline version and the clean version for your review. • The Registration Data Policy with redlined changes resulting from Public Comment: Registration Data Policy - Redline Version Post Public Comment • The clean version of the Registration Data Policy with changes resulting from Public Comment: Registration Data Policy - CLEAN Version Post Public Comment Also prepared is the Public Comment Report Addendum that documents the analysis and responses for the comments. • Public Comment Report - 20 January 2023 • Public Comment Report Addendum - Responses to Registration Data Public comment - 28 April 2023 You will find all these documents posted on the IRT wiki following our normal process. https://community.icann.org/display/RDPIRT/RegDataPolicy+Implementation+Reso... We’ll go over these in the IRT meeting on 10 May 2023. --  Kind Regards, Dennis S. Chang GDD Programs Director Phone: +1 213 293 7889 Sykpe: dennisSchang www.icann.org One World – One Internet