* 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. > 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" 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 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. 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. Just my 2c Lutz Donnerhacke ----- To unsubscribe from this mailing list or change your subscription options, please visit: https://mailman.ripe.net/mailman3/lists/db-wg.ripe.net/ As we have migrated to Mailman 3, you will need to create an account with the email matching your subscription before you can change your settings. More details at: https://www.ripe.net/membership/mail/mailman-3-migration/
