I agree with William. As a broker we use various data points in determining history and legality of ownership. This is not limited to (for example) changes in (responsible) organization. Ideally, we'd like to have access to as much data as possible to paint the clearest picture we can. Regards, Wessel -----Oorspronkelijk bericht----- Van: db-wg <db-wg-bounces@ripe.net> Namens William Sylvester via db-wg Verzonden: woensdag 12 juni 2024 18:49 Aan: db-wg@ripe.net Onderwerp: Re: [db-wg] First round of cleanup of Database WG NWIs Shane, et al, I think all of what you mention regarding research vs brokers are for the purpose of doing research. Anyone who might look at historical data as a broker, researcher, or otherwise has the use case of looking at previous data versions. I think your primary use cases are ; 1) Academic research for historical consildation of changes over time. 2) Legal research for holdership, custody, or ultimately who has held a resource over time. 3) Organizational change control of past configuration, registration, etc. I am not sure we need to differentiate personas of usage (academic, broker, legal, etc.) so much as understanding the use cases of the different buckets for the purposes of informing functionality required. Thanks, William On 6/12/24, 5:03 AM, "db-wg on behalf of Shane Kerr via db-wg" <db-wg-bounces@ripe.net <mailto:db-wg-bounces@ripe.net> on behalf of db-wg@ripe.net <mailto:db-wg@ripe.net>> wrote: Peter, On 12/06/2024 10.36, Peter Hessler via db-wg wrote:

As you all know, the Database Working Group uses a different process from other working groups, and have Numbered Work Items instead of Policy Development Process.

We've had many Items on the list, and some have been there since we created the NWI process. So, the Chairs have decided that we need to go through and clean up the list so we can complete the items we wish to complete.

For this round, we'd like us to review two NWIs that are similar to each other.

https://www.ripe.net/manage-ips-and-asns/db/numbered-work-items/ <https://www.ripe.net/manage-ips-and-asns/db/numbered-work-items/>

NWI-2 - Displaying history for database objects where available NWI-17 - Historical data

We ask the working group to discuss these two Items and decide if the WG can confirm the problem statements and provide feedback if either of these Items are still a problem that should be persued.

We ask for discussion on list until Friday July 5th.

My understanding is that there are two main consumers of historical data: 1. Researchers 2. IPv4 brokers For researchers, what they are looking for is limited basically by imagination. Size trends, rate of churn, connectivity histories, market centralization, and so on; a careful study of RIPE Database records might show things for any of these and more. For IPv4 brokers, I think that they are trying to do due diligence to ensure that the space that they are managing the sale of is actually legitimate. NWI-2 aims to fix an inconsistency where deleted objects are not visible in history. Presumably this is useful for both researchers and IPv4 brokers. NWI-17 is the result of the RIPE Database Requirements Task Force report, and recommends limiting the data available to what is needed for the common use case. It also recommends fixing the historical data to handle split & merging of address blocks. Basically, I think this is all reasonable (disclaimer, I was on the task force), and ends up looking like: 1. Add support for deleted records to historical queries 2. Add support for split & merged address blocks to historical queries 3. Strip anything but the absolute necessary information from historical queries 4. Provide a way to get full historical information via some other process (possibly using NDA with the RIPE NCC or the like) For #3, I don't know what is necessary since I don't broker IPv4 sales, but probably it is something like changes to the organization responsible for a given block with the dates those occurred, and that's basically it. Cheers, -- Shane -- To unsubscribe from this mailing list, get a password reminder, or change your subscription options, please visit: https://lists.ripe.net/mailman/listinfo/db-wg

On Wed, 3 Jul 2024, denis walker via db-wg wrote: (...)

The high cost and low (if any) benefit of splitting this data is completely pointless. Or maybe it will be split on object types. But given that few people are likely to be querying the history of some of the object types, like maybe set objects and poems, does it still make any sense? Do we really have a problem making such a small range of data items available to anyone who is interested in this operational data? If there is a concern that some personal data still slips through, maybe in descr:, then perhaps it needs another legal review, not a redesign.

My recommendation is that we drop NWI-17.

cheers denis (...)

I agree with Denis and i support dropping NWI-17. Regards, Carlos

Denis, denis walker via db-wg wrote on 03/07/2024 17:33:

The Task Force (TF) made the recommendation in NWI-17, but did not give any justification for it.

