- GNSO-Accuracy-ST - lists.icann.org

Post call | Registration Data Accuracy Scoping Team | Thursday, 02 December 2021
by Terri Agnew Dec. 2, 2021

Dec. 2, 2021

Dear all, All recordings for the Registration Data Accuracy Scoping Team held on Thursday, 02 December 2021 can be found on the agenda wiki page <https://community.icann.org/x/4gC7Cg> (attendance included) and the GNSO Master Calendar [gnso.icann.org]<https://urldefense.com/v3/__https:/gnso.icann.org/en/group-activities/calen…>. These include: * Attendance (please let me know if your name has been left off the attendance list) * Audio recording * Zoom chat archive * Zoom recording (including audio, visual, rough transcript) * Transcript For additional information, you may consult the mailing list archives <https://mm.icann.org/pipermail/gnso-accuracy-st/> and the main wiki page<https://community.icann.org/x/hQIuCg>. Thank you! Kind Regards, Terri

1 0

Doodle | RDA ST Team reschedule of 16 December 2021 Team meeting
by Terri Agnew Dec. 2, 2021

Dec. 2, 2021

Dear all, As discussed on today’s team call, please complete the doodle to reschedule the Registration Data Accuracy Scoping Team currently scheduled on Thursday, 16 December 2021 at 14:00 UTC as it conflicts with the GNSO Council call (14:00-16:00 UTC). Options on doodle: Wednesday, 15 December 2021 at 14:00 UTC for 90 minutes Thursday, 16 December at 13:00 UTC for 60 minutes Thursday, 16 December at 16:00 UTC for 90 minutes Doodle: https://doodle.com/poll/8evdrs6a295y2isa?utm_source=poll&utm_medium=link Thank you. Kind regards, Terri

1 0

Meeting invitation | Registration Data Accuracy Scoping Team | Thursday, 09 December 2021 at 14:00 UTC
by Terri Agnew Dec. 2, 2021

Dec. 2, 2021

Dear all, The Registration Data Accuracy Scoping Team meeting is scheduled on Thursday, 09 December 2021 at 14:00 UTC for 90 minutes. Please click the link below to join the webinar: https://icann.zoom.us/j/94504686990?pwd=MWc2eXZENk9yN0RqOUUzaGx2eGV0QT09 Passcode: Vc#0B7$pu8 For Audio only: Or One tap mobile : US: +13017158592,,94504686990#,,,,*4631547480# or +13126266799,,94504686990#,,,,*4631547480# Webinar ID: 945 0468 6990 Passcode: 4631547480 International numbers available: https://icann.zoom.us/u/akRu7JTFd <https://urldefense.com/v3/__https:/icann.zoom.us/u/akRu7JTFd__;!!PtGJab4!pY…> If this is your first time with Zoom, please take a look here: Welcome to Zoom <https://urldefense.com/v3/__https:/gnso.icann.org/sites/default/files/polic…> Members, participants, alternates and observers all have different access and participation directions, please read below! ALL: Before joining the call * Please send 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 [icann.org]<https://urldefense.com/v3/__https:/www.icann.org/resources/pages/expected-s…> * Visit the Wiki agenda page: https://community.icann.org/x/5gC7Cg * Check your time zone: https://tinyurl.com/cxa3haye ONLY for Members and Alternates * Please join via the above Main Zoom Webinar link and staff will promote you to panelist. * Please select Panelists and Attendees, or Everyone, when posting to the chat in order for everyone to see and to be captured afterwards. * Alternate replacement confirmations – In order to keep track of alternate replacements, use the google form <https://urldefense.com/v3/__https:/forms.gle/GZqMAi4kKDaVP5o66__;!!PtGJab4!…> to communicate who the alternate is replacing and for which period. This information will be publicly posted so that the Team is aware at any time who is active. Alternate Assignment –wiki page<https://community.icann.org/x/-wC7Cg>. 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

**Starting in 15 minutes | Meeting invitation | Registration Data Accuracy Scoping Team | Thursday, 02 December 2021 at 14:00 UTC
by Terri Agnew Dec. 2, 2021

Dec. 2, 2021

