[GNSO-Accuracy-ST] SSAC inputs on assignment #1

Wed Dec 1 15:32:40 UTC 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 at 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 at tucows.com
>
> +1.416 535 0123 Ext. 1392
>
>
>
>
>
> *From: *Steve Crocker <steve at shinkuro.com>
> *Sent: *December 1, 2021 10:24 AM
> *To: *gnso-accuracy-st at 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 at 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 at ec.europa.eu>
> *Sent:* Wednesday, December 1, 2021 8:42 AM
> *To:* Roger D Carney <rcarney at godaddy.com>; gnso-accuracy-st at icann.org <
> gnso-accuracy-st at icann.org>
> *Subject:* RE: [GNSO-Accuracy-ST] Update - Working Accuracy Contractual
> Construct/ Definition
>
>
>
> You don't often get email from melina.stroungi at 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 at .
>
>
>
> 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 at icann.org> *On Behalf
> Of *Roger D Carney via GNSO-Accuracy-ST
> *Sent:* Wednesday, December 1, 2021 3:13 PM
> *To:* gnso-accuracy-st at 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 at icann.org> on behalf
> of Michael Palage <michael at palage.com>
> *Sent:* Tuesday, November 30, 2021 1:57 PM
> *To:* 'Lori Schulman' <lschulman at inta.org>; 'Sarah Wyld' <swyld at tucows.com>;
> gnso-accuracy-st at icann.org <gnso-accuracy-st at 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 at .
>
>
>
> 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%2Furldefense.com%2Fv3%2F__https%3A%2Finformation.aero%2Fregistration__%3B!!DOxrgLBm!SlIPgOHk4NUnDgEMMf0nXcx1obQx41WYLv5aA_ETG0vREgw_a_nVQgvECCSTz8HOB-UAlJdR%24&data=04%7C01%7Crcarney%40godaddy.com%7Ce9663d4bb92848d46f1708d9b4d8d81e%7Cd5f1622b14a345a6b069003f8dc4851f%7C0%7C0%7C637739666993892481%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=bzqgllRezmIrWzGz%2BaZdiKoClFr0d53LVkdrM%2Fhusuc%3D&reserved=0>
> and https://information.aero/node/add/request-aero-id
> <https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.com%2Fv3%2F__https%3A%2Finformation.aero%2Fnode%2Fadd%2Frequest-aero-id__%3B!!DOxrgLBm!SlIPgOHk4NUnDgEMMf0nXcx1obQx41WYLv5aA_ETG0vREgw_a_nVQgvECCSTz8HOB3ITCJxE%24&data=04%7C01%7Crcarney%40godaddy.com%7Ce9663d4bb92848d46f1708d9b4d8d81e%7Cd5f1622b14a345a6b069003f8dc4851f%7C0%7C0%7C637739666993902474%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=2PEaEvgf7KpCcOk9IWI4FAmVzcMjYumHet5PpflaBmc%3D&reserved=0>
>
>
>
>    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%2Furldefense.com%2Fv3%2F__https%3A%2Fwww.icmregistry.com%2Fabout%2Fpolicies%2Flaunch%2F*general_aval__%3BIw!!DOxrgLBm!SlIPgOHk4NUnDgEMMf0nXcx1obQx41WYLv5aA_ETG0vREgw_a_nVQgvECCSTz8HOB3TI9E9h%24&data=04%7C01%7Crcarney%40godaddy.com%7Ce9663d4bb92848d46f1708d9b4d8d81e%7Cd5f1622b14a345a6b069003f8dc4851f%7C0%7C0%7C637739666993912474%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=HRGvEwyPJkzltdcM3Z5Rs%2BflZTLlQkKe8QriVsqPnJQ%3D&reserved=0>
>
>
>
>    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-11dec17-en.pdf
>    <https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.com%2Fv3%2F__https%3A%2Fwww.icann.org%2Fen%2Fsystem%2Ffiles%2Ffiles%2Frsep-2017039-bank-et-al-request-11dec17-en.pdf__%3B!!DOxrgLBm!SlIPgOHk4NUnDgEMMf0nXcx1obQx41WYLv5aA_ETG0vREgw_a_nVQgvECCSTz8HOB4HLTjfN%24&data=04%7C01%7Crcarney%40godaddy.com%7Ce9663d4bb92848d46f1708d9b4d8d81e%7Cd5f1622b14a345a6b069003f8dc4851f%7C0%7C0%7C637739666993912474%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=X03pz69aKr4V9vus8QGSFJ5baNq09HVw2AkM8rcqvfw%3D&reserved=0>
>    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%2Furldefense.com%2Fv3%2F__https%3A%2Fwww.register.bank%2Fget-started%2F__%3B!!DOxrgLBm!SlIPgOHk4NUnDgEMMf0nXcx1obQx41WYLv5aA_ETG0vREgw_a_nVQgvECCSTz8HOBx2kcBfH%24&data=04%7C01%7Crcarney%40godaddy.com%7Ce9663d4bb92848d46f1708d9b4d8d81e%7Cd5f1622b14a345a6b069003f8dc4851f%7C0%7C0%7C637739666993922455%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=opfKI3l0A1Cbh%2FHnFLdf8zC1Y2RQhKx27dtBg94BeEU%3D&reserved=0>
>
>
>
>    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%2Furldefense.com%2Fv3%2F__https%3A%2Fnabp.pharmacy%2Fprograms%2Faccreditations-inspections%2Fdotpharmacy%2F*apply__%3BIw!!DOxrgLBm!SlIPgOHk4NUnDgEMMf0nXcx1obQx41WYLv5aA_ETG0vREgw_a_nVQgvECCSTz8HOB2DdoXPP%24&data=04%7C01%7Crcarney%40godaddy.com%7Ce9663d4bb92848d46f1708d9b4d8d81e%7Cd5f1622b14a345a6b069003f8dc4851f%7C0%7C0%7C637739666993922455%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=aZMtBH2NyWg0H64IABVIqqDk9aLm5q1Pc8zSbYI37Ug%3D&reserved=0>
>
>
>
>    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 at inta.org>
> *Sent:* Tuesday, November 30, 2021 1:06 PM
> *To:* Sarah Wyld <swyld at tucows.com>; michael at palage.com;
> gnso-accuracy-st at 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 at inta.org, www.inta.org
> <https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.com%2Fv3%2F__http%3A%2Fwww.inta.org__%3B!!DOxrgLBm!SlIPgOHk4NUnDgEMMf0nXcx1obQx41WYLv5aA_ETG0vREgw_a_nVQgvECCSTz8HOBycMdrw5%24&data=04%7C01%7Crcarney%40godaddy.com%7Ce9663d4bb92848d46f1708d9b4d8d81e%7Cd5f1622b14a345a6b069003f8dc4851f%7C0%7C0%7C637739666993932451%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=Fo%2FAqvfJvW%2BZDyJCMeLP%2BDSNM86v4D3Gao%2BmBH8S0MQ%3D&reserved=0>
>
>
>
>
>
> *From:* GNSO-Accuracy-ST <gnso-accuracy-st-bounces at icann.org> *On Behalf
> Of *Sarah Wyld
> *Sent:* Monday, November 29, 2021 3:27 PM
> *To:* michael at palage.com; gnso-accuracy-st at 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 at tucows.com
>
> +1.416 535 0123 Ext. 1392
>
>
>
>
>
> *From: *Michael Palage <michael at palage.com>
> *Sent: *November 26, 2021 12:02 PM
> *To: *gnso-accuracy-st at 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 at 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.
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mm.icann.org/pipermail/gnso-accuracy-st/attachments/20211201/be0f128f/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 63571345E95F4A7EAB8DDEBB2527DDE5.png
Type: image/png
Size: 14051 bytes
Desc: not available
URL: <https://mm.icann.org/pipermail/gnso-accuracy-st/attachments/20211201/be0f128f/63571345E95F4A7EAB8DDEBB2527DDE5-0001.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 6F62404DA7094099BCC16603621453CE.png
Type: image/png
Size: 165 bytes
Desc: not available
URL: <https://mm.icann.org/pipermail/gnso-accuracy-st/attachments/20211201/be0f128f/6F62404DA7094099BCC16603621453CE-0001.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 665C71F64CA34944B66AA257274329E8.png
Type: image/png
Size: 141 bytes
Desc: not available
URL: <https://mm.icann.org/pipermail/gnso-accuracy-st/attachments/20211201/be0f128f/665C71F64CA34944B66AA257274329E8-0001.png>