* Rodolfo García Peñas (kix) wrote:
El 26/05/2025 a las 11:24, Lutz Donnerhacke escribió:
That's the point. In the case of real trouble, you want to be able to reach out for somebody competent at the other end of the problem. That's why this information is collected, stored and made accessible.
In my opinion, the proposal does not change the fact that the information must be collected in the database and made it accessible. The information is simply there, but if the owner does not wish to display it, the database should hide it. Contact could still be made, but instead of sending an email to mailto:user@company.com, the email for the user would be mailto:a1b4au3afs.privacy-contact@ripe.net.
So you want to introduce a level of indirection, which does not tackle the problem of spam and phishing at all, but make it worse. You can be still reached by the "privacy-address", but you lose the information, which system was originating the mail. You can't anymore block well known spammer hosters, as well as combine suspicious mail body coming from dynamic address ranges. Instead, everything is coming from the well trusted RIPE servers, you never will block. Bad actors will use the privacy proxy addresses in the same way as they are using the current ones. Unless you require RIPE NCC to operate spam and phishing prevention at their servers at a very high level, those services will make the problem worse. And for what? The human eye can't recognise the mail address anymore? So the bad actors does not longer know. Who is this person, which they are sending mail to? Seriously? Okay, you might add an real proxy-privacy service at this point, like ICANN is doing. This would require a human intervention step, where the content of the message is checked for legitimate use cases. Processing time between 24 and 72 hours. Very cool solution for an (emergency) contact during a network disruption. Not! You are right, that several people do not want to give away their contact information. If this is acceptable behaviour: Fine, drop the information from the database = "Remove Whois". Otherwise if the information is necessary to operate in the Internet yourself, then you have to publish this information: Standing in public requires to be seen by others. If you do not want to stand in public, use an Internet Service Provider, which is standing there instead of you. You can't have both.
One proposal is to use a Boolean model for each field (or for all fields in the object) to indicate whether the information should be "protected" or "public."
This option would simply say either: - "I don't care about others, go die yourself" or - "I'm responsible for problems, I cause"
Another example option would be to include levels such as "public" (publicly accessible), "LEA" (accessible by LEAs), "LIR" (accessible by other authenticated LIRs), and "private" (fully private).
This option would translate to - "I'm responsible for problems, I cause" - "I don't care about others, but RIPE NCC should not be sued for" - "If everything is fine, others at my league may contact me. If things are broken, I don't care" - "I don't care about others, go die yourself"
I don't think this proposal will change behavior. Are the phone numbers published in the database currently answered? Are emails responded to? If someone does not respond to emails, RIPE NCC is notified and they try to facilitate contact. I think it could be the same in this case.
Data accuracy and responsiveness are different problems. If we conclude, that the information can*t be validated, and nobody is willing to take action on inaccurate or unresponsive entries, then this information MUST NOT be collected in the first place: "Remove Whois". Besides that, I stand for my interpretation of your proposals.
Ultra thin whois
This model is interesting and very similar to the one used in RPKI. The LIR can choose between managing the information on the LIR portal or on its own servers.
Valid extension: Let the LIR choose to use the RIPE DB instead of running their own.
However, my proposal relates to the information contained in the database and how it is displayed, not how the database is implemented (single or distributed). In both cases, the information should be the same.
You miss the point of this proposal: The only information stored in a DB is the information, is the information of the active contract, which is always known and validated. Requiring a third party (LIR) to update a subset of their contract information in a DB, which is located in a different, possibly distinct legal region, will always let to inaccuracies over time.
Remove whois
Not storing information is different from not displaying it. To fulfill its purposes, the information must be in the database, and the records and contacts may be different for an LIR and the customers of that LIR. Therefore, in my opinion, there is a need to identify inetnum/inetnum6 objects and contacts (admin, tech, zone, abuse). Contact methods will not display the information (if the user so chooses it), but the recipients will be different.
The whole purpose of this database is to have access to the most accurate contact information, in order to resolve network issues quickly. Storing information and preventing access, violates this purpose. Hence, the information MUST NOT collected in the first place. Plain and simple. Lutz