**Starting in 15 minutes Dear all, The Registration Data Accuracy Scoping Team meeting is scheduled on Thursday, 02 December 2021 at 14:00 UTC for 90 minutes. Please click the link below to join the webinar: https://icann.zoom.us/j/94504686990?pwd=MWc2eXZENk9yN0RqOUUzaGx2eGV0QT09 Passcode: Vc#0B7$pu8 For Audio only: Or One tap mobile : US: +13017158592,,94504686990#,,,,*4631547480# or +13126266799,,94504686990#,,,,*4631547480# Webinar ID: 945 0468 6990 Passcode: 4631547480 International numbers available: https://icann.zoom.us/u/akRu7JTFd <https://urldefense.com/v3/__https:/icann.zoom.us/u/akRu7JTFd__;!!PtGJab4!pY…> If this is your first time with Zoom, please take a look here: Welcome to Zoom <https://urldefense.com/v3/__https:/gnso.icann.org/sites/default/files/polic…> Members, participants, alternates and observers all have different access and participation directions, please read below! ALL: Before joining the call * Please send 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 [icann.org]<https://urldefense.com/v3/__https:/www.icann.org/resources/pages/expected-s…> * Visit the Wiki agenda page: https://community.icann.org/x/4gC7Cg * Check your time zone: https://tinyurl.com/mu3fvetj [tinyurl.com]<https://urldefense.com/v3/__https:/tinyurl.com/mu3fvetj__;!!PtGJab4!olYAu5t…> ONLY for Members and Alternates * Please join via the above Main Zoom Webinar link and staff will promote you to panelist. * Please select Panelists and Attendees, or Everyone, when posting to the chat in order for everyone to see and to be captured afterwards. * Alternate replacement confirmations – In order to keep track of alternate replacements, use the google form <https://urldefense.com/v3/__https:/forms.gle/GZqMAi4kKDaVP5o66__;!!PtGJab4!…> to communicate who the alternate is replacing and for which period. This information will be publicly posted so that the Team is aware at any time who is active. Alternate Assignment –wiki page<https://community.icann.org/x/-wC7Cg>. 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, Nathalie

1 0

**REMINDER** Meeting invitation | Registration Data Accuracy Scoping Team | Thursday, 02 December 2021 at 14:00 UTC
by Julie Bisland Dec. 1, 2021

Dec. 1, 2021

Dear all, The Registration Data Accuracy Scoping Team meeting is scheduled on Thursday, 02 December 2021 at 14:00 UTC for 90 minutes. Please click the link below to join the webinar: https://icann.zoom.us/j/94504686990?pwd=MWc2eXZENk9yN0RqOUUzaGx2eGV0QT09 [icann.zoom.us]<https://urldefense.com/v3/__https:/icann.zoom.us/j/94504686990?pwd=MWc2eXZE…> Passcode: Vc#0B7$pu8 For Audio only: Or One tap mobile : US: +13017158592,,94504686990#,,,,*4631547480# or +13126266799,,94504686990#,,,,*4631547480# Webinar ID: 945 0468 6990 Passcode: 4631547480 International numbers available: https://icann.zoom.us/u/akRu7JTFd <https://urldefense.com/v3/__https:/icann.zoom.us/u/akRu7JTFd__;!!PtGJab4!pY…> If this is your first time with Zoom, please take a look here: Welcome to Zoom <https://urldefense.com/v3/__https:/gnso.icann.org/sites/default/files/polic…> Members, participants, alternates and observers all have different access and participation directions, please read below! ALL: Before joining the call * Please send 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 [icann.org]<https://urldefense.com/v3/__https:/www.icann.org/resources/pages/expected-s…> * Visit the Wiki agenda page: https://community.icann.org/x/4gC7Cg * Check your time zone: https://tinyurl.com/mu3fvetj ONLY for Members and Alternates * Please join via the above Main Zoom Webinar link and staff will promote you to panelist. * Please select Panelists and Attendees, or Everyone, when posting to the chat in order for everyone to see and to be captured afterwards. * Alternate replacement confirmations – In order to keep track of alternate replacements, use the google form <https://urldefense.com/v3/__https:/forms.gle/GZqMAi4kKDaVP5o66__;!!PtGJab4!…> to communicate who the alternate is replacing and for which period. This information will be publicly posted so that the Team is aware at any time who is active. Alternate Assignment –wiki page<https://community.icann.org/x/-wC7Cg>. 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, Nathalie

1 0

Re: [GNSO-Accuracy-ST] SSAC inputs on assignment #1
by Steve Crocker Dec. 1, 2021

Dec. 1, 2021