the justification is included in the final DB-TF report which was published as ripe-767. The recommendations in the various NWIs should be read in the context of this report.

The high cost and low (if any) benefit of splitting this data is completely pointless. [...]

My recommendation is that we drop NWI-17.

The DB-TF considerations behind NWI-17 related to GDPR, so this wasn't a recommendation that came out of nowhere. It would be a better idea to do something about the recommendation rather than unilaterally dropping it. Since 2021, ML has become a thing. It would be interesting to see if any of the LLMs would return anything useful in response to a query along the lines of "provide a list of all database objects containing information which looks like it's PII". Nick

Radu, there are a lot of things to unpick in regard to personal information in the RIPEDB. Person objects are not authenticated or checked, except inside the scope of RIPE ARC checks. Second and third parties can create person: objects for people without verification either for the email or phone number. So there are serious questions about the accuracy of the existing data in the database. This alone needs a good deal of attention and where necessary, remediation. As a general principle, no data is better than incorrect data. In regard to who uses the data, and what they use it for, LEAs are one of many classifications of RIPE DB data consumers. The data might be of use to them if it's verified (e.g. ARC checks / LIR verification / PI contractual obligations / etc), but for other stuff like unverified person objects, or ASSIGNED-PA objects, there is no guarantee of any form about whether the data is accurate in any way. In regard to your question, accurate registration details for this data are not a legal requirement in NL, and LEAs do not have statutory access to the data. That said, there's an obligation on the RIPE NCC to ensure that the policies and practices for accessing this data are legal and fit for purpose. That will includes providing access to LEAs within the scope of GDPR in the normal course of events, or e.g. providing access to internal data following a court order. When the DBTF noted that accurate registration of data and removal of unnecessary data (= data minimisation) from the RIPE DB should be followed up in a way that the DBWG thought was appropriate, they did this because these are legal requirements. In this context, it would be unwise to drop this from the DBWG's list of outstanding tasks. Nick Radu Anghel wrote on 08/07/2024 18:36:

I also support dropping NWI-17.

Removing contact information (address/phones) from the database just because "it looks like PII" would get more confused LEAs contacting RIPE and just defeat the purpose of the DB - a way to find contact information for _who_registered_this_resource_.

For GDPR there is the "legitimate interest" when dealing with persons, while company addresses are not PII at all.

Some persons found ways to keep the DB "accurate" regarding phone numbers, among other things, just check out a few examples nic-hdl: haz nic-hdl: fsci

Radu

On Sat, Jul 6, 2024 at 4:33 PM Nick Hilliard via db-wg <db-wg@ripe.net> wrote:

...

Denis,

denis walker via db-wg wrote on 03/07/2024 17:33:

...

The Task Force (TF) made the recommendation in NWI-17, but did not give any justification for it.

the justification is included in the final DB-TF report which was published as ripe-767. The recommendations in the various NWIs should be read in the context of this report.

...

The high cost and low (if any) benefit of splitting this data is completely pointless. [...]

My recommendation is that we drop NWI-17.

The DB-TF considerations behind NWI-17 related to GDPR, so this wasn't a recommendation that came out of nowhere. It would be a better idea to do something about the recommendation rather than unilaterally dropping it.

Since 2021, ML has become a thing. It would be interesting to see if any of the LLMs would return anything useful in response to a query along the lines of "provide a list of all database objects containing information which looks like it's PII".

Nick

--

To unsubscribe from this mailing list, get a password reminder, or change your subscription options, please visit: https://lists.ripe.net/mailman/listinfo/db-wg

Radu, Radu Anghel wrote on 11/07/2024 20:57:

The lack of authentication / checks for creating person objects could indeed be a problem, but I wouldn't choose to remove the requirement for having addresses and phone numbers associated with globally unique numbers because of this.

I can think of the following situations:

1) the object is created by a LIR because the person is a customer => the LIR is responsible for maintaining the accuracy of this data according to [1]

2) the object is created by the person => if the object is associated with any resource, a LIR is again responsible for the accuracy

3) the object is created by a third party, not the person, neither the LIR => if the object is associated with any resource it is the LIR's responsibility, as it is their customer

In all these cases, the RIPE NCC is co-processor of the data, and has a responsibility for GDPR compliance.

If the person object is not associated with a resource I see no problem with the accuracy of the information.

