Hi Frank Thank you for some very useful information here. This is the type of input we need in these discussions. I have had many discussions with the RIPE NCC legal team about this proposal. They did point out to me there is a difference between processing personal data for the 'legitimate interest of the public' and processing it by consent of the data subject. I obviously didn't fully understand the consequences of such a change. Nor did I realise that certain phrases or comments would imply such a change has been made and that the change would then apply across the board. Having read carefully what you have said here, I think we need to maintain the 'legitimate interest of the public' as the principle reason for processing personal data in the RIPE Database. It would seem this bypasses the need for explicit consent from the data subject where public interest is involved. And the public interest is in keeping the internet running and identifying the users of blocks of IP addresses. But, beyond this principle, I still see a need to change the elements of personal data that are processed for the different purposes of the database. I understand what you say about IP addresses being considered as PII, as well as the business phone number of a 1 person company. So let me try to expand on my underlying thoughts. It seems we are all now surrounded by a multitude of PII elements. Name, home address, personal/private phone number and email, business related phone number and email, your IP addresses, etc. Even though all of it can be considered to be PII, which parts do you never want to end up in the public RIPE Database registry and what absolutely must be in the database? Most people accept that your name is a must, either as a resource holder or a contact. If you work from business premises the address is no problem, but if you work from home your full address should be an absolute no, although it is currently published. Many people say we cannot separate personal phones from business phones. But that is simply not true. Suppose we work for a 2 man business. This week I am on call 24/7 to fix network problems, next week you are on call. We both have a personal phone with us. If we also have a business phone (number) that can be routed to either phone, this is the only number that needs to be published in the RIPE Database. So no one can call me at 3am to fix a problem if I am not on call as they don't have my personal number. Calling the published business number will be routed to you. Maybe this business number is still technically PII. But there is a clear distinction between our core personal details and our business personal details. To maintain a healthy work/life balance no one should be forced, coerced, pressured into having their core personal details published in the RIPE Database, not even based on public interest regardless of what they want. This is what I mean by separating personal details from business details and only publishing business details in the database. Whether this can be expressed in general legalistic, or even in practical, terminology I don't know (yet). I believe the intent of this proposal is good (although some would disagree), but I don't think the current wording is good enough. cheers denis proposal author On Wed, 26 Oct 2022 at 20:11, Frank Breedijk <f.breedijk@divd.nl> wrote:

Dennis,

Thanks for getting back to me. See my comments inline.

On 26 Oct 2022, at 19:37, denis walker <ripedenis@gmail.com> wrote:

Hi Frank

First of all I would like to thank you for joining this discussion. With any policy discussion it is important to get as wide a range of views as possible. We also like to hear from people who use the RIPE Database to get a better understanding of who uses it and for what purpose.

There has been a lot of misunderstanding over what this policy proposal is about...and what it isn't about. Let's split it into privacy and verification. On the privacy side there is no suggestion at all that we leave resources without valid contacts.

I’m happy to hear that it is not you intention to remove contacts from te database. But I am worried that an incorrectly worded policy may have that result. If RIPE NCC adopts a policy in which it states that in order for PII to live in the DB it needs permission from the subjects, then subjects may hold RIPE NCC to this policy forcing RIPE NCC into a position where it has to make a choice.

If there is a contact listed in the database you can use it to make reports. It is not your responsibility to determine if it is a personal or business contact.

Understood.

One of the main aims of this policy is to slowly change the mindset of resource holders away from entering the personal details of their staff as contacts and to switch to using business contact details. When the RIPE Database was first established, privacy on the internet was not a concern. By default, users would just enter personal details for contacts. We currently have the personal details of around 2 million people in the database. It is still growing by several thousands per month. In almost all of these cases, 'personal' details are not needed. There has to be a way to contact resource holders and network operators, but not using your home address or private phone/email.

This is a great aim, but right now the proposed policy doesn’t state this. It clearly states that RIPE NCC is going to move to a permission model.

A large proportion of resource holders and end users are corporate bodies. Where they have entered corporate contact details, nothing will change.

Again this is not what your policy states. You policy states that you should not enter PII and even somebodies corporate email address is PII. Also an abuse@ address of a company with a single owner/employee is PII. And if you say you will only process PII if you have permission, that is what you have to do.

Where they have entered personal details of staff, they will need to change this to business information. Names of contacts are the only bit of personal information that a public registry must have. People argue that personal information is OK if people consent to it. But is it really informed consent? This is an open, public database, accessible by anyone connected to the internet. It has personal details of 2m (technical) people. It can be easily (and probably is) data mined on a daily basis. Once you put your details into this database you have irreversibly broadcast them to the world.