Sarah, Thanks. I said V0 what I expected the answer to be, but I didn't mean to imply I think that's the right answer. That said, what sort of syntactic validation is applied to, say, the name of the organization? Steve On Wed, Dec 1, 2021 at 10:30 AM Sarah Wyld <swyld(a)tucows.com> wrote: > Hi Steve & team, > > > > There’s perhaps an error in this chart? > > > > Where it says “V0 for all other data elements” I think it should be V1, as > syntactical validation is required for all data elements, not only the > country code (already marked as V1). > > > > Thanks, > > > > > > > > -- > > *Sarah Wyld*, CIPP/E > > > > Policy & Privacy Manager > > Pronouns: she/they > > > > swyld(a)tucows.com > > +1.416 535 0123 Ext. 1392 > > > > > > *From: *Steve Crocker <steve(a)shinkuro.com> > *Sent: *December 1, 2021 10:24 AM > *To: *gnso-accuracy-st(a)icann.org > *Subject: *[GNSO-Accuracy-ST] SSAC inputs on assignment #1 > > > > I've added the questions shown below. In the google doc, they're numbered > 16-18. Copying them into this email renumbered them 1-3. > > > > My purpose in this note is to flag a couple of points related to points > that have come up in earlier discussion. > > > > The first question emphasizes there are many different data elements, each > of which may -- and most likely will -- have its own validation level. > Moreover, for purposes of this question, the V2 level, operational > validation, is understood to be the same as agreed upon contractual clause > that's currently under discussion. > > > > The second question addresses the point that some registrars and > registries may impose higher levels of validation than is required under > the RA and RAA. > > > > The third question asks for clarification as to whether the > validation level is disclosed to the requester whenever the data element is > provided in a response. Among other things, this question speaks to Alan's > concern that a registrar might do operational validation of, say, the phone > number but not the email address, but then provide the email address and > not the phone number in response to a request. > > > > Thanks, > > > > Steve > > > > 1. What are the accuracy requirements for *each* of the data > elements collected by the registrar? If possible, use the four level scale > of V0, V1, V2, V3. > > V0 = No validation required. > > V1 = Syntactic validation > > V2 = Operational validation > > V3 = Identity validation > > > > The expected answer is > > V2 for phone and/or email > > V1 for country code > > V0 for all other data elements > > 2. Are registries and/or registrars permitted to > perform or impose a higher level of validation? > > > > The expected answer is yes, but the documentation is not explicit. > > 3. Are registrars required to provide the validation level > along with the data element in their responses, either as part of the > response or in their documentation? > > > > The expected answer is no, but the answer should be yes. > > > > On Wed, Dec 1, 2021 at 10:06 AM Roger D Carney via GNSO-Accuracy-ST < > gnso-accuracy-st(a)icann.org> wrote: > > Good Morning, > > > > Thanks Melina. In regards to the text that you highlighted, for clarity, > my statement was point in time (Oct 21 and Oct 26), not since. > > > > > > Thanks > > Roger > > > > > > *From:* STROUNGI Melina <Melina.STROUNGI(a)ec.europa.eu> > *Sent:* Wednesday, December 1, 2021 8:42 AM > *To:* Roger D Carney <rcarney(a)godaddy.com>; gnso-accuracy-st(a)icann.org < > gnso-accuracy-st(a)icann.org> > *Subject:* RE: [GNSO-Accuracy-ST] Update - Working Accuracy Contractual > Construct/ Definition > > > > You don't often get email from melina.stroungi(a)ec.europa.eu. Learn why > this is important <http://aka.ms/LearnAboutSenderIdentification> > > Caution: This email is from an external sender. Please do not click links > or open attachments unless you recognize the sender and know the content is > safe. Forward suspicious emails to isitbad@. > > > > Dear all, > > > > Unfortunately, I was away on sick leave and have not managed to hear the > recordings; so apologies in advance if I have missed important updates. > > > > Just a first reaction in relation to the point below (in highlight) that > no one initially spoke in objection to the working definition; this is not > entirely… accurate J I recall I had made certain remarks on the basis of > Michael’s proposed wording – some orally and some inserted in the google > doc. So I personally used Michael’s reworded construct as baseline. > > > > I am not aware if Michael’s proposed wording was entirely dismissed during > the last discussions where I was not present, but for sure I had expressed > my objections at the initially proposed ‘working definition/construct’ – > for instance I had stressed we should also encompass any related purposes – > not re-invent or amend current purposes but simply state what already > exists. > > > > I understand there is confusion from many of us – including myself – as to > what is the current status/starting basis, but hopefully we can all discuss > about it in our upcoming meeting. > > > > Best regards, > > Melina > > > > > > *From:* GNSO-Accuracy-ST <gnso-accuracy-st-bounces(a)icann.org> *On Behalf > Of *Roger D Carney via GNSO-Accuracy-ST > *Sent:* Wednesday, December 1, 2021 3:13 PM > *To:* gnso-accuracy-st(a)icann.org > *Subject:* Re: [GNSO-Accuracy-ST] Update - Working Accuracy Contractual > Construct/ Definition > > > > Good Morning, > > > > Thank you for your note Michael, but I think it may be a bit misleading > and the RrSG does not (and did not) agree with the suggested updates to the > current working definition of accuracy. > > > > As you have reviewed the call on Nov 4th several times, you will have > noted that I objected to these changes around the 1 hour and 11 minute > point. Specifically, around adding any mention of identity requirements as > that is just not the case in our contract or policy. I believe the > reference to ICANN's report/memo below in your email, leaves off some > important language/context. First, this report provides information on how > ICANN Compliance operates, it does not add requirements (that is only done > in contracts or Policy). Second, as I have mentioned several times, the > mention of "identity" here does not (and cannot, see first point) add any > requirements on the CP, it only states that ICANN Compliance may ask for > "...further information concerning their findings...", it does not ask or > even suggest that the Registrar do anything more than what they have > already done in their investigation. > > > > The one item I do believe we agreed to was around the "affirmative > response" idea. I don't have the specifics on this one but I think Sarah > brought up support on adding language around that idea. > > > > Additionally, as I (and others) have mentioned many times we did not > provide a proposed definition we provided the current working definition. I > understand that people may want to update/expand that definition and I > believe that is why the GNSO Council formed this Scoping Team. > > > > I will also point to prior calls, like the Oct 21st call where this > working definition was presented, and we had agreement from several SGs, > staff and the Chair that this was the baseline definition that we would > work from moving forward. I will note that I saw no chat nor anyone speak > in objection to this working definition. I once again brought this point > of agreement up during our ICANN session (36 min) and once again I did not > see or hear any objections to this being the baseline. Obviously, some > minor tweaks would occur, but the suggested changes were not minor and adds > responsibilities that just do not exist today. > > > > To be clear the RrSG does not agree with the suggested updates to the > working definition. > > > > > > Thanks > > Roger > > > > > > *From:* GNSO-Accuracy-ST <gnso-accuracy-st-bounces(a)icann.org> on behalf > of Michael Palage <michael(a)palage.com> > *Sent:* Tuesday, November 30, 2021 1:57 PM > *To:* 'Lori Schulman' <lschulman(a)inta.org>; 'Sarah Wyld' <swyld(a)tucows.com>; > gnso-accuracy-st(a)icann.org <gnso-accuracy-st(a)icann.org> > *Subject:* Re: [GNSO-Accuracy-ST] Update - Working Accuracy Contractual > Construct/ Definition > > > > Caution: This email is from an external sender. Please do not click links > or open attachments unless you recognize the sender and know the content is > safe. Forward suspicious emails to isitbad@. > > > > Hello All, > > > > As someone that watched the video recording twice allow me to recount the > events of Nov 4th. > > > > In advance of the call there had been two “definitions” (contractual > construction / explanations) put forth for consideration. One by the > Registrars and the one put forward by myself. > > > > In an effort to reconcile these two definitions, I opted to mark-up the > Registrar’s “definition”. The first change was replacing the phrase “shall > strictly” with “is.” Specifically I cited to Background Briefing > Assignment #1 which stated in relevant part that: > > > > However, if the *complaint is about identity* (e.g., the registrant is > not who they say they are), Contractual Compliance may ask the registrar to > provide further information. (emphasis added). > > > > After the group acknowledged that this excerpt from the ICANN briefing > document showed a larger remit than just syntactical and operational > accuracy, the “shall strictly” phrase was redlined and replaced with ‘is.”. > Alan Greenburg from ALAC tired to propose an alternative wording but the > redline stayed as “is”. > > > > The next proposed redline was inspired largely by the following excerpt > from the ICANN72 GAC communique which states in relevant part: > > > > The GAC gives particular importance to the verification, validation and > correction of all registration data by registrars, *and certain > registries*, in line with their contractual obligations, and supports > rigorous monitoring and enforcement of such > > contractual obligations by ICANN. (emphasis added) > > > > These changes again were made with no substantive opposition from the > group. > > > > As I have stated previously these agreed upon changes where lost when the > document was exited at the end of the call. I have consulted with ICANN Org > and they are unaware of how these changes were lost. However, I believe the > video clearly shows that the deletion was NOT an intentional act because no > one spoke to the text being removed, it just disappeared. Please review > the video for yourself, I have provided the time stamp to help make > everyone’s review easier. > > > > Now if the RySG and RsSG are going to maintain their objection to the > previous redline “definition” and instead advocate for the RrSG > “definition” we will address this topic AFTER the we conclude the questions > to ICANN Org, but before we begin our GAP analysis. > > > > I do have a specific request for Marc, Beth and Sofie. During the next > RySG call could you seek clarification from the RySG on whether Registries > believe they have a right under their Registry Agreement to verify the > accuracy of data elements that they process as part of domain name > registrations in their respective TLDs. Additionally, what steps if any > does ICANN Compliance take in connection with Registry Audits regarding > this verification as I do believe it is relevant to our discussion here in > this Working Group. > > > > Listed below are a non-exhaustive list of Registry Operators that involve > some level of accuracy /registrant vetting beyond just email and phone > accuracy (syntactical and operational) as part of their registry operations: > > > > 1. From the original 2001 proof of concept round, .AERO was one of the > first TLD that required the process of registrant data prior to being able > to obtain a gTLD domain name registration. If you look at the current > .AERO registration website you will see the following requirement: > > > > Obtain your .aero ID, prior to registration of your chosen domain name > through a .aero authorised registrar, this unique validity process screens > potential domain registrants thus ensuring the integrity and the > exclusivity of the .aero domain. > > See https://information.aero/registration > <https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefens…> > and https://information.aero/node/add/request-aero-id > <https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefens…> > > > > 1. From the 2004 Sponsored round perhaps the best example was .XXX > which made the following representations: > > > > 5.0 PREVENTING ABUSIVE REGISTRATIONS > > > > The Registry will authenticate members of the Sponsored Community, as part > of the name registration process. As part of this process, the Registry > will validate contact information for the Registrant, secure the > Registrant’s affirmative consent to the Registry-Registrant Agreement, and > issue unique Membership Credentials. The Membership Application Process > must be completed before a domain name is permitted to resolve in the TLD. > > See https://www.icmregistry.com/about/policies/launch/#general_aval > <https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefens…> > > > > 1. fTLD submitted an approved RSEP to ICANN for the processing of > Registrant information prior to registration. The name of this RSEP is > Dynamic Registration Verification and is available here, see > https://www.icann.org/en/system/files/files/rsep-2017039-bank-et-al-request… > <https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefens…> > This webpage shows the information that fTLD collects from prospective > registrants as part of their verification process, see > https://www.register.bank/get-started/ > <https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefens…> > > > > 1. NABP, the Registry Operator of .PHARMACY, has also vetted > prospective registrants as part of its registration process, see > https://nabp.pharmacy/programs/accreditations-inspections/dotpharmacy/#apply > <https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefens…> > > > > 1. In addition, every .BRAND Registry Operator has a requirement to > limit registrations in that TLD to either the Brand owner or “Trademark > Licensee” so this would be a further example of where a Registry Operator > is processing data about a Registrant (e.g. Trademark Licensee) that may or > may not appear in the Whois/RDDS output. > > > > 1. There are also numerous RSEPs filed by Registry Operators seeking > “Registration Validation” which clearly go above just syntactical and > operational validation, e.g. Chinese Real Name Verification. > > > > I hope this removes any ambiguity as to the events of Nov 4th. If, > however, the RySG and RrSG maintain their objection we will revisit prior > to our GAP analysis discussion as noted above. > > > > Best regards, > > > > Michael > > > > > > *From:* Lori Schulman <lschulman(a)inta.org> > *Sent:* Tuesday, November 30, 2021 1:06 PM > *To:* Sarah Wyld <swyld(a)tucows.com>; michael(a)palage.com; > gnso-accuracy-st(a)icann.org > *Subject:* RE: [GNSO-Accuracy-ST] Update - Working Accuracy Contractual > Construct/ Definition > > > > Hi, > > > > The changes were definitely tracked. I was under the impression that we > agreed to those changes. If so, then they should be reinserted as a > compromise that we can live with for the purposes of the scoping exercise. > Any binding definitions will be negotiated by the eventual PDP. > > > > With kind regards, > > > > Lori S. Schulman > > Senior Director, Internet Policy > > *International Trademark Association (INTA)* > > +1-202-704-0408, Skype: LSSchulman > > lschulman(a)inta.org, www.inta.org > <https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefens…> > > > > > > *From:* GNSO-Accuracy-ST <gnso-accuracy-st-bounces(a)icann.org> *On Behalf > Of *Sarah Wyld > *Sent:* Monday, November 29, 2021 3:27 PM > *To:* michael(a)palage.com; gnso-accuracy-st(a)icann.org > *Subject:* Re: [GNSO-Accuracy-ST] Update - Working Accuracy Contractual > Construct/ Definition > > > > 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(a)tucows.com > > +1.416 535 0123 Ext. 1392 > > > > > > *From: *Michael Palage <michael(a)palage.com> > *Sent: *November 26, 2021 12:02 PM > *To: *gnso-accuracy-st(a)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 > > > > _______________________________________________ > GNSO-Accuracy-ST mailing list > GNSO-Accuracy-ST(a)icann.org > https://mm.icann.org/mailman/listinfo/gnso-accuracy-st > > _______________________________________________ > 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. > > >

