Hi Piotr Have you forgotten about the almost million personal data sets that the RIPE NCC locked and then asked the community to decide what to do next? I wrote a detailed argument on why I believe this is a serious legal issue some time ago, which not even the RIPE NCC answered: https://www.ripe.net/ripe/mail/archives/db-wg/2016-September/005318.html Bottom line, the RIPE NCC is both responsible for and liable for publishing in a public database the personal details of almost a million people who they have no relationship with, no knowledge of and no contact with. That breaks data protection laws. They cannot hide behind being the 'data controller' or the arguments made by the RIPE Data Protection Task Force many years ago that this responsibility was delegated to the LIRs. If the RIPE NCC's MNTNER object protects these PERSON objects, the RIPE NCC is responsible and liable for this data. The objects should be reverted back to unmaintained and the operational data that references them should be locked. That will force members to sort the problem out themselves, after ignoring it for many years. cheers denis On 19/10/2016 15:52, Piotr Strzyzewski wrote:

Dear DB-WG Members

This is the 1st draft of the agenda for the DB-WG Meeting at RIPE73 at the Meliá Castilla hotel in Madrid, Spain.

The DB-WG Meeting is scheduled as usual for Thursday, Oct 27th, starting at 15:00 local time, after the lunch break. The length of our timeslot is 90 minutes.

ATTENTION: This time the meeting start and end times have been adjusted by one hour to complement the local Spanish working hours and customs.

For the overall RIPE 73 meeting plan please refer to its most up-to-date version at https://ripe73.ripe.net/programme/meeting-plan/

Please feel free to comment agenda items or propose additional topics to be discussed both on the mailing list or direct to the WG Chairs at db-wg-chairs@ripe.net

Looking forward to see you all in Madrid.

All the best, Job, Nigel & Piotr ________________________________________________________________________

A. Administrative Matters [~10 min] . Welcome . select scribe (thanks to Nigel for volunteering again!) . finalise agenda . approval of minutes from previous WG meeting(s)

B. Review of Numbered Work Items (Job Snijders) [~10 min]

C. NWI model - where are we? (Job Snijders) [~10 min]

D. DB Operational Update New and revised DB-Software functionality (proposed, test, deployment) Recent DB issues (Tim Bruijnzeels, RIPE NCC) [~15 min]

E. Afrinic IRR homing project update (Piotr Strzyżewski) [~10 min]

F. Recent work on the UI improvements (Alex Band, RIPE NCC) [~20 min]

G. DB-WG - What next? (discussion) [~15 min]

Y. Input from other Working Groups and/or Task Forces

Z. AOB

Dear RIPE DB WG,

E. Afrinic IRR homing project update (Piotr Strzyżewski) [~10 min]

Glad to see this is on the agenda. Myself and AFRINIC are eager to see this move forward. As far as I recall, the problem statement was roughly agreed on and we all (RIPE DB WG and AFRINIC) feel that ultimately having AFRINIC resources in the AFRINIC IRR is more manageable for all the members in both regions as well as both sets of RIR staff. Please correct me if I am wrong. I believe it’s also clear to everyone that when one or the other of the prefix or ASN is in a different region to the other, resolving where the ROUTE(6) object should live and how authorisation is done between two RIRs is complex and needs some further discussion. I believe it’s states as out of scope of NWI 3 anyway. This should not preclude or block the homing of the majority of ROUTE(6) objects currently in RIPE DB related to AFRINIC resources, where both the prefix and ASN are AFRINIC assigned or allocated. From the AFRINIC organisation point of view, at this stage there is no consideration to change route(6) objects in terms of aggregation or de-aggregation. Nor would we want to see any objects deleted from the RIPE DB that are not already duplicated in the AFRINIC IRR first. A goal here is to serve our members by having their valid route(6) objects managed from the same interfaces and tool as their actual resources, their sub-allocation, their reverse DNS delegations, RPKI ROAs, and so on. And under the same authorisation. As such, AFRINIC does already actively encourage members to migrate their route objects across. We even have some tooling and running code to assist members to do so. But uptake is slow. I believe due to primarily two factors: - General inertia: “If it’s working now, why change anything”. - Upstream carriers that still require RIPE DB IRR objects from downstream operators in the AFRINIC region. I believe (hope) that these two factors are where the RIPE NCC and the RIPE DB community can assist. Of course at the same time the message from AFRINIC *is* one of equal desire to have the objects more and support for the DB WG’s desire to not have out of region objects. No one wants this to be seen as the RIPE DB dictating the way forward, but a certain degree of firmness from both ends would, I believe, help as an incentive to the resource holders to take action for themselves. And AFRINIC is then ready to assist them in creating/copying the objects. To summarise: This is mostly to re-iterate that finding a way to complete this work is understood to be mutually beneficial to both RIPE and AFRINIC communities, membership and organisations in the long run. Without a doubt there will be some challenges with the technicalities of certain sub-groups of objects that are out of date or not perfectly duplicated, but we understand this is unavoidable and are ready to put in the effort to deal with them as the data are looked at more closely. I have a high level of confidence that these will not form the majority of objects to move anyway. Best regards, Daniel