Again this is a very good thing to do. One of the key principles in GDPR is data minimisation and you are going to practise this. It is funny that you mention consent, because consent is only consent if it is not conditional.

If somebody approaches RIPE NCC stating they did not give permission their details have to be removed from the DB. RIPE NCC cannot stop their registration because that would mean that consent was not free consent.

The policy is not based on GDPR specifically. In fact GDPR is not even mentioned in the policy text. Privacy rules existed before GDPR. The driving force behind this policy is the unease of a number of individuals that are concerned about having their personal data in the database.

But one has to consider the consequences of switching to a consent model under GDPR. And with GDPR in effect this is an ill advised move.

During this discussion some people have suggested those who are concerned about privacy could enter misleading information like PO boxes as addresses. Even maybe totally false details. We know there is a lot of false data in the database. But how can you build a public registry and advocate entering false data to overcome privacy concerns? Some investigators have said that even false data is useful if it has been used consistently. They can still do pattern matching on the false data. When the conversation goes down that path it is clear something is wrong.

Agree, this needs to be addressed.

The RIPE community has no legal definition, no legal authority, no membership. It is made up of anyone who wants to be a part of it today, perhaps gone tomorrow. This includes the good, the bad and the ugly. All those operators who take internet safety seriously are a part of this community. But so are those who provide services to the abusers, even those involved in criminal activities. They all have an equal say in policy discussions. This makes policy development very difficult.

Then we come on to the verification. You sent an email to this mailing list, exposing your email address. You referenced your web url. On that site you have a phone number and postal address. Anyone can now create a contact object (PERSON or ROLE) in the RIPE Database containing your name, address, phone and email details. That object can be referenced from any address space object, suggesting that you and your organisation are the legitimate contact for that address space. Maybe those addresses are involved in the worst kind of activity possible on the internet....and you are the contact. Unless you regularly search the database for your details to make sure no one has done this, the first you will know about it is when some investigators turn up at your office to question you. This is because anyone can enter these details into this database without the need for any verification. This policy says you can only enter a phone number if you are holding the phone in your hand. Only enter an email address if you have control over it. The policy also suggests we don't need addresses for contacts. So it prevents the worst of these types of abuses of your details. There has been so much public debate in recent years about big tech companies abusing personal information. Verification has become a part of daily life...except in the RIPE Database.

Verification is a good thing, no objections (you honor ;) )

But RIP NCC is setting itself up for a lot of trouble by going to “permission” as the GDPR ground for processing instead of “legitimate interests pursued by the controller”

The policy isn't based on GDPR, but if it was I would suggest 'legitimate public interest' rather than the controller's interest.

The policies base doesn’t matter to the effect such a policy has under GDPR. And yes, legitimate interest of the public is even better. We also use it for DIVD.

Especially this line in the proposal can be explained as such: “All organisations holding resources allocated or assigned by the RIPE NCC, or documented in the RIPE Database, must sign a declaration that they have read and understood this policy and that either all the data for their organisation and resources contained in the RIPE Database is fully compliant with this policy or they are working towards full compliance.”

Considering we have around 15k to 20k RIPE NCC Members who are all contractually bound to follow policy, and yet only about 50 people ever comment on policy discussions, I would suggest that ALL Members should be required to affirm that they acknowledge any new or changed policy annually when they are invoiced for membership.

What is the consequence of not signing this policy. If it is nothing I wish RIPE NCC good luck. If it has consequences it doesn’t count as ‘consent’. And if enough people do sign it, it creates a president that allows those with bad intentions to have their details removed.

With this statement in the policy it is quite possible that RIPE NCC at some point will have to choose between two evils: a) Either revoking all resources of those parties that did not sign a declaration b) Removing all PII of those parties from the database.

Action does not need to be taken, just get the reaffirmation annually that they state they are up to date with policy. Then if any policy violation is exposed later they cannot argue they were not aware of the new policy.

But RIPE NCC may be forced to take action at some point either by an activist, a person in the database with bad intentions or a regulating body.

What would the impact be?

I analyzed 7476 IP addresses that popped up in a certain case using ripeSTAT and whois (see attachment)

458 Afrinic 1052 APNIC 1277 ARIN 190 LACNIC 4090 RIPE 409 no RIR in ripeSTAT abuse finder API

I marked all email addresses that were not clearly a “function”/group/department mailbox as personal.