2 2

Re: [GNSO-Accuracy-ST] Update - Working Accuracy Contractual Construct/ Definition
by STROUNGI Melina Dec. 1, 2021

Dec. 1, 2021

Dear all, Unfortunately, I was away on sick leave and have not managed to hear the recordings; so apologies in advance if I have missed important updates. Just a first reaction in relation to the point below (in highlight) that no one initially spoke in objection to the working definition; this is not entirely… accurate :) I recall I had made certain remarks on the basis of Michael’s proposed wording – some orally and some inserted in the google doc. So I personally used Michael’s reworded construct as baseline. I am not aware if Michael’s proposed wording was entirely dismissed during the last discussions where I was not present, but for sure I had expressed my objections at the initially proposed ‘working definition/construct’ – for instance I had stressed we should also encompass any related purposes – not re-invent or amend current purposes but simply state what already exists. I understand there is confusion from many of us – including myself – as to what is the current status/starting basis, but hopefully we can all discuss about it in our upcoming meeting. Best regards, Melina From: GNSO-Accuracy-ST <gnso-accuracy-st-bounces(a)icann.org> On Behalf Of Roger D Carney via GNSO-Accuracy-ST Sent: Wednesday, December 1, 2021 3:13 PM To: gnso-accuracy-st(a)icann.org Subject: Re: [GNSO-Accuracy-ST] Update - Working Accuracy Contractual Construct/ Definition Good Morning, Thank you for your note Michael, but I think it may be a bit misleading and the RrSG does not (and did not) agree with the suggested updates to the current working definition of accuracy. As you have reviewed the call on Nov 4th several times, you will have noted that I objected to these changes around the 1 hour and 11 minute point. Specifically, around adding any mention of identity requirements as that is just not the case in our contract or policy. I believe the reference to ICANN's report/memo below in your email, leaves off some important language/context. First, this report provides information on how ICANN Compliance operates, it does not add requirements (that is only done in contracts or Policy). Second, as I have mentioned several times, the mention of "identity" here does not (and cannot, see first point) add any requirements on the CP, it only states that ICANN Compliance may ask for "...further information concerning their findings...", it does not ask or even suggest that the Registrar do anything more than what they have already done in their investigation. The one item I do believe we agreed to was around the "affirmative response" idea. I don't have the specifics on this one but I think Sarah brought up support on adding language around that idea. Additionally, as I (and others) have mentioned many times we did not provide a proposed definition we provided the current working definition. I understand that people may want to update/expand that definition and I believe that is why the GNSO Council formed this Scoping Team. I will also point to prior calls, like the Oct 21st call where this working definition was presented, and we had agreement from several SGs, staff and the Chair that this was the baseline definition that we would work from moving forward. I will note that I saw no chat nor anyone speak in objection to this working definition. I once again brought this point of agreement up during our ICANN session (36 min) and once again I did not see or hear any objections to this being the baseline. Obviously, some minor tweaks would occur, but the suggested changes were not minor and adds responsibilities that just do not exist today. To be clear the RrSG does not agree with the suggested updates to the working definition. Thanks Roger ________________________________ From: GNSO-Accuracy-ST <gnso-accuracy-st-bounces(a)icann.org<mailto:gnso-accuracy-st-bounces@icann.org>> on behalf of Michael Palage <michael(a)palage.com<mailto:michael@palage.com>> Sent: Tuesday, November 30, 2021 1:57 PM To: 'Lori Schulman' <lschulman(a)inta.org<mailto:lschulman@inta.org>>; 'Sarah Wyld' <swyld(a)tucows.com<mailto:swyld@tucows.com>>; gnso-accuracy-st(a)icann.org<mailto:gnso-accuracy-st@icann.org> <gnso-accuracy-st(a)icann.org<mailto:gnso-accuracy-st@icann.org>> Subject: Re: [GNSO-Accuracy-ST] Update - Working Accuracy Contractual Construct/ Definition Caution: This email is from an external sender. Please do not click links or open attachments unless you recognize the sender and know the content is safe. Forward suspicious emails to isitbad@. Hello All, As someone that watched the video recording twice allow me to recount the events of Nov 4th. In advance of the call there had been two “definitions” (contractual construction / explanations) put forth for consideration. One by the Registrars and the one put forward by myself. In an effort to reconcile these two definitions, I opted to mark-up the Registrar’s “definition”. The first change was replacing the phrase “shall strictly” with “is.” Specifically I cited to Background Briefing Assignment #1 which stated in relevant part that: However, if the complaint is about identity (e.g., the registrant is not who they say they are), Contractual Compliance may ask the registrar to provide further information. (emphasis added). After the group acknowledged that this excerpt from the ICANN briefing document showed a larger remit than just syntactical and operational accuracy, the “shall strictly” phrase was redlined and replaced with ‘is.”. Alan Greenburg from ALAC tired to propose an alternative wording but the redline stayed as “is”. The next proposed redline was inspired largely by the following excerpt from the ICANN72 GAC communique which states in relevant part: The GAC gives particular importance to the verification, validation and correction of all registration data by registrars, and certain registries, in line with their contractual obligations, and supports rigorous monitoring and enforcement of such contractual obligations by ICANN. (emphasis added) These changes again were made with no substantive opposition from the group. As I have stated previously these agreed upon changes where lost when the document was exited at the end of the call. I have consulted with ICANN Org and they are unaware of how these changes were lost. However, I believe the video clearly shows that the deletion was NOT an intentional act because no one spoke to the text being removed, it just disappeared. Please review the video for yourself, I have provided the time stamp to help make everyone’s review easier. Now if the RySG and RsSG are going to maintain their objection to the previous redline “definition” and instead advocate for the RrSG “definition” we will address this topic AFTER the we conclude the questions to ICANN Org, but before we begin our GAP analysis. I do have a specific request for Marc, Beth and Sofie. During the next RySG call could you seek clarification from the RySG on whether Registries believe they have a right under their Registry Agreement to verify the accuracy of data elements that they process as part of domain name registrations in their respective TLDs. Additionally, what steps if any does ICANN Compliance take in connection with Registry Audits regarding this verification as I do believe it is relevant to our discussion here in this Working Group. Listed below are a non-exhaustive list of Registry Operators that involve some level of accuracy /registrant vetting beyond just email and phone accuracy (syntactical and operational) as part of their registry operations: 1. From the original 2001 proof of concept round, .AERO was one of the first TLD that required the process of registrant data prior to being able to obtain a gTLD domain name registration. If you look at the current .AERO registration website you will see the following requirement: Obtain your .aero ID, prior to registration of your chosen domain name through a .aero authorised registrar, this unique validity process screens potential domain registrants thus ensuring the integrity and the exclusivity of the .aero domain. See https://information.aero/registration<https://urldefense.com/v3/__https:/information.aero/registration__;!!DOxrgL…> and https://information.aero/node/add/request-aero-id<https://urldefense.com/v3/__https:/information.aero/node/add/request-aero-i…> 1. From the 2004 Sponsored round perhaps the best example was .XXX which made the following representations: 5.0 PREVENTING ABUSIVE REGISTRATIONS The Registry will authenticate members of the Sponsored Community, as part of the name registration process. As part of this process, the Registry will validate contact information for the Registrant, secure the Registrant’s affirmative consent to the Registry-Registrant Agreement, and issue unique Membership Credentials. The Membership Application Process must be completed before a domain name is permitted to resolve in the TLD. See https://www.icmregistry.com/about/policies/launch/#general_aval<https://urldefense.com/v3/__https:/www.icmregistry.com/about/policies/launc…> 1. fTLD submitted an approved RSEP to ICANN for the processing of Registrant information prior to registration. The name of this RSEP is Dynamic Registration Verification and is available here, see https://www.icann.org/en/system/files/files/rsep-2017039-bank-et-al-request…<https://urldefense.com/v3/__https:/www.icann.org/en/system/files/files/rsep…> This webpage shows the information that fTLD collects from prospective registrants as part of their verification process, see https://www.register.bank/get-started/<https://urldefense.com/v3/__https:/www.register.bank/get-started/__;!!DOxrg…> 1. NABP, the Registry Operator of .PHARMACY, has also vetted prospective registrants as part of its registration process, see https://nabp.pharmacy/programs/accreditations-inspections/dotpharmacy/#apply<https://urldefense.com/v3/__https:/nabp.pharmacy/programs/accreditations-in…> 1. In addition, every .BRAND Registry Operator has a requirement to limit registrations in that TLD to either the Brand owner or “Trademark Licensee” so this would be a further example of where a Registry Operator is processing data about a Registrant (e.g. Trademark Licensee) that may or may not appear in the Whois/RDDS output. 1. There are also numerous RSEPs filed by Registry Operators seeking “Registration Validation” which clearly go above just syntactical and operational validation, e.g. Chinese Real Name Verification. I hope this removes any ambiguity as to the events of Nov 4th. If, however, the RySG and RrSG maintain their objection we will revisit prior to our GAP analysis discussion as noted above. Best regards, Michael From: Lori Schulman <lschulman(a)inta.org<mailto:lschulman@inta.org>> Sent: Tuesday, November 30, 2021 1:06 PM To: Sarah Wyld <swyld(a)tucows.com<mailto:swyld@tucows.com>>; michael(a)palage.com<mailto:michael@palage.com>; gnso-accuracy-st(a)icann.org<mailto:gnso-accuracy-st@icann.org> Subject: RE: [GNSO-Accuracy-ST] Update - Working Accuracy Contractual Construct/ Definition Hi, The changes were definitely tracked. I was under the impression that we agreed to those changes. If so, then they should be reinserted as a compromise that we can live with for the purposes of the scoping exercise. Any binding definitions will be negotiated by the eventual PDP. With kind regards, Lori S. Schulman Senior Director, Internet Policy International Trademark Association (INTA) +1-202-704-0408, Skype: LSSchulman lschulman(a)inta.org<mailto:lschulman@inta.org>, www.inta.org<https://urldefense.com/v3/__http:/www.inta.org__;!!DOxrgLBm!SlIPgOHk4NUnDgE…> From: GNSO-Accuracy-ST <gnso-accuracy-st-bounces(a)icann.org<mailto:gnso-accuracy-st-bounces@icann.org>> On Behalf Of Sarah Wyld Sent: Monday, November 29, 2021 3:27 PM To: michael(a)palage.com<mailto:michael@palage.com>; gnso-accuracy-st(a)icann.org<mailto:gnso-accuracy-st@icann.org> Subject: Re: [GNSO-Accuracy-ST] Update - Working Accuracy Contractual Construct/ Definition 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(a)tucows.com<mailto:swyld@tucows.com> +1.416 535 0123 Ext. 1392 [cid:image002.png@01D7E6CA.14D0CED0] From: Michael Palage<mailto:michael@palage.com> Sent: November 26, 2021 12:02 PM To: gnso-accuracy-st(a)icann.org<mailto: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. [cid:image001.png@01D7E2BD.34B4CF00] However, at the conclusion of the call as we were wrapping up the session, these edits were lost [cid:image002.png@01D7E2BD.34B4CF00] 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

