I am very sorry to have missed the discussion today. Thanks very much
for your informative summary Ken. I will listen to the recording of the
session today when it arrives, and chime in on the list. I have been
sitting on the RDRS group for some time.
I hope that the issue of ICANN's controllership came up, and the cost
issues. ICANN has been reluctant to take on the responsibility of
controllership for personal information of registrants, so the
registrars and registries are the data controllers....which means they
get to decide whether and when to release personal data, absent a court
order. Persons whose information is being processed (and released) do
indeed have a right to know on what basis that data is being released,
and to whom. To me this is the crux of the matter, the extent to which
ICANN wanted to assume more of a controller role and set policy on how
much data has to be released, what prices could be charged, when the
individual would be told of the release etc. Arguably all the years
that it ignored data protection law it was assuming a controller role,
because it insisted that the data be released, and any registrar (who
clearly are controllers and collect a lot more data which is more
useful, notably financial data) who wished to comply with local data
protection law had to make a case for doing so and appeal to ICANN's
legal department for permission.
We argued that requestors do not have a right to get personal
information of individuals. I expect we will continue to have to argue
that as and when ICANN moves forward with the scoping team on accuracy
of data. The GNSO Council just voted to kick that can down the road for
a few more months, but the demand for more accurate data persists.
Statistics from the current exercise will be useful when that exercise
gets going.
Kind regards
Stephanie Perrin
On 2024-02-23 12:51 p.m., Ken Herman wrote:
>
> Thanks, Farzaneh, for the clarifications. Always a learning experience
> for me. It’s likely I didn’t quite capture all the nuances, and it’s
> also possible that these points weren’t addressed.
>
> Regarding the processes used by registrars, that sounds to me like the
> crux of the issue. Regardless of the system, it is left to the
> registrars to validate the requestors and it doesn’t appear that there
> are any standards or really anything that will help registrants know
> if their registrar is likely to reveal their private, sensitive
> personal information.
>
> It would be terrific if you can participate on Monday as I’m sure
> other comments like yours will surface.
>
> And, well, maybe “ignore” wasn’t one of the options used, but it sure
> seemed that way to me, as in “maybe we won’t get to this” And maybe
> the registrars aren’t “obliged” to respond, but statistics on
> responses are being kept. Probably I could have phrased that better.
>
> Ken
>
> *From:*farzaneh badii <[log in to unmask]>
> *Sent:* Friday, February 23, 2024 12:12 PM
> *To:* Ken Herman <[log in to unmask]>
> *Cc:* NCSG-Discuss <[log in to unmask]>;
> [log in to unmask]
> *Subject:* Re: [NCUC-DISCUSS] RDRS Special Event Summary
>
> Ken
>
> Just a quick reaction to this:
>
> * Registration data, knowing who owns what domain name and how that
> owner can be contacted, is a central component of the Internet.
>
> Registration of data was never ever about "who owns" the domain name.
> It was about contactibility of registrant. We have been correcting
> ICANN board and others on this issue since the beginning of these
> discussions.
>
> * Prior to 2018, ownership data was easily available and public.
> After the EU GDPR in 2018, Ownership data became redacted.
>
> The term ownership is interesting. Never ever ownership was redacted.
> Domain name registrant is not even necessarily the owner. Also are
> registrars accepting that domain names are property to be owned?
> Great. but domain name registration data is not the ownership ledger.
>
> * As privacy laws like the GDPR began to restrict access to the
> information about owners and operators of domain names, new
> systems, like the RDRS, were developed to manage the process of
> revealing private information to those with a need to know it.
>
> it was never about access to information. It was access to private,
> sensitive personal information of people. Also the system was
> developed to give access to people who actually have a legitimate
> interest not people with a need to know it!!
>
> * *Each registrar has its own process for validating requestors,
> with no input or guidance from ICANN.*
>
> Can we at least know what those processes are?
>
> How are registrars obliged to respond but can ignore the request? Do
> they tell the requestor: hey we are ignoring you?
>
> Farzaneh
>
> On Fri, Feb 23, 2024 at 12:01 PM Ken Herman <[log in to unmask]> wrote:
>
> Hello NCSG and NCUC members.
>
> Thanks to everyone who was able to attend this week’s briefing on
> ICANN’s Remote Data Request System (RDRS).
>
> After an introduction by Wisdom, Kathy provided background and was
> followed by a presentation by Ms. Diana Middleton of ICANN. The
> session then invited Ms. Sarah Wyld and Ms. Reg Levy, both from
> the registrar Tucows, to offer their perspective.
>
> The purpose of the session was to gather facts and provide an
> opportunity for members of the non-commercial community to learn
> about the RDRS, both from the perspective of ICANN and the point
> of view of a registrar.
>
> The presenters shared a lot of information about the RDRS and the
> processes. I attached the slides from the ICANN presentation as
> well as the latest ICANN RDRS statistics report.
>
> I have put here some (not all!) of the points presented, and I
> encourage anyone who attended (or reviewed the transcript) to add
> anything important that would be useful to share.
>
> * Registration data, knowing who owns what domain name and how
> that owner can be contacted, is a central component of the
> Internet.
> * Prior to 2018, ownership data was easily available and public.
> After the EU GDPR in 2018, Ownership data became redacted.
> * As privacy laws like the GDPR began to restrict access to the
> information about owners and operators of domain names, new
> systems, like the RDRS, were developed to manage the process
> of revealing private information to those with a need to know it.
> * RDRS is a pilot, intended to run for 2 years so the board can
> gather statistics and experience before making any further
> decisions about its future.
> * The RDRS was developed to simplify the process used by
> interested parties to request redacted data.
> * Demand for the system is unknown; that is the reason for the
> pilot.
> * Originally, a System for Standardized Access and Disclosure
> (SSAD) was proposed, which included many features, but deemed
> too complex so the RDRS was created instead.
> * Parties interested in redacted data must register on the
> system and identify their role (law enforcement, government
> agencies, intellectual property professionals, cybersecurity
> researchers, et al.)
> * The system presents these registered parties with a form to
> describe their interest in a specific domain name.
> * Registrars, which are the custodians of personal data) are
> invited by ICANN to participate, but not all do. Participating
> registrars also have access to the system and can view and are
> obliged to act upon requests.
> * Participating registrars review the requests and decide what
> to do with them, to either comply, reject or ignore. For
> requests that would go to non-participating registrars,
> requestors have the option of printing a pdf of the request to
> send to the appropriate registrar.
> * Some registrars, like Tucows, already had a system to respond
> to requests for redacted data.
> * *Each participating registrar decides how to handle requests.
> This includes validating the requestor’s credentials and
> determining whether or not to comply with the request, taking
> into account their understanding of the request and compliance
> with local laws. *
> * *Each registrar has its own process for validating requestors,
> with no input or guidance from ICANN.*
> * *ICANN’s role is to accept the requests and tabulate the
> responses by registrars.*
> * *ICANN knows the details the requestor placed on the form.*
>
> ICANN publishes a monthly report with RDRS statistics. The second
> report covers from the period from inception to January 31, and is
> attached, but it can also be found at:
> https://www.icann.org/en/system/files/files/rdrs-usage-metrics-16feb24-en.pdf.
>
> Some interesting statistics:
>
> * 510 requests submitted to participating registrars.
> * 274 requests submitted (estimated) to non-participating
> registrars.
> * 35.5% of requests received from requestors self-identified as
> IP holders.
> * 11% of requests received from requestors self-identified as
> law enforcement.
> * 72% of requests received were denied.
> * 29% of denied requests were denied due to “Contracted party
> cannot disclose the data due to applicable law” (the most of
> all reasons).
>
> *All members are invited to join a follow-up session scheduled for
> Monday, February 26 at 15:00 UTC. *This is intended to be an
> informal opportunity for community members to discuss the
> information provided and to identify any further questions to
> follow-up with ICANN for information that might be useful.
>
> Thanks again to all who participated with special thanks to our
> speakers, Diana Middleton from ICANN and Sarah Wyld and Reg Levy
> from Tucows, as well as our own Kathy Kleiman, who provided the
> necessary background and Wisdom who ably acted as Master of
> Ceremony for the event. Also, we are grateful to Andrea or
> arranging the Zoom link and keeping track of questions in the
> chat. She posted the link to the recording for those interested
> but could not attend.
>
> Ken
>
> _______________________________________________
> Ncuc-discuss mailing list
> [log in to unmask]
> https://lists.ncuc.org/cgi-bin/mailman/listinfo/ncuc-discuss
>
|