If we could not report to email addresses that were personal we would not be able to report abuse to 929 out of 7476 ip addresses. (~12%) 201 of these IP addresses belong to the rir RIPE. (of the 4090 marked as belonging to RIPE, about 5%) 180 of these come from the ripeSTAT API, so they come from a CONTACT record, not a PERSON record. In only 21 cases I had to resort to whois to get a PERSON record.

You can send your reports to any contact you see in the database. This policy does not affect you in this way.

Until those objects disappear from the database for one reason or the other.

Conclusion: A small but significant portion of “abuse” addresses are “personal” Most of these are in CONTACT records not PERSON records.

Besides these email addresses, RIPE NCC will have to do the work to be GDPR compliant for other PII anyway. IP addresses are considered PII in The Netherlands, a work/group phone number/email can still be PII, e.g. in the case where the company is a single person company or the company name can be traced back to a natural person, so going this route creates a lot of work and doesn’t actually reduce the compliance load on RIPE NCC.

As I said, this policy is not about GDPR compliance. It is about respecting basic privacy. Also arranging data that people are comfortable with so there is more chance they will enter correct data. A reliable database with valid data is in everyone's interest.

Agree. I’m worried that this policy will have a negative impact in the long run.

cheers denis policy author

Dear RIPE DB-WG, Hope this email finds you in good health! Please see my comments below, inline... Thanks. Le mer. 26 oct. 2022 à 23:39, denis walker via db-wg <db-wg@ripe.net> a écrit :

Hi Frank

Thank you for some very useful information here. This is the type of input we need in these discussions. I have had many discussions with the RIPE NCC legal team about this proposal. They did point out to me there is a difference between processing personal data for the 'legitimate interest of the public' and processing it by consent of the data subject. I obviously didn't fully understand the consequences of such a change. Nor did I realise that certain phrases or comments would imply such a change has been made and that the change would then apply across the board.

Hi Denis, Thanks for your email, brother :-) ...i would like to join you in thanking Frank, for its *frank* expression of its valuable experience; shared by some others earlier.

Having read carefully what you have said here, I think we need to maintain the 'legitimate interest of the public' as the principle reason for processing personal data in the RIPE Database.

Thanks for agreeing, Denis.

It would seem this bypasses the need for explicit consent from the data

subject where public interest is involved.

Hey...my humble take, on it, is that the consent insentive would be just keeped where it's required: under the resource holder...i might be wrong though :-/ In fact a resource holder is still bound to: (i) the RIPE Database T&C (Terms & Conditions) [1]; (ii) the RIPE Database AUP (Acceptable Use Policy) [2]; (iii) the RIPE NCC Standard Service Agreement (SSA) [3]; __ [1]: deals with both insertion & query of data - <https://www.ripe.net/manage-ips-and-asns/db/support/documentation/terms> [2]: not deals with insertion, but only with query of data - <https://www.ripe.net/manage-ips-and-asns/db/support/documentation/aup> [3]: deals with acknowledgement of reading of all applicable policies - <https://www.ripe.net/publications/docs/ripe-745> <quote> 6.1 The Member acknowledges applicability of, and adheres to, the RIPE Policies <https://www.ripe.net/ripe-policies> and RIPE NCC procedural documents. The RIPE Policies and the RIPE NCC procedural documents are publicly available from the RIPE NCC Document Store. These documents, which may be revised and updated from time to time, form an integral part of and apply fully to the RIPE NCC Standard Service Agreement. Each revised document will receive a new document number and can be found on https://www.ripe.net. Below is a non-exclusive list of these documents: - IPv4 Address Allocation and Assignment Policies in the RIPE NCC Service Region <https://www.ripe.net/ripe/docs/ipv4-policies> (current version) - Autonomous System (AS) Number Assignment Policies and Procedures <https://www.ripe.net/ripe/docs/asn-assignment> (current version) - IPv6 Address Allocation and Assignment Policy <https://www.ripe.net/ripe/docs/ipv6-policies> (current version) - RIPE NCC Activity Plan <https://www.ripe.net/ripe/docs/ap> (current version) - RIPE NCC Charging Scheme <https://www.ripe.net/ripe/docs/charging> (current version) - RIPE NCC Billing Procedure and Fee Schedule <https://www.ripe.net/participate/billing/procedure> (current version) - Closure of LIR and Deregistration of Internet Number Resources <https://www.ripe.net/ripe/docs/closure> (current version) - Transfer of Internet Number Resources <https://www.ripe.net/ripe/docs/transfer> (current version) - The RIPE NCC Clearing House Procedure <https://www.ripe.net/ripe/docs/clearinghouse> (current version) - RIPE NCC Conflict Arbitration Procedure <https://www.ripe.net/ripe/docs/arbitration> (current version) </quote > No matter whois the practical maintainer...the resource holder is actually responsible. And the public interest is in keeping the internet running and identifying