4 4

Please Disregard - Test Message #2 to Mailman
by policy＠bacinblack.com Nov. 30, 2021

Nov. 30, 2021

Please Disregard - Test Message #2 to Mailman Berry Cobb GNSO Policy Consultant Principal | <http://bacinblack.com/> BAC in Black Consulting Mob: +1 (720) 839-5735 <https://twitter.com/berrycobb> <https://www.linkedin.com/in/berrycobb/>

1 0

Proposed Agenda - Accuracy Scoping Team meeting #7 and #8
by Marika Konings Nov. 30, 2021

Nov. 30, 2021

Dear All, As indicated by Michael, please find below the proposed agenda for meetings #7 (Thursday 25 November) and #8 (Thursday 2 December) below. As discussed during the last meeting, the gap analysis homework assignment has been updated to reflect the input received during the call as well as on the mailing list (thank you RrSG team for your suggestions). To give you all a bit more time to complete this assignment, input is now expected at the latest by 9 December, but if you are able to provide your input before that date, this would be welcomed so that review can commence during the meeting on 2 December. You can find the updated template here: https://docs.google.com/document/d/11msexuoqWSUsFj8ZjVvWF-XHpcMJntWH/edit. Please note that the template has an input table for each group represented on the scoping team. Best regards, Caitlin, Berry and Marika Registration Data Accuracy Scoping Team – Meeting #7 Thursday 25 November at 14.00 UTC 1. Welcome & Chair Updates * Administrative update 1. Confirm action items & next meeting (Thursday 2 December at 14.00 UTC) Registration Data Accuracy Scoping Team – Meeting #8 Thursday 2 December at 14.00 UTC 1. Welcome & Chair Updates (5 minutes) 1. Follow up questions to ICANN org regarding enforcement and Accuracy Reporting System (60 minutes) * Input received from scoping team to date: https://docs.google.com/document/d/1arlKdQkbRkE1LuurmDdd-PZP184_AdFm/edit * Scoping team input * Confirm final questions for submission to ICANN org 1. Gap Analysis (25 minutes) * Review input received from scoping team: https://docs.google.com/document/d/11msexuoqWSUsFj8ZjVvWF-XHpcMJntWH/edit * Scoping team input * Confirm next steps 1. Confirm action items & next meeting (Thursday 9 December at 14.00 UTC)

4 4

Update - Working Accuracy Contractual Construct / Definition
by Michael Palage Nov. 29, 2021

Nov. 29, 2021

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

4 4