I understand where you're coming from on this, but the legal situation is that this doesn't matter: personal data is personal data, regardless of what sort of object it's associated with or whether it's associated with any object at all. Unassociated person: objects are deleted after a period of time. This isn't incidental.

I used the LEAs as an example because RIPENCC constantly refers them to the public information available in the database, if such even potentially wrong information did not exist how would the RIPE NCC reply to their requests? [2]

It's totally worth pointing LEAs to data relating to ALLOCATED-PA and ASSIGNED-PI because that will tell them where to serve the summons. But its often pointless for ASSIGNED-PA which makes up the majority of the objects (and consequently the person: objects) in the ripedb. It would help to clarify in the RIPE DB what data is authoritative, i.e. subject to checks, and what sort of checks.

I did not suggest in any way that accurate registration details for number resources are legally required in the NL, they are required by the RIPE NCC contracts that comply with both GDPR and NL laws.

The RIPE NCC Privacy Statement [3] informs that the database shows registration details and contact information such as names, phones, postal addresses. This is a legal basis to publish these details since you have to agree with it in order to register resources, as a person or organization.

For ASSIGNED-PI and ALLOCATED-PA, the resource holder needs to provide their details, for sure. That would constitute performance of a contract. But that's not the same as publishing it to the world, regardless of what it says in the T&Cs. You can't make the leap from stating that just because the RIPE NCC Privacy Statement says the information will be published, that this implies that "legal basis" is satisfied as a basis for data processing. This is not how GDPR works. The difficulty here is that there is a mixture of PII and non-PII in the database. There's no difficulty with non-PII. The problem is that it's all mixed up together.

GDPR does not apply to company details, and both companies and natural persons agree with this information being published when requesting resources. So there is both consent and a legitimate interest in having this data and publishing it. [4]

You're correct, partly, on company details. For example, role email addresses or telephone main lines are not subject to GDPR. However, individual contact details within a company can be. E.g. Joe.Schmoe@example.com could be considered personally identifiable information, but accounts@example.com definitely not. Consent is complicated in GDPR. Legally it must be possible to withdraw consent without detriment. So if the GDPR basis for processing data is "consent", and the resource holder withdraws that consent, you gotta respect that and nothing can change contractually. This is something that the european data protection board has started taking action on in the last couple of years, and there is now case law to support this position. The rationale behind this is that if there is pressure or coercion involved, then it's not consent: it's pressure or coercion. Consent in GDPR gives the right for a data processor to hold information about a data subject if the subject agrees. But it does _not_ give the data processor the right to withdraw service if that consent is withdrawn. There are arguable points in Legitimate Interest. If this is the basis for publishing the data, then this is why the RIPE Community needs to ensure that the policies and data management practices are assessed, i.e. to ensure that if this information is published on the basis of legitimate interest, then there is careful consideration of this within GDPR, that the policies are compliant with GDPR and that the practice is compliant with the policies. In other words, if the RIPE NCC / RIPE Community makes a claim that a specific legal basis is used for processing data, then the justification for that basis must be analysed carefully and clearly described.

I understand that some might not want this type of information related to them in a public database, but registering globally unique resources is not mandatory so it is a choice they have to make. There is nobody forcing people to become *-c contacts for resources, it is either their job, so the details except the name are company details, or their choice.

See above on consent and whether personally identifiable information in the context of corporate operation constitutes PII.

Only because the RIPE NCC validated part of the details at some point in time is not a guarantee that ALLOCATED PA is accurate either.

You're correct that it doesn't guarantee accuracy, but the ARC is a process which satisfies due diligence, i.e. it's a visible and tangible demonstration that the RIPE NCC is proactive about maintaining data accuracy.

Companies and persons (that are LIRs and have ALLOCATED PA) sometimes change addresses or phones and updating the RIPE DB might not be among the things on their to-do lists.

So, for the particular case of the RIPE DB, I disagree with this principle, I think that having some potentially wrong data is much better than having an anonymous registry. There is a clear way to trace who is responsible for keeping the data accurate, and procedures to "persuade" them to fix it.

It does not really matter if the contact details are found in a person or role object, but I think it is important to continue to have them.

This is one of the issues which the DBTF has recommended to get some attention. The one thing we can all agree on is that it's a difficult area. Nick

Best,

Radu

[1] https://www.ripe.net/publications/docs/ripe-791/ [2] https://www.ripe.net/publications/docs/ripe-819/ [3] https://www.ripe.net/about-us/legal/ripe-ncc-privacy-statement/ [4] https://commission.europa.eu/law/law-topic/data-protection/reform/rules-busi...

