[db-wg] 2022-01 Personal data in the RIPE Database Next Steps

Dear Database Working Group Members,

The four-week discussion phase for the policy proposal "2022-01 Personal data in the RIPE Database" ended on 15 July. In agreement with the proposer, we have decided tomove the proposal into the Review Phase but postponed its start to the end of August. This was done keeping in mind that the upcoming vacation period might prevent participation in the discussion and the timely publication of the RIPE NCC Impact Analysis.

Please note that the RIPE Database WG Co-Chair Denis Walker is the author of this policy proposal, hence he is not taking part in the decisions regarding consensus.

The RIPE NCC Policy Officer will announce the start of the Review phase together with the publication of the policy draft and impact analysis.

For reference, here’s a short summary of the discussion so far:

Ronald Guilmette posted many messages strongly opposing the proposal, advocating instead for the accurate verification of WHOIS data and for not publishing personal data for privacy reasons only in special legitimate cases.
His main points of disagreement were:
a)    The transparency of the database would suffer, affecting LEAs’ and researchers’ work.
b)    The postal address is managed solely by the resource holder and not by the RIPE NCC.
c)    The postal address can already be concealed using, e.g., a PO box.
d)    Only a minority in the community is asking for the postal address not to be published, which doesn’t justify the effort and cost of implementation.
e)    More contact details might fall under the same new proposed rule in the future.
f)    Accepting the proposal would change the historical practice of the RIPE Database.
g)    There is no legal basis for the proposed changes.

The proposer addressed the concerns above as follows:
a)    The transparency achieved is questionable if it's based on unverified data.
b)    End Users are not always aware that their address has been entered in the RIPE Database by the LIR.
c)    Addresses like those of PO boxes do not help LEAs orresearchers.
d)    Implementation could be supported using the existing ARCs.
e)    There is no mention of further changes in the proposal.
f)    Historical practice should not be treated as a requirement.
g)    Legal aspects should be further clarified by the RIPE NCC legal team.

Niels Bakker supported the proposal as it would allow the RIPE NCC to offer a way to prevent LIRs from entering End Users’ personal data in the RIPE Database.

Some ideas for modifying the proposal were posted:
- Ronald Guilmette suggested to address the verification of contact details entered in the RIPE Database with a separate proposal that he would support, provided that the implementation challenges, costs, and consequences for non-compliance would be clarified. This would split the existing proposal in two: VERIFICATION and REDACTION.

- Sylvain Baya, contributed to the discussion and also postedlinks to RIPE Labs articles published in the past about the proposal’s topics. He supported Ronald’s suggestion of allowing the RIPE NCC to accept the requests of exemption from publication of the Personally Identifiable Information (PII) made by natural persons who need Internet resources and can legally demonstrate their privacy requirement. Sylvain also suggested splitting the subject into a set of proposals: one about the general principles for processing data within the RIPE Database, one about *insertion* of PII within the RIPE Database, one about the *query* of the RIPE Database and one for handling the current PII present into the RIPE Database.

- Leo Vegoda suggested clearly separating the sections defining a principle from those defining its implementation.

- Cynthia Revström supported the proposal and suggested rewording the proposal clarifying that entering the full home address is never justified and that the default should be no address at all for individuals. The assumption should be that any address an individual is operating from is a home address unless the individual themselves clearly say that it is not.

Please let me know if you have any questions.

Kind regards,


William

db-wg Co-Chair
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ripe.net/ripe/mail/archives/db-wg/attachments/20220804/63b0b32a/attachment.html>