Hi team, I (of course) can’t speak for the registries or answer this question, but I do want to say, I’m glad the text in the screenshot was not updated. The definition in that section of the document should remain as we had proposed it back on Oct 29, and any changes should be tracked elsewhere. Maybe that’s why the changes were removed? See you tomorrow, thanks! Sarah -- Sarah Wyld, CIPP/E Policy & Privacy Manager Pronouns: she/they swyld@tucows.com +1.416 535 0123 Ext. 1392 From: Michael Palage Sent: November 26, 2021 12:02 PM To: gnso-accuracy-st@icann.org Subject: [GNSO-Accuracy-ST] Update - Working Accuracy Contractual Construct/ Definition Hello All, For those colleagues that celebrated the Thanksgiving holiday yesterday, I hope you had an enjoyable time with your family and friends and did not eat too much.   I would also like to thanks those team members that showed up for our brief Administrative Call yesterday. In preparing for the call yesterday I noted some of the new additions added by the RySG to the questions for ICANN staff. Thank you for these additions Roger. This flagged a previous issue which I had raised with our ICANN colleagues last weekend and it involves the current working contractual construct / definition. In the RySG questions they cited to the proposed RrSG accuracy “definition” (aka contractual construct): "Accuracy shall be strictly defined as syntactical accuracy of the registration data elements provided by the Registered Name Holder as well as the operational accuracy of either the telephone number or the email address." Last week when I was looking for the latest and greatest contractual construct/definition I noted that there was a technical glitch when reviewing the Zoom recording which I will summarize below. If you go to the Zoom recording from the Nov 4th call you will see that the red lined version of the contractual construct/definition which was agreed to during the call and which is reflected below.   However, at the conclusion of the call as we were wrapping up the session, these edits were lost Therefore, I would like clarification from the RySG do they wish to cite the group’s current working contractual construct/definition that was agreed to during the Nov 4th call, or do they intend to cite to the RrSG pre November 4th call  contractual construct/definition? I know these technical glitches, e.g. delta in Google Doc, Alan receiving emails, and the unavailability email archives makes things a little more challenging. However, I know our ICANN colleagues are working on the email issues, and I am sure we will be able to achieve most of our work asynchronously if we put our minds to it. Best regards, Michael

Michael, I’ll try and respond as that specific RySG question was proposed by me. In asking the question I did intent to use the working definition proposed by the registrar stakeholder group. I was under the impression that the edits you had suggested had not been agreed to by the group during the Nov 4th call. I thought the edits were removed from the google document because they were not broadly supported by the scoping team. Personally I prefer the registrar’s proposed working definition. I think it more accurately (see what I did there) captures the current state of play. Given that our first task from council includes instructions to pay particular attention to the accuracy definition that ICANN compliance employs, I thought it would be useful to understand if compliance agrees with the working definition proposed by the registrars and if not is there a different definition they use. Clearly registrars and ICANN compliance have key roles when it comes to accuracy, so when it comes to understanding what the current state of accuracy is, I’m most interested in hearing from those two groups. Hopefully that is helpful. Thank you, Marc From: GNSO-Accuracy-ST <gnso-accuracy-st-bounces@icann.org> On Behalf Of Michael Palage Sent: Friday, November 26, 2021 12:02 PM To: gnso-accuracy-st@icann.org Subject: [EXTERNAL] [GNSO-Accuracy-ST] Update - Working Accuracy Contractual Construct / Definition 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. Hello All, For those colleagues that celebrated the Thanksgiving holiday yesterday, I hope you had an enjoyable time with your family and friends and did not eat too much. I would also like to thanks those team members that showed up for our brief Administrative Call yesterday. In preparing for the call yesterday I noted some of the new additions added by the RySG to the questions for ICANN staff. Thank you for these additions Roger. This flagged a previous issue which I had raised with our ICANN colleagues last weekend and it involves the current working contractual construct / definition. In the RySG questions they cited to the proposed RrSG accuracy “definition” (aka contractual construct): "Accuracy shall be strictly defined as syntactical accuracy of the registration data elements provided by the Registered Name Holder as well as the operational accuracy of either the telephone number or the email address." Last week when I was looking for the latest and greatest contractual construct/definition I noted that there was a technical glitch when reviewing the Zoom recording which I will summarize below. If you go to the Zoom recording from the Nov 4th call you will see that the red lined version of the contractual construct/definition which was agreed to during the call and which is reflected below. However, at the conclusion of the call as we were wrapping up the session, these edits were lost Therefore, I would like clarification from the RySG do they wish to cite the group’s current working contractual construct/definition that was agreed to during the Nov 4th call, or do they intend to cite to the RrSG pre November 4th call contractual construct/definition? I know these technical glitches, e.g. delta in Google Doc, Alan receiving emails, and the unavailability email archives makes things a little more challenging. However, I know our ICANN colleagues are working on the email issues, and I am sure we will be able to achieve most of our work asynchronously if we put our minds to it. Best regards, Michael