On Thu, Jul 11, 2024 at 8:22 PM Nick Hilliard <nick@foobar.org> wrote:

...

Radu,

there are a lot of things to unpick in regard to personal information in the RIPEDB.

Person objects are not authenticated or checked, except inside the scope of RIPE ARC checks. Second and third parties can create person: objects for people without verification either for the email or phone number. So there are serious questions about the accuracy of the existing data in the database. This alone needs a good deal of attention and where necessary, remediation.

As a general principle, no data is better than incorrect data.

In regard to who uses the data, and what they use it for, LEAs are one of many classifications of RIPE DB data consumers. The data might be of use to them if it's verified (e.g. ARC checks / LIR verification / PI contractual obligations / etc), but for other stuff like unverified person objects, or ASSIGNED-PA objects, there is no guarantee of any form about whether the data is accurate in any way.

In regard to your question, accurate registration details for this data are not a legal requirement in NL, and LEAs do not have statutory access to the data. That said, there's an obligation on the RIPE NCC to ensure that the policies and practices for accessing this data are legal and fit for purpose. That will includes providing access to LEAs within the scope of GDPR in the normal course of events, or e.g. providing access to internal data following a court order.

When the DBTF noted that accurate registration of data and removal of unnecessary data (= data minimisation) from the RIPE DB should be followed up in a way that the DBWG thought was appropriate, they did this because these are legal requirements. In this context, it would be unwise to drop this from the DBWG's list of outstanding tasks.

Nick

Radu Anghel wrote on 08/07/2024 18:36:

...

I also support dropping NWI-17.

Removing contact information (address/phones) from the database just because "it looks like PII" would get more confused LEAs contacting RIPE and just defeat the purpose of the DB - a way to find contact information for _who_registered_this_resource_.

For GDPR there is the "legitimate interest" when dealing with persons, while company addresses are not PII at all.

Some persons found ways to keep the DB "accurate" regarding phone numbers, among other things, just check out a few examples nic-hdl: haz nic-hdl: fsci

Radu

On Sat, Jul 6, 2024 at 4:33 PM Nick Hilliard via db-wg <db-wg@ripe.net> wrote:

...

Denis,

denis walker via db-wg wrote on 03/07/2024 17:33:

...

The Task Force (TF) made the recommendation in NWI-17, but did not give any justification for it.

the justification is included in the final DB-TF report which was published as ripe-767. The recommendations in the various NWIs should be read in the context of this report.

...

The high cost and low (if any) benefit of splitting this data is completely pointless. [...]

My recommendation is that we drop NWI-17.

The DB-TF considerations behind NWI-17 related to GDPR, so this wasn't a recommendation that came out of nowhere. It would be a better idea to do something about the recommendation rather than unilaterally dropping it.

Since 2021, ML has become a thing. It would be interesting to see if any of the LLMs would return anything useful in response to a query along the lines of "provide a list of all database objects containing information which looks like it's PII".

Nick

--

To unsubscribe from this mailing list, get a password reminder, or change your subscription options, please visit: https://lists.ripe.net/mailman/listinfo/db-wg

_______________________________________________ db-wg mailing list -- db-wg@ripe.net To unsubscribe send an email to db-wg-leave@ripe.net

Radu Anghel wrote on 12/07/2024 06:38:

...

The difficulty here is that there is a mixture of PII and non-PII in the database. There's no difficulty with non-PII. The problem is that it's all mixed up together.

One incomplete solution for this would be to no longer allow natural persons to register resources, but I do not think this is a good idea, or something that anyone wants. I say incomplete because for example sole traders "John Doe trading as ACME" are both legal entities and natural persons at the same time.

This option should definitely be part of a discussion.

...

Consent in GDPR gives the right for a data processor to hold information about a data subject if the subject agrees. But it does _not_ give the data processor the right to withdraw service if that consent is withdrawn.

You are probably thinking of the Cookie Monster situation where you can refuse cookies you don't like and still access a website. But there are the "required" cookies that you cannot refuse.

I was referring to other things, e.g. EDPB Opinion 08/2024: "Valid Consent in the Context of Consent or Pay Models Implemented by Large Online Platforms", or the local country DPA guidelines in terms of addressing consent. For example, the IE DPA's position is:

Similarly, consent will be presumed not to have been freely given if the data subject was not given the opportunity consent separately to distinct processing operations for different purposes. As noted above, controllers should also be wary when using consent in conjunction with a contract, because if the performance of that contract is made dependent on the individual providing consent to certain processing despite it not being necessary for such performance the consent will be invalid.

I.e. holding the data is one thing, and it stands to reason that you can't register a resource without proving registration details, so in this case, performance of a contract is a legitimate basis for holding PII. Publishing it is a separate argument though, and the SSA cannot override legislation in this regard. Consent is a difficult area.

If you withdraw consent to have your name, postal address and phone with Amazon it would be tricky for them to deliver your orders, so they might "withdraw service".

Delivering packages needs PII on the basis of performance of a contract. This is a straightforward situation: no details means that the package can't be delivered.

See above, RIPE NCC is doing a great job at it.

For sure they have, and have done so for years. The proof of the pudding is that the ICANN / domain name whois was shut down on foot of a court order due to inattention to privacy legislation, but the RIPE whois service stayed up. This happened because the RIPE NCC was careful over a long period of time to be compliant with privacy legislation, initially the Data Protection Directive which was published in 1995, and then its successor, the GDPR. That said, the DBWG has a part to play in this. The DBTF identified that there were data quality and storage concerns in the ripe db which needed to be looked at. NWI-17 was one of the work items which resulted. If NWI-17, or NWI-2 / NWI-15 / NWI-18 are summarily closed on the basis that "they've been there for too long so let's just close them", then the DBWG will incur risk for the RIPE DB by not formally looking at the issues. It could potentially happen that the outcome after a reasonable assessment is: nothing needs to be changed - the DBTF didn't prescribe or pre-suppose any outcome of this assessment. They just said that the issued needed to be looked at. Nick

Hi Nick You seemed to have mixed up many issues here including privacy, data verification, 2023-04, legal basis within GDPR, lawful access, etc. I actually agree with many of the points you make. In fact I have made many of these points myself over a number of years and generally they were all ignored by the community. You may remember I put forward a policy proposal on privacy and data verification a couple of years ago. The verification part was totally rejected by the community as it would involve some extra work by LIRs. The privacy part was rejected as I suggested using consent as the basis of processing personal data in the RIPE Database. Arguments were made that it is not processed on the basis of consent, which at that time was supported by the legal impact analysis. Then we jump forward to 2023-04 where the legal analysis said ALL personal data processed by the RIPE Database is on the basis of consent. When I asked the legal team to clarify that, they remained silent. So right now we have no clear idea on what basis any or all personal data in the RIPE Database is processed according to the GDPR. I did suggest the legal team writes a very clear statement defining the basis (or bases) on which personal data is processed. There was no response to that. I still think we need this clearly defined in a way that does not keep changing, depending on what policy proposal is being reviewed. BUT...none of this has anything to do with historical queries. Ed was very clear that PERSON and ROLE objects are NOT subject to historical queries and never will be. No one will be allowed to sign an NDA and get access to this personal data. So although I agree that all of what you have said does need to be addressed, it is not relevant to NWI-17. Nothing you have said justifies the complexity required to create a split level access to historical operational data. btw it looks like you have taken over my role of writing long, detailed emails...that few people, if any, read. cheers denis ======================================================== DISCLAIMER Everything I said above is my personal, professional opinion. It is what I believe to be honest and true to the best of my knowledge. No one in this industry pays me anything. I have nothing to gain or lose by any decision. I push for what I believe is for the good of the Internet, in some small way. Nothing I say is ever intended to be offensive or a personal attack. Even if I strongly disagree with you or question your motives. Politicians question each other's motives all the time. RIPE discussion is often as much about politics and self interest as it is technical. I have a style of writing that some may not be familiar with, others sometimes use it against me. I also have OCD. It makes me see the world slightly differently to others. It drives my mind's obsessive need for detail. I can not change the way I express my detailed opinions. People may choose how to interpret them. ======================================================== On Fri, 12 Jul 2024 at 01:26, Nick Hilliard <nick@foobar.org> wrote:

Radu,

Radu Anghel wrote on 11/07/2024 20:57:

...

The lack of authentication / checks for creating person objects could indeed be a problem, but I wouldn't choose to remove the requirement for having addresses and phone numbers associated with globally unique numbers because of this.

I can think of the following situations:

1) the object is created by a LIR because the person is a customer => the LIR is responsible for maintaining the accuracy of this data according to [1]

2) the object is created by the person => if the object is associated with any resource, a LIR is again responsible for the accuracy

3) the object is created by a third party, not the person, neither the LIR => if the object is associated with any resource it is the LIR's responsibility, as it is their customer

In all these cases, the RIPE NCC is co-processor of the data, and has a responsibility for GDPR compliance.

...

If the person object is not associated with a resource I see no problem with the accuracy of the information.

I understand where you're coming from on this, but the legal situation is that this doesn't matter: personal data is personal data, regardless of what sort of object it's associated with or whether it's associated with any object at all.

Unassociated person: objects are deleted after a period of time. This isn't incidental.

...

I used the LEAs as an example because RIPENCC constantly refers them to the public information available in the database, if such even potentially wrong information did not exist how would the RIPE NCC reply to their requests? [2]

It's totally worth pointing LEAs to data relating to ALLOCATED-PA and ASSIGNED-PI because that will tell them where to serve the summons. But its often pointless for ASSIGNED-PA which makes up the majority of the objects (and consequently the person: objects) in the ripedb.

It would help to clarify in the RIPE DB what data is authoritative, i.e. subject to checks, and what sort of checks.

...

I did not suggest in any way that accurate registration details for number resources are legally required in the NL, they are required by the RIPE NCC contracts that comply with both GDPR and NL laws.

The RIPE NCC Privacy Statement [3] informs that the database shows registration details and contact information such as names, phones, postal addresses. This is a legal basis to publish these details since you have to agree with it in order to register resources, as a person or organization.

For ASSIGNED-PI and ALLOCATED-PA, the resource holder needs to provide their details, for sure. That would constitute performance of a contract. But that's not the same as publishing it to the world, regardless of what it says in the T&Cs. You can't make the leap from stating that just because the RIPE NCC Privacy Statement says the information will be published, that this implies that "legal basis" is satisfied as a basis for data processing. This is not how GDPR works.

The difficulty here is that there is a mixture of PII and non-PII in the database. There's no difficulty with non-PII. The problem is that it's all mixed up together.

...

GDPR does not apply to company details, and both companies and natural persons agree with this information being published when requesting resources. So there is both consent and a legitimate interest in having this data and publishing it. [4]

You're correct, partly, on company details. For example, role email addresses or telephone main lines are not subject to GDPR. However, individual contact details within a company can be. E.g. Joe.Schmoe@example.com could be considered personally identifiable information, but accounts@example.com definitely not.

Consent is complicated in GDPR. Legally it must be possible to withdraw consent without detriment. So if the GDPR basis for processing data is "consent", and the resource holder withdraws that consent, you gotta respect that and nothing can change contractually. This is something that the european data protection board has started taking action on in the last couple of years, and there is now case law to support this position.

The rationale behind this is that if there is pressure or coercion involved, then it's not consent: it's pressure or coercion.

Consent in GDPR gives the right for a data processor to hold information about a data subject if the subject agrees. But it does _not_ give the data processor the right to withdraw service if that consent is withdrawn.

There are arguable points in Legitimate Interest. If this is the basis for publishing the data, then this is why the RIPE Community needs to ensure that the policies and data management practices are assessed, i.e. to ensure that if this information is published on the basis of legitimate interest, then there is careful consideration of this within GDPR, that the policies are compliant with GDPR and that the practice is compliant with the policies.

In other words, if the RIPE NCC / RIPE Community makes a claim that a specific legal basis is used for processing data, then the justification for that basis must be analysed carefully and clearly described.

...

I understand that some might not want this type of information related to them in a public database, but registering globally unique resources is not mandatory so it is a choice they have to make. There is nobody forcing people to become *-c contacts for resources, it is either their job, so the details except the name are company details, or their choice.

See above on consent and whether personally identifiable information in the context of corporate operation constitutes PII.

...

Only because the RIPE NCC validated part of the details at some point in time is not a guarantee that ALLOCATED PA is accurate either.

You're correct that it doesn't guarantee accuracy, but the ARC is a process which satisfies due diligence, i.e. it's a visible and tangible demonstration that the RIPE NCC is proactive about maintaining data accuracy.

...

Companies and persons (that are LIRs and have ALLOCATED PA) sometimes change addresses or phones and updating the RIPE DB might not be among the things on their to-do lists.

