You're viewing an archived page. It is no longer being updated.
Session: Thursday, 23 May, 14:00 – 15:30
Chairs: Denis Walker, William Sylvester
Scribe: Anand Buddhdev
Status: Draft
The Chairs welcomed attendees to the session.
The presentation is available at:
https://ripe78.ripe.net/presentations/136-RIPE78-DB-WG.pdf
Sandra asked the audience to participate in a survey that helps the RIPE NCC understand how to help users understand the RIPE Database.
The presentation is available at:
https://ripe78.ripe.net/presentations/129-RIPE78-Operational-Update.pdf
Cynthia Maja Revstrom (remote) asked whether there was an ETA for NWI 8 and if there was an update on open access to NRTM.
Ed replied that there was no ETA on NWI 8 yet, but there could be a working version of it fairly soon, given that the implementation plan was simpler.
About NWI-9, Ed said that it was better to redesign and re-implement the protocol in a standards-compliant way, instead of just opening up NRTM.
Cynthia commented that it was not a good idea to change the protocol because NRTM software is out there.
Marcus Jackson asked about which bug fixes RIPE NCC hoped to implement if they were not blocked by feature releases. Ed said that the release cycle for RIPE Database software updates is two weeks, and there is a release candidate environment for testing. However, his team would only do this if there was agreement from the community.
Job Snijders (NTT) commented that previously NRTM used to be open, and this would help folks with routing information. He asked the working group chairs about a process to open a slimmed-down version of NRTM.
William replied that Job could open an NWI on the list and start a discussion.
Daniel Karrenberg (RIPE NCC) invited Job to gather some people who are using the full NRTM feed and tell the NCC whether they would benefit from a slimmed-down version.
Aris Lambrianidis (AMS-IX) said that as the person behind NWI-9, he would also prefer a slimmer NRTM.
Job then said he would love to work with RIPE NCC in redefining a new protocol to help the community with its various use cases.
Denis Walker (WG co-chair) commented that perhaps the option to return personal data could be reversed, so that no personal data is returned by default.
The presentation is available at:
https://ripe78.ripe.net/presentations/10-10-PersonalData2.pdf
Daniel Karrenberg said that the first verison of the RIPE DB was based on a personal contact manager. The principal data model has not changed since then. He said it was a good idea to have some people write down the purpose of the RIPE DB, and then develop requirements from that. The purpose should be small, not more than four A4 pages. This is within the scope of this WG. He said that if this work is undertaken, to please reach out to the operators and Law Enforcement authorities. This work is for more than this WG. Other WGs need to be involved. In response to Denis's question about when to start this work,
Daniel said that this work can start now.
Nurani Nimpuno (Asteroid) said that she has worked with the RIPE Database for 20 years. She has developed training materials and explained to many people how to use the database. She agreed with Daniel that we need a purpose document and seek input from a broader group of people who use this database. She also said that there is no need to wait to start this work.
Cynthia Maya Revstrom, a remote participant said that sometimes person objects get left behind. She asked if there was a process to request deletion of a personal object. Denis replied that this is possible via a process, and one may contact the RIPE NCC for this.
Athina Fragkouli (RIPE NCC) said that in context of GDPR, a purpose for the RIPE Database was written down by the Data protection task force and was used to evaluate the database. In that context personal details were needed, but RIPE NCC will be happy to re-evaluate in context of a new purpose document.
Elvis Velea from Escrow (remote) said that RIPE NCC was creating new admin and tech contacts in the RIPE Database for each new LIR, and this often creates many duplicate contacts. He suggested that existing contacts should be re-used, and asked of there was any plan to do so.
Felipe Silveira Victolla, RIPE NCC, said the RIPE NCC prefers role objects, and is reviewing procedures to make greater use of role objects instead of personal objects.
Peter Koch said that he was involved in the data protection task force back in the day. He explained that there is a distinction between purpose and usage of the RIPE Database. Defining the purpose of the RIPE Database will also touch on the purpose of the RIPE NCC more broadly. He said that one should not quickly jump into the task of defining the purpose of the RIPE Database, because it's not really a lightweight task.
Daniel Karrenberg clarified that purpose should be defined more narrowly, in the context of personal data.
Elvis Velea (remote) said that a task force is needed, but noted that asking WGs hasn't worked in the past.
Nick (remote) asked if there was way to become a RIPE member without data getting into the database Daniel Karrenberg said it's possible, but only if that member doesn't want resources.
The presentation is available at:
https://ripe78.ripe.net/presentations/130-Cleaning-Up-Locked-Persons.pdf
Daniel Karrenberg asked whether when doing bulk updates, someone could become the maintainer of an object without agreeing to it. Ed replied that this would never happen. He said that this work would happen in co-operation with LIRs and the RIPE Database WG. Only old locked objects would be removed, and it's a chance to clean up very old data from around before 2010.
Elvis Velea (remote) said that deleting these objects is the right thing to do. Changing to a dummy object is also good.
Nick Hilliard (INEX) asked how many locked objects were being unlocked by users. Ed replied that about 10,000 locked objects are being cleaned up, but it's a slow process. Nick then asked about the issue with duplicate person objects, and whether they were referencing different maintainer objects. Ed said that there is a lot of duplication, but it was just about locked objects. He said that before cleaning up, the RIPE NCC would check whether it was identifying the same person.
The presentation is available at:
https://ripe78.ripe.net/presentations/134-CC-Proposal.pdf
Shane Kerr wrote some text long ago to say that the country codes are useless, and should not be relied upon. He suggested that we don't call it "country" in the organisation object, to avoid overloading the definition of "country" in different objects, and also make it optional in objects that don't need it. He also suggested coming up with a new name to avoid confusion with the existing "country" attribute.
The presentation is available at:
https://ripe78.ripe.net/presentations/137-db_wg_ripe78_prop2018-06_snijders.pdf
Rüdiger Volk asked whether entities been notified about the existing conflicts.
Job said that there had been some activity.
Rüdiger said he prefers that all parties are notified first.
Job said he was open to proposal changes.
Denis Walker (co-chair) also said seven days was too short.
Job replied that they could change the notification period.
Erik Bais suggested a one-time effort and then to use seven-day hold downs.
Denis Walker said that people tend to forget things when notifications go out, and then some event happens much later. He said it was better to give notifications and allow people time to respond to them.
Job said that there would be two different events: first, when an invalid ROA is created, and then seven days (or some other period) later, when the policy is implemented. He said it would affect around 700 of the current 69,000 objects.
Sandra Murphy, a remote participant, asked whether RFC 7909 had got any traction in RIPE?
Job said it hadn't.
Jan Dickinson,a remote participant, asked whether there would be a second check of the ROA before deletion?
Job said yes, a ROA must exist for seven consecutive days. If it doesn't, the hold-down is cancelled.
There were no comments.
Nick Hilliard said that transfers will invalidate objects, and should be deleted.
William Sylvester added that he had proposed something like this about two years ago.
Job asked Nick to clarify whether he meant the RIPE-IRR or RIPE-NONAUTH. Nick said he meant RIPE NONAUTH.
The Chairs thanked the attendees and closed the session.