Thursday, 19 May 14:00-15:30 (UTC+2)
WG co-Chairs: Denis Walker, William Sylvester
Scribe: Boris Duval
Status: Final
William welcomed the attendees to the session. He mentioned that one chair position was open and asked for volunteers to send the chairs an email on the mailing list.
Maria Stafyla, RIPE NCC
Maria Stafyla presented a RIPE NCC legal review of NWI-2 (historical data) and NWI-13 (geofeed data). She began by outlining the main principles of the RIPE Database and emphasized that any data entered into the RIPE Database must meet specific purposes. She added that if these purposes changed and geofeed, for example, was considered a purpose, the community should discuss this.
Denis Walker, Co-Chair, RIPE Database Working Group
Denis Walker gave an update on the status of the current NWIs. He mentioned that while some had been closed or cancelled due to lack of interest, others had been open for years and that the current process was stalled. Denis proposed the creation of a “permanent task force” within the community that would have the time to examine these NWIs and to suggest a plan to move things forward.
Cynthia Revström, representing herself, pointed out that with regard to historical data, privacy must take precedence over public interest, as there were no legitimate reasons to keep certain types of historical data (e.g. text description) in the database. Regarding geofeed, she said that it had a use because it allowed users to link data to a certain block of IP addresses and that geofeed was just a link to an external data source that had to be authoritative in a standardized format.
Maria replied that even if the geofeed information itself was not in the database, it linked to it and that from a legal point of view, there must be clear accountability as to who was responsible for certain data.
Cynthia gave a specific example of how geofeed restrictions could be problematic and offered to continue the discussion after the session.
Peter Hessler, DENIC, said that he had similar concerns about geolocation restrictions and that unfortunately this was something the community had to be authoritative about, as there were several geolocation companies that made up what they wanted. He also mentioned that he felt the restrictions were arbitrary based on the size of the allocation.
Edward Shryane, RIPE NCC, mentioned that this was one of the drawbacks of the current implementation and that the prefix size was difficult to obtain and that it could lead to personal identification.
Erik Bais, A2B Internet, mentioned that historical data was very relevant for brokers to see what happened in the past. He added that his company queries this data while making sure to exclude the personal data. In terms of improving the NWI process, he said that this was necessary and that the community would benefit from a stricter procedure. He also said that NWI-4 is needed, as it annoyed his customers who had a small allocation and wanted to assign a whole prefix and had to split it because they could not put a prefix with the same assignment in the database due to GDPR constraints. He added that, as a broker, he also did leasing, and some of the leases were /22s. If the prefix itself was a /22 or /24, his customers had to resort to cutting it into two pieces and then creating overlapping route objects and RPKI objects, so it was easier for them and technically better if you could just have an assignment in there.
Denis mentioned that the RIPE NCC was currently working on an impact analysis and that the initial intention was to use a quick method to manage a simple technical change. The other objective was to avoid all the formalities, dates and time periods. However, he said that in practice it was probably never that simple.
Nick Hilliard, INEX, mentioned that NWI-4 was not about whether there was going to be breakage but what level of breakage we considered acceptable and who dealt with that breakage. He said that the proposal on the table for using the allocated assignment PA would create an inconsistency in the data model used by the RIPE NCC. He added that this would need to be handled by other software which interfaced with the RIPE NCC, whether it was a broker software, DSIM or IPAM software. Hacks were not going to have to be put into place to deal with this issue because it was essentially a completely new way of referring to a situation where allocation size equaled assignment size.
Denis replied that he did not think it was a new situation because it had always existed, and that we usually lied because we put data in the database that masked the truth.
Nick said that the model that we used at the moment had a certain set of breakage, and the model that had been proposed as the solution outsourced the breakage from the RIPE NCC to the community software. He added that the model that he proposed on the mailing list sourced the breakage to the RIPE NCC and would create a lot of breakage, which is quite a major project.
Denis mentioned that he had already said that the RIPE Database needed a new data model 10 years ago and suggested continuing the discussion offline.
Elvis Daniel Velea, V4Escrow, said that information showing the history of allocations and assignments should be available as it constituted useful information for brokers. Regarding historical information about objects that were not allocated or assignments, Elvis said that this should not be publicly available, but could be made available to the original maintainer only, as it could be useful in some cases.
Niall O’Reilly, RIPE Vice Chair, said that he would follow up on the mailing list as time was running out.
Cynthia proposed to organise ad hoc sessions with the RIPE DB-WG chairs and the relevant RIPE NCC staff in order to have more time to discuss these topics.
Denis agreed with this idea.
Ed Shryane, RIPE NCC
Ed Shryane presented an operational update of the RIPE Database. During his update, he reported that a RIPE Labs paper has been published on UTF-8 and asked the community to give feedback on how UTF-8 should be added to the database. He added that a new service criticality framework had been published and that comments were also needed on this topic. He also mentioned that the RIPE Database Team was considering deprecating Whois Tags.
Kaveh Ranjbar, RIPE NCC, commented that Whois Tags was his idea in 2013 when he was working closely with the database team and that he was in favour of its deprecation.
Harry Cross, representing himself, said that in light of the increasing GDPR requirements, it was important to support Unicode to handle specific scripts, but that expanding the character set could also lead to database pollution. He asked if a balance could be struck.
Ed said that interoperability was also very important to ensure that it continued to be usable. He added that there were technical solutions to support a subset, normalise and exclude certain characters. He commented that all of these elements must be taken into account in the implementation. He also said that the RIPE NCC was already enforcing character subsets in the database in some places; for example, names are ASCII-only, whereas the database supported latin-1.
Cynthia Revström asked a question about cleaning up white pages and whether we should support non-referenced objects that were not cleaned up (e.g. RIPE Atlas anchors). She said that this was a valid use case for contact and that there was no need for a separate system for contact information, which should be supported in this case.
Ed mentioned another case where it was used when referring to a domain name. In this case, a domain registrar referred to a person in the RIPE Database.
Denis Walker, Co-Chair, RIPE Database Working Group
Denis Walker presented his recent policy proposal regarding personal data in the RIPE Database. He argued that most of the time personal data was not needed and that the few cases where it was needed were for natural persons. He also said that contacts should be roles, not persons, and that most contact information should be verifiable. He added that this change would not happen overnight as the database contained 1.9 million contacts.
Peter Hessler said that as far as LEAs are concerned, the best solution would be for them to get a warrant to obtain personal data. He also said that the fact that we have published personal data in the RIPE Database before did not mean that we could not stop publishing it. Regarding replacing people with roles, he said that for small LIRs this was complicated because one person can be the IT department. Regarding verifiable data, he said that this would be a bad idea as some people often entered random information to comply with a requirement (he gave the example of fax numbers), and it could become impossible to create objects if someone did not have a phone number for a specific object, for example.
Cynthia Revström, representing herself, agreed with Peter's comments on validation and said that in some cases it would be unavoidable to have personal data in the RIPE Database, but that this should be recognised and that we should not pretend that it was not there.
Denis agreed and said that this was the reason why he had talked about the need for a change of mindset in his presentation.
Leo Vegoda, Euro-IX/PeeringDB, agreed with what was said about the database being polluted with a lot of irrelevant personal data and added that it would take a huge effort to clean it up. He also said that the community should consider a new contact model, as phone numbers and postal addresses might not always be there.
Elvis Daniel Velea said that much of the data in the RIPE Database was out of date and had not been used for years and that it would be good to look at ways of cleaning it up. He mentioned that perhaps the RIPE NCC could do this during the ARCs.
Denis replied that one could not be sure that it had not been used. He added that it could in fact still be used and be perfectly valid. He agreed with Leo that this would be a huge undertaking and that we should think about how to do it first.
Matthias Merkel, Staclar, said that deleting full addresses for individuals made sense from a privacy perspective. However, he added that there were many people with the same name and that having at least something like a city could help identify who was really in charge of the object. He added that the RIPE NCC had removed the address line for some organisations owned by individuals, which might be a good compromise.
Cynthia Revström shared that the goal was to not be able to pinpoint a person with contact information. Peter agreed and added that he kept his address private for security reasons but had no problem sharing it with the RIPE NCC or sharing city or regional information.
Denis replied that this could be problematic as some people lived in small towns and it could still be used to identify the person.
Florian Streibelt, MPI, said that with regard to the comment about obtaining a warrant for LEAs, it would be better to keep the possibility of publishing the public contact data, as he would rather receive a call from the police than have them come with a warrant and take all the devices away, as it was done in Germany when they obtained a warrant for IT offences.
William closed the queue as time was running out, and Denis invited the community to continue the discussion on the mailing list.
There was no further discussion, as time had run out.