[NCSG-PC] GNSO Council Accuracy Assignment - Questions to be answered by NCSG
Tomslin Samme-Nlar
mesumbeslin at gmail.com
Fri Jan 31 11:39:46 EET 2025
Hi all,
Since there are no further inputs or comments, I will proceed to submit
what I have here to the council as NCSG response, since today is the
deadline for submission.
Thanks again Farzi for your contribution to this.
Warmly,
Tomslin
On Wed, 29 Jan 2025, 07:30 Tomslin Samme-Nlar, <mesumbeslin at gmail.com>
wrote:
> Hi Farzi,
>
> Thanks for the contribution. It is timely!
>
> @everyone, are there any other suggested contributions to these questions?
>
> I am also re-attaching the ICANN Org response here since it appears the
> previous link is now broken.
>
> Warmly,
> Tomslin
>
>
>
> On Tue, 28 Jan 2025 at 15:17, farzaneh badii <farzaneh.badii at gmail.com>
> wrote:
>
>> Thanks Tomslin. Please see my responses below:
>>
>> Farzaneh
>>
>>
>> On Tue, Jan 7, 2025 at 8:58 PM Tomslin Samme-Nlar <mesumbeslin at gmail.com>
>> wrote:
>>
>>> Hi all,
>>>
>>> If you recall, Registration data accuracy has been a topic of contention
>>> in the community now for a while. Those who follow the the topic know that
>>> the Accuracy Scoping team was paused by the council due to challenges of
>>> pursuing further work on accuracy, including that
>>>
>>> 1. It is unclear whether [the scenarios] would provide useful data
>>> to inform the Accuracy Scoping Team’s efforts;
>>> 2. The scenarios are not expected to provide data as it relates to
>>> identity verification of the registrant or veracity of the contact
>>> information (i.e., the data belongs to the data subject);
>>> 3. The costs associated with a full-scale registrar audit [Scoping
>>> Team Recommendation #2] may be prohibitive when taking into account the
>>> relatively low level of insight the audit may yield;
>>> 4. ICANN does not have the authority to mandate collection of
>>> nonpublic registration data necessary to conduct reviews outside of
>>> auditing current contractual requirements; and
>>> 5. ICANN may not be able to demonstrate the purpose of some of the
>>> data processing outweighs the rights of the impacted data subject.
>>>
>>> As a result, deliberations on this topic on the council was deferred
>>> till February and an assignment to ask ICANN Org some clarifying legal
>>> questions, and thereafter ask each SG/C to respond to a set of threshold
>>> questions that will help guide the way forward on this topic was agreed by
>>> the council. ICANN Org came back with their response
>>> <https://urldefense.com/v3/__https:/us-east-1.secure-attach.amazon.com/da78dbeb-dd4d-4f3f-96c2-1d5abfe7810b/d3fd2bca-021f-494b-957c-0c800d63f333__;!!PtGJab4!5ebsdR0WRUrjpIzUO8HekPbjqckThf0GWEiIM_7eVuzWwd4NAuc_-nt2-GqtwpE87UIulB_KPGxmS00M_1a2SSvlTw$>
>>> just before the December holidays.
>>>
>>> Now therefore, each SG/C is required to respond to the threshold
>>> questions
>>> <https://gnso.icann.org/sites/default/files/policy/2024/draft/draft-concept-proposal-accuracy-12sep24.pdf>
>>> by Friday 31 January 2025. We forgot to include it for discussion in our
>>> Policy meeting earlier this week. However, I request that members provide
>>> their input via this email thread. Once agreed, we'll forward our response
>>> to the Council. The questions we have to answer are in the link above but
>>> for convenience, I'll list them here below:
>>>
>>> 1. *What are concrete and articulable examples of what inaccurate
>>> data DOES prevent or inhibit, and how does it do so?*
>>>
>>> Inaccurate domain name registrant data should be defined based on the
>> purpose of accuracy within the scope of ICANN's mandate: ensuring that the
>> registrant is 'contactable.' If the registrant cannot be reached due to
>> undeliverable messages caused by errors in the provided contact details,
>> the data should be deemed inaccurate.
>>
>>>
>>> 1. *What are concrete and articulable examples of what inaccurate
>>> data does NOT prevent?*
>>>
>>>
>>> 1. *Are there specific stakeholders, industries, or sectors
>>> particularly vulnerable to the effects of inaccurate registration data? If
>>> so, what are they and why?*
>>>
>>> Domain name registrants can be affected by insisting on having even more
>> "accuracy" requirements. In order to ensure accuracy suggestions could be
>> made to "identify" domain name registrants which goes against the principle
>> of respecting anonymity should the domain name registrant want to remain
>> anonymous and identification of registrants can have an adverse impact on
>> data protection and access to domain names globally.
>>
>>
>>
>>> 1. *Given the examples provided in response to the three questions
>>> above (if any), please articulate a short problem statement for accuracy.
>>> The problem statement should consider:*
>>> - *What is the current problem or challenge?*
>>> - *What are the consequences of this problem or challenge?*
>>> - *What is the ultimate objective of working on this problem or
>>> challenge?*
>>> - *Considering the limitations of data processing, how do you
>>> propose to address this problem?*
>>>
>>> We don't believe there are many challenges facing data accuracy. There
>> are already requirements in place for domain name registrants to keep their
>> data accurate, and there is an ultimate punishment for that: losing their
>> domain name if they don't do so. Please refer to registrants obligation
>> here:
>> https://www.icann.org/resources/pages/registration-data-accurate-2023-11-02-en?utm_source=chatgpt.com
>>
>>
>>>
>>> 1. *Is now the appropriate time to address the problem? For example,
>>> some stakeholders have mentioned the implementation of NIS2 as an important
>>> precursor to understanding new accuracy requirements. Should this or other
>>> examples be considered prior to engaging in potential policy work?*
>>>
>>> it's crucial to remember that NIS2 is a directive, not a regulation. Its
>> implementation will vary across European jurisdictions, and it shouldn't
>> set the accuracy standard for ICANN. This is due to two key reasons:
>>
>> 1. NIS2's provisions concerning domain names were influenced by specific
>> stakeholder groups, not by multistakeholder consensus.
>> 2. Some transposing laws (e.g., Germany) aim to identify registrants
>> through data accuracy to prevent fraud. However, we believe that accuracy
>> at ICANN should not necessitate registrant identification.
>>
>>>
>>> 1. *Are the ICANN org alternatives proposals worth exploring, such
>>> as:*
>>> - *Provision of historical audit data that measures registrars’
>>> compliance with accuracy-related provisions in the RAA.*
>>> - *Engagement with contracted parties and ccTLD operators on
>>> developments in European policymaking regarding registration data accuracy.*
>>> 2. *What are the limitations of the ICANN proposals? Why should or
>>> should they not be pursued?*
>>> 3. *What other possibilities can be explored to move our work on
>>> Accuracy forward?*
>>>
>>> I look forward to your contribution to these questions.
>>>
>>> Warmly,
>>> Tomslin
>>>
>>>
>>>
>>> ---------- Forwarded message ---------
>>> From: Feodora Hamza via council <council at icann.org>
>>> Date: Thu, 12 Dec 2024 at 23:11
>>> Subject: [council] Re: Follow-up GNSO Council Accuracy Assignment
>>> To: DiBiase, Gregory <dibiase at amazon.com>, council at gnso.icann.org <
>>> council at gnso.icann.org>
>>>
>>>
>>> Dear Councilors,
>>>
>>>
>>>
>>> due to technical issues, please see accuracy assignment attached and
>>> linked below.
>>>
>>> Accuracy Assignment:
>>> https://gnso.icann.org/sites/default/files/policy/2024/draft/draft-concept-proposal-accuracy-12sep24.pdf
>>>
>>>
>>>
>>> Kind regards,
>>>
>>> Feodora Hamza
>>>
>>>
>>>
>>> *From: *"DiBiase, Gregory via council" <council at icann.org>
>>> *Reply to: *"DiBiase, Gregory" <dibiase at amazon.com>
>>> *Date: *Thursday, 12 December 2024 at 20:57
>>> *To: *"council at gnso.icann.org" <council at gnso.icann.org>
>>> *Subject: *[council] Follow-up GNSO Council Accuracy Assignment
>>>
>>>
>>>
>>> - *Attachments protected by Amazon: *
>>> - Answer to the GNSO questions on accuracy.pdf
>>> [us-east-1.secure-attach.amazon.com]
>>> <https://urldefense.com/v3/__https:/us-east-1.secure-attach.amazon.com/da78dbeb-dd4d-4f3f-96c2-1d5abfe7810b/d3fd2bca-021f-494b-957c-0c800d63f333__;!!PtGJab4!5ebsdR0WRUrjpIzUO8HekPbjqckThf0GWEiIM_7eVuzWwd4NAuc_-nt2-GqtwpE87UIulB_KPGxmS00M_1a2SSvlTw$> |
>>>
>>> - ATT00001.txt [us-east-1.secure-attach.amazon.com]
>>> <https://urldefense.com/v3/__https:/us-east-1.secure-attach.amazon.com/da78dbeb-dd4d-4f3f-96c2-1d5abfe7810b/94d6cb3e-3ab2-446c-a385-9c201a9cffc9__;!!PtGJab4!5ebsdR0WRUrjpIzUO8HekPbjqckThf0GWEiIM_7eVuzWwd4NAuc_-nt2-GqtwpE87UIulB_KPGxmS00M_1ZAKmAJaA$> |
>>>
>>>
>>> Amazon has replaced the attachments in this email with download links.
>>> Downloads will be available until January 11, 2025, 19:56 (UTC+00:00). Tell
>>> us what you think [amazonexteu.qualtrics.com]
>>> <https://urldefense.com/v3/__https:/amazonexteu.qualtrics.com/jfe/form/SV_ehuz6zGo8YnsRKK__;!!PtGJab4!5ebsdR0WRUrjpIzUO8HekPbjqckThf0GWEiIM_7eVuzWwd4NAuc_-nt2-GqtwpE87UIulB_KPGxmS00M_1Zzdd6ztA$>
>>>
>>> For more information click here [docs.secure-attach.amazon.com]
>>> <https://urldefense.com/v3/__https:/docs.secure-attach.amazon.com/guide__;!!PtGJab4!5ebsdR0WRUrjpIzUO8HekPbjqckThf0GWEiIM_7eVuzWwd4NAuc_-nt2-GqtwpE87UIulB_KPGxmS00M_1ZzNkqBbQ$>
>>>
>>> Dear Councilors,
>>>
>>>
>>>
>>> I am following up on the attached email from ICANN Org in which they
>>> provided their input on the accuracy assignment. On 25 October, we shared
>>> the proposed accuracy assignment, which included questions for ICANN org
>>> and the community.
>>>
>>>
>>>
>>> Now that ICANN org has provided responses to the Council’s questions, we
>>> are now sending the remaining questions in the attached proposal to
>>> interested SG/C/ACs for their input. Given the proximity to the holidays,
>>> we propose giving groups until Friday, 31 January 2025 to provide their
>>> input to the Council.
>>>
>>>
>>>
>>> As noted during the Council’s previous discussions on the topic of
>>> accuracy, the Council recognizes the importance of accuracy and is
>>> committed to making progress on this issue. Your group’s responses to these
>>> questions are very important for the Council’s future discussion, and we
>>> strongly encourage your groups to think about these questions and provide
>>> candid responses.
>>>
>>>
>>>
>>> Thank you in advance for your input.
>>>
>>>
>>>
>>> Thanks,
>>>
>>> Greg
>>> _______________________________________________
>>> council mailing list -- council at icann.org
>>> To unsubscribe send an email to council-leave at icann.org
>>>
>>> _______________________________________________
>>> 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: <http://lists.ncsg.is/pipermail/ncsg-pc/attachments/20250131/b87119b2/attachment-0001.htm>
More information about the NCSG-PC
mailing list