* Rodolfo García Peñas (kix) wrote:

I would like to make a proposal regarding the database so that privacy can be included in the objects.
Among the main objectives of the database [1] are "To provide accurate registration information of
these resources in order to meet a variety of operational requirements" and "Facilitating coordination
between network operators (network problem resolution, outage notification etc.)",
and therefore the database contains information to facilitate these actions.

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.

Hi Lutz,

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 user@company.com, the email for the user would be a1b4au3afs.privacy-contact@ripe.net.

In my opinion, hiding information is optional, but I think that possibility should exist and that it should be done at the database level. If this option is not offered, people may take unusual steps to hide information. For example, in the “NWI proposal: adjusting contact method requirements and adding new methods,” it can be seen that the information between the role and person objects is not consistent. Possibly, if someone wants to hide their information, they will create a role object, because it is not necessary to indicate a contact person or a telephone number. I do not know if historical information is available on the creation of these types of objects and if there has been any change in behavior in the volume of objects created since the publication of GDPR. Perhaps RIPE NCC has this statistical information. It also causes cases such as those shown in my other messages (e.g., incorrect or false information, not creating inetnum/inetnum6 objects, etc.).

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.

If this problem is really an issue, I'd propose two other models:

Ultra thin whois
================
The whois server at RIPE only contains contractual information, which delegates
every query to the responsible LIR. Every LIR is required to operate its own
whois server as part of the LIR contract with RIPE. RIPE NCC sets up monitoring
resources including penalties for not operational systems. This model has the
opportunity to comply to local law, like we have in non-EU-countries, because
the personal data does never cross juristic boundaries anymore.

IANA operates in this way:
$ whois -h whois.iana.org 217.17.192.66
refer:        whois.ripe.net
inetnum:      217.0.0.0 - 217.255.255.255
organisation: RIPE NCC
status:       ALLOCATED
whois:        whois.ripe.net
changed:      2000-06
source:       IANA

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. 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. Even so, I think it is a very interesting proposal, and perhaps it should be analyzed in a separate proposal, bearing in mind that not all LIRs are large ISPs and making them manage their own whois servers creates additional work.

Remove whois
============
According to the GDPR, no data should be collected, if there is no need for.
Hence, remove all admin-c, tech-c, zone-c, abuse-c fields from the database.
Remove all inetnum*-objects which are more specific. There is no need for.
The remaining objects are only those, which are required for RPSL queries.

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.

Remaining comment from my time at ICANN Whois Review: The LEAs do not
need whois. They only use it for an initial orientation. They assume, that
the registrar (LIR) is part of the organized crime, so all the data is
untrustworthy by definition. They are interested in the contractual data,
the registry (RIPE) has. And those data should be validated in regular
intervals.

I have indicated several possibilities for filtering the information in the database as examples. Perhaps an LIR has no problem sharing the information with LEAs or other ISPs, but it is possible that no LIR (or its customers) wants to share its address ranges and contact persons with “hackers/phishers/...”, and that is the situation we are in.

Regards,

Rodolfo García (kix)