Hi Ben,

thank you very much for your reply.

I am not a fan of this proposal.

Part of the value the RIPE database offers is some kind of reasonable
way to get into contact with operators, and this would basically turn
a lot of the end records into unactionable records (other than for LEA
use cases, something that I am reasonably sure that LEAs are not that
familiar with at the moment anyway)

The proposal aims to maintain communication with operators without displaying the information directly. Contacting operators must be possible using data concealment methods, such as temporary email addresses that forward to real email addresses and obfuscating the name of the contact and their organization.

The information published in the database is used not only to contact operators, but also during the reconnaissance phase of attacks on entities [1][2]. Minimizing the exposure of public information is a common countermeasure in security processes [3], and the database should offer this alternative. In response, entities hide information in the database, which can result in the database containing inaccurate information.

I've seen the value in the previous ones for removing the requirement
for phone numbers and/or addresses, but removing/hiding the entire
object is a step too far

I guess what I am not understanding is what you are trying to prevent
here by hiding the person object?

The proposal is not only for person objects, but also for other objects that allow a company or person to be identified, if the company chooses to do so. For example, inetnums in the database allows you to obtain an entity's address ranges, making it easier to identify the attack surface [4]. Person/role objects could be used for phising attacks or phone wardriving.

I am aware of the changes I am proposing. However, the alternative may be ineffective solutions, such as removing emails or phone numbers, using allocated-by-LIR to add ranges and hide end-user information, registering end-user information as ISP information [5], entering fictitious information [6][7][8], or simply not registering the information in the database ("The RIPE Database Requirements Task Force (DBTF) reported that, in May 2021, there were 16,232 PA allocations without any child PA assignments and 9,986 LIRs held PA allocations containing no PA assignments." [9]). If the database does not offer an alternative, these situations will increase over time and the information may become useless. In addition, the GDPR may impact object information, and an alternative of this type can help preserve contact information while maintaining the privacy of the information.

Regards,

Rodolfo García (kix)

[1] https://www.51sec.org/2025/03/21/cehv13-notes-module-02-footprinting-and-reconnaissance/

[2] https://ethicalhack.dieg0v.com/herramientas-basicas-para-obtener-informacion-de-servidores-externos

[3] https://e-cq.net/assets/pdf/footprinting-encored.pdf

[4] https://nmap.org/book/host-discovery-find-ips.html

[5] https://apps.db.ripe.net/db-web-ui/query?searchtext=62.213.192.208

[6] https://apps.db.ripe.net/db-web-ui/lookup?source=ripe&key=DP10823-RIPE&type=person

[7] https://apps.db.ripe.net/db-web-ui/lookup?source=ripe&key=DP10824-RIPE&type=person

[8] https://apps.db.ripe.net/db-web-ui/lookup?source=ripe&key=ORG-BB268-RIPE&type=organisation

[9] https://www.ripe.net/community/policies/proposals/2022-02/