the users of blocks of IP addresses.

...right! and, as it should stand :-) Is it covering all the below section of text quoted from the T&C (Terms & Conditions) of the RIPE Database [1]? <quote> Article 3 -Purpose of the RIPE Database The RIPE Database contains information for the following purposes: - Ensuring the uniqueness of Internet number resource usage through registration of information related to the resources and Registrants - Publishing routing policies by network operators (IRR) - Facilitating coordination between network operators (network problem resolution, outage notification etc.) - Provisioning of Reverse Domain Name System (DNS) and ENUM delegations - Providing information about the Registrant and Maintainer of Internet number resources when the resources are suspected of being used for unlawful activities, to parties who are authorised under the law to receive such information. - Scientific research into network operations and topology - Providing information to parties involved in disputes over Internet number resource registrations to parties who are authorised under the law to receive such information. </quote>

But, beyond this principle, I still see a need to change the elements of personal data that are processed for the different purposes of the database.

And yes, it matters! imho. ...my, humble & free, advice would still be: __ Please propose a BCOP (Best Current Operational Practice) to try to address it. ¯¯

I understand what you say about IP addresses being

considered as PII, as well as the business phone number of a 1 person company. So let me try to expand on my underlying thoughts. It seems we are all now surrounded by a multitude of PII elements. Name, home address, personal/private phone number and email, business related phone number and email, your IP addresses, etc. Even though all of it can be considered to be PII, which parts do you never want to end up in the public RIPE Database registry and what absolutely must be in the database?

Most people accept that your name is a must, either as a resource holder or a contact. If you work from business premises the address is no problem, but if you work from home your full address should be an absolute no, although it is currently published.

You might want to add an exceptional possibility in case of clear demonstrated risks on the side of the home business owner. And that means, imho, to: (i) an authorization request with documented evidences, and (ii) approval to have the personal contact masked by an email address alias within the RIPE NCC mailing system, such as "contact$ContactId at privacy-protection·ripe.net" Many people say we cannot separate personal phones from business phones.

But that is simply not true. Suppose we work for a 2 man business. This week I am on call 24/7 to fix network problems, next week you are on call. We both have a personal phone with us. If we also have a business phone (number) that can be routed to either phone, this is the only number that needs to be published in the RIPE Database. So no one can call me at 3am to fix a problem if I am not on call as they don't have my personal number. Calling the published business number will be routed to you. Maybe this business number is still technically PII. But there is a clear distinction between our core personal details and our business personal details. To maintain a healthy work/life balance no one should be forced, coerced, pressured into having their core personal details published in the RIPE Database, not even based on public interest regardless of what they want.

This is what I mean by separating personal details from business details and only publishing business details in the database.

Denis, it appears that you have already at least one really good thing to include inside the draft of BCOP you should propose, imho ;-) Whether this can be expressed in general legalistic, or even in

practical, terminology I don't know (yet). I believe the intent of this proposal is good (although some would disagree), but I don't think the current wording is good enough.

...imho! this proposal, have now been at least demonstrated to: |1. not be able to fairly address the problem targeted; |2. have a problem which may oppose to the purpose of the RIPE DB. ...therefore, imho, it should be withdrawn asap. Shalom, --sb. cheers

denis proposal author

On Wed, 26 Oct 2022 at 20:11, Frank Breedijk <f.breedijk@divd.nl> wrote:

...

[...]

Agree. I’m worried that this policy will have a negative impact in the

long run.

...

[...]

-- Best Regards ! baya.sylvain [AT cmNOG DOT cm] |cmNOG's Structure <https://cmnog.cm/dokuwiki/Structure>|cmNOG's Surveys <https://survey2.cmnog.cm/> Subscribe to the cmNOG's Mailing List <https://lists.cmnog.cm/mailman/listinfo/cmnog/> __ *#‎LASAINTEBIBLE‬|‪#‎Romains15‬:33«*Que LE ‪#‎DIEU‬ de ‪#‎Paix‬ soit avec vous tous! ‪#‎Amen‬!*»‪#‎MaPrière‬ est que tu naisses de nouveau. #Chrétiennement‬«*Comme une biche soupire après des courants d’eau, ainsi mon âme soupire après TOI, ô DIEU!*» (#Psaumes42:2)*