On Sun, Oct 09, 2022 at 01:33:43PM +0200, Sander Steffann via db-wg wrote:
The RIPE NCC has prepared an impact analysis on this latest proposal version to support the community’s discussion.
You can find the proposal and impact analysis at: https://www.ripe.net/participate/policies/proposals/2022-01 https://www.ripe.net/participate/policies/proposals/2022-01#impact-analysis
The executive board feedback corresponds to my opinion on this policy, especially these points: - It significantly reduces the usability for one of its core purpose - being able to contact resource holders about their number resources.
This presumes a "traditional" model of resource assignment and allocation that is no longer ubiquitous. For virtually all LIRs I have a hand in managing resources for, the end users have neither the inclination nor the ability to manage the /29 they are assigned - they expect their provider to do this. Should an end-user wish to manage their assignment themselves, or the LIR to devolve this responsibility, they can still create an inet(6)num for the assignment. In the NCC's Impact Analysis, it states as the legal reasoning for GDPR purposes "the legitimate interest of the RIPE community". I consider this reasoning naive. The "RIPE community is an unconstituted and ephemeral collection of individuals and can't be a legal subject. Whom do I take to court if I want to test my privacy rights against the "interest of the RIPE community"? Every member of the mailing lists individually?
- We would welcome a discussion that focuses more on which parts of the data are publicly available, rather than a sweeping removal.
Any data that should not be publically available should also not be in this database. A reasoned argument may be made to have this data in a *separate*, non-public database. That said, I still oppose this proposal based on other grounds, such as the attempt to introduce yet another "verification" requirement and the resulting overhead to both the NCC and the membership. rgds, Sascha Luck