So, for the particular case of the RIPE DB, I disagree with this principle, I think that having some potentially wrong data is much better than having an anonymous registry. There is a clear way to trace who is responsible for keeping the data accurate, and procedures to "persuade" them to fix it.

It does not really matter if the contact details are found in a person or role object, but I think it is important to continue to have them.

This is one of the issues which the DBTF has recommended to get some attention. The one thing we can all agree on is that it's a difficult area.

Nick

...

Best,

Radu

[1] https://www.ripe.net/publications/docs/ripe-791/ [2] https://www.ripe.net/publications/docs/ripe-819/ [3] https://www.ripe.net/about-us/legal/ripe-ncc-privacy-statement/ [4] https://commission.europa.eu/law/law-topic/data-protection/reform/rules-busi...

On Thu, Jul 11, 2024 at 8:22 PM Nick Hilliard <nick@foobar.org> wrote:

...

Radu,

there are a lot of things to unpick in regard to personal information in the RIPEDB.

Person objects are not authenticated or checked, except inside the scope of RIPE ARC checks. Second and third parties can create person: objects for people without verification either for the email or phone number. So there are serious questions about the accuracy of the existing data in the database. This alone needs a good deal of attention and where necessary, remediation.

As a general principle, no data is better than incorrect data.

In regard to who uses the data, and what they use it for, LEAs are one of many classifications of RIPE DB data consumers. The data might be of use to them if it's verified (e.g. ARC checks / LIR verification / PI contractual obligations / etc), but for other stuff like unverified person objects, or ASSIGNED-PA objects, there is no guarantee of any form about whether the data is accurate in any way.

In regard to your question, accurate registration details for this data are not a legal requirement in NL, and LEAs do not have statutory access to the data. That said, there's an obligation on the RIPE NCC to ensure that the policies and practices for accessing this data are legal and fit for purpose. That will includes providing access to LEAs within the scope of GDPR in the normal course of events, or e.g. providing access to internal data following a court order.

When the DBTF noted that accurate registration of data and removal of unnecessary data (= data minimisation) from the RIPE DB should be followed up in a way that the DBWG thought was appropriate, they did this because these are legal requirements. In this context, it would be unwise to drop this from the DBWG's list of outstanding tasks.

Nick

Radu Anghel wrote on 08/07/2024 18:36:

...

I also support dropping NWI-17.

Removing contact information (address/phones) from the database just because "it looks like PII" would get more confused LEAs contacting RIPE and just defeat the purpose of the DB - a way to find contact information for _who_registered_this_resource_.

For GDPR there is the "legitimate interest" when dealing with persons, while company addresses are not PII at all.

Some persons found ways to keep the DB "accurate" regarding phone numbers, among other things, just check out a few examples nic-hdl: haz nic-hdl: fsci

Radu

On Sat, Jul 6, 2024 at 4:33 PM Nick Hilliard via db-wg <db-wg@ripe.net> wrote:

...

Denis,

denis walker via db-wg wrote on 03/07/2024 17:33:

...

The Task Force (TF) made the recommendation in NWI-17, but did not give any justification for it.

the justification is included in the final DB-TF report which was published as ripe-767. The recommendations in the various NWIs should be read in the context of this report.

...

The high cost and low (if any) benefit of splitting this data is completely pointless. [...]

My recommendation is that we drop NWI-17.

The DB-TF considerations behind NWI-17 related to GDPR, so this wasn't a recommendation that came out of nowhere. It would be a better idea to do something about the recommendation rather than unilaterally dropping it.

Since 2021, ML has become a thing. It would be interesting to see if any of the LLMs would return anything useful in response to a query along the lines of "provide a list of all database objects containing information which looks like it's PII".

Nick

--

To unsubscribe from this mailing list, get a password reminder, or change your subscription options, please visit: https://lists.ripe.net/mailman/listinfo/db-wg

_______________________________________________ db-wg mailing list -- db-wg@ripe.net To unsubscribe send an email to db-wg-leave@ripe.net

_______________________________________________ db-wg mailing list -- db-wg@ripe.net To unsubscribe send an email to db-wg-leave@ripe.net

Nick Hilliard wrote on 14/07/2024 12:34:

you're correct that there are a number of separate issues here that need to be teased out and addressed separately. The first step in this is to build a problem definition for each of the outstanding NWIs and work from there.

pfft, solution definition, not problem definition. Nick