RIPE 83
.
Database Working Group
.
Wednesday, 24 November 2021
.
13:00 (UTC + 1)
WILLIAM SYLVESTER: Welcome, everyone, to the Database Working Group here at RIPE 83. We see a lot of welcome faces out there. Thanks to everyone for attending. We have a busy agenda today, just a couple of tidbits. The session is recorded, please post your affiliations when you are asking questions in the chat, and I look forward to having a great session today. So, with that, Ed, if you'd like to kick us off with your operational and Cloud migration update.
ED SHRYANE: Hello, everyone. I am Ed Shryane, and I am a senior technical analyst at the RIPE NCC.
And here is the database team, and my thanks to them for their hard work over the last six months that's reflected in this update.
So, what have we been doing since RIPE 82:
.
First of all, there has been one Whois release, that was in July, mostly operational changes, all time stamps have now been normalised, they are all in UTC, including the Z time zone. We simplified the HTTP reader in rewrite rules and we removed deprecated TNS versions and insecure cipher algorithms. We had checked beforehand that this would affect less than 2% of traffic, and thankfully we have had no reports of disruption.
There have been three Whois outages since May. Firstly, there was an update outage in September of one hour, there was a network issue which caused trust anchors to get stuck, and it didn't time‑out, which blocked everything else. We did take some time to try and find the root cause. In the end we had to restart the master database to clear the trust anchors. And since then, we have shortened trust anchors idle time‑out to five minutes to mitigate this if if it happens again.
Secondly, there was an e‑mail notification outage on the 9th and 14th July. It was due to a network issue and it caused intermittent issues to send notification e‑mails from Whois updates.
Finally, on Monday, on the 25th June, there was an issue updating the daily database dump and split times and we uploaded those manually to resolve the issue.
Some Whois features ‑‑ statistics on recently introduced features.
We have the regular abuse‑c validation. We have now over 100,000 abuse‑c addresses in the database. We found that 3,000 of those were invalid, and we're on track to finish validating all of those addresses for the year.
Secondly, the RPKI NON‑AUTH Route‑6 clean‑up, we have now deleted nearly 1,500 route objects this year. The unregistered prefix NON‑AUTH route in 6 clean‑up, we have deleted nearly 1,000 in Route‑6 objects. The NWI‑8 work item to synchronise portal users to the fault maintainer in the RIPE Database, there is over 1,000 LIRs using that feature. Finally, the Open NRTM, I found there was nearly 200 distinct client IPs using the service.
Three data clean‑ups. The unregistered prefix job as mentioned only available on reserved prefixes in the delegated stats are considered unregistered and, thus, eligible for clean‑up, and we deployed that at the end of June.
Secondly, we corrected address attributes on just over 1,000 LIR organisations. The address order was reversed when synchronising from the internal registry. And that's now been resolved.
And finally, Remco van Mook, at the last RIPE meeting, pointed out that some status attribute values are not upper‑cased. The Whois has been upper‑casing since 2014, but the clean‑up was not done and any existing data so we have now done that and all status values are now upper case.
Person Objects. There is a lot of personal data in the database. Just nearly 1.9 million Person Objects, 1.7 million of those are from assignments. The top 10 LIRs are responsible for 1 million of those references, referencing Person Objects. We unlocked almost 600,000 Person Objects in June 2020, since then 28,000 unlocked persons have been deleted, 1,600 updated, we also e‑mailed to the top ten LIRs in May and with a reminder in June, six LIRs have replied, and they confirmed that their end users are informed that their contact details will be added to the RIPE Database and they also confirmed that they do keep the registration up to date.
Upcoming changes in the RIPE Database.
.
There is a Whois release in the release candidate environment right now and it is due for production on Tuesday, the 7th December. The main change is to add numbered work item number 13, the geofeed attribute to inetnum 6 num objects. We now support base 64 encoded signed updates which are generated by Thunderbird, and finally, we are supporting internationalised domain names in outgoing update notifications.
.
Upcoming changes:
We are making improvements to the query page and my colleague will explain in more detail what those changes entail. But also, to point out that we are planning a public full text search API separate from the RIPE web application.
We have enabled client certificate authentication in the release candidate environment for testing. This uses TLS, the client certificate, but to use the same certificate to authenticate Whois updates. And the benefit is that there is no shared secret between the client and who is but the downside is, it is more complex so it will be interesting to see what the uptake of that is.
Finally, the default maintainer, we need to make some improvements. Currently, it's only set on top level allocations for an organisation, and secondly, internal users must make any changes manually, so it's error‑prone, so we plan to focus on improving that in the coming months.
.
The Cloud migration:
So just to confirm, the Cloud migration of the RIPE Database is on hold since the RIPE 82 meeting. Let's start again. There was a series of presentations, a RIPE Labs articles by Felipe. We're stepping back from discussing the technical specifics on our earlier proposal and we starting engagement with the RIPE community to define requirements for the usage of Cloud.
And most recent use of Labs article on service criticality and we plan on working with the community on defining the service criticality for the RIPE Database.
That said, there are some useful outcomes from the Cloud work that we have applied in the internal environment. We have improved collaboration with our other teams within the RIPE NCC, operations and RPKI. We are more aware of how to improve resiliency and that applies internally as well. And there are a bunch of technical improvements that we have been using, not only switching to UTC, but using containers more and simplifying our production environment.
Quarterly planning:
We are working with our coms team on publishing a status update every quarter and that goes on our website so users can keep track of changes and things we're working on and give their feedback.
So, mostly this is a number of work items. I'll just go through those quickly. These are the open issues that are in progress with the database team. Numbered work item number 2, displaying history for the database objects where available, and there was a recommendation made by the Working Group co‑chairs after the last RIPE meeting, Legal have ‑‑ are analysing that, but they do have some concerns regarding GDPR with the request and a more detailed response will be published to the Working Group list shortly.
NWI‑4, role of the status field in multivalued status context. There was a suggestion from Carsten to use the couple prefix and status the primary key instead. We spent some time trying to implement this, but we have concluded that it's a very difficult change to implement because we'd have to rewrite a lot of the query and update code and we plan to e‑mail the Working Group with a more complete explanation of why that is.
Definition of country, NWI‑10 ‑‑ database, the data entry of end‑user organisation legal address is in progress, and we expect to complete that by the end of 2021. And once we have verified that data, we will populate the RIPE Database with the country code for end‑user organisations and also update the resource prefixes in the delegated stats.
NRTM version 4, we had a BoF in September to discuss the proposed draft for the NRTM version 4, and I propose a nominating list as a solution definition for NWI‑12, so we welcome any feedback. And if this proposal has consensus of the Working Group, we are ready to start implementation early next year, once the draft is complete.
Geofeed, implementation is now complete for geofeed, and it will be in the next Whois release.
And finally, UTF‑8 in the RIPE Database, the technical investigation is complete for this. It is feasible, but it's more the impact on the RIPE NCC that we're still investigating that, and you can expects a RIPE Labs article soon.
Okay. That's the end of my presentation. Any questions? Okay, I don't see any questions. If there are no questions at this time, I am happy to reply to any e‑mails to the Working Group.
WILLIAM SYLVESTER: Thank you so much, Ed.
ED SHRYANE: Thank you.
WILLIAM SYLVESTER: Up next we have the user interface update from Rehan from the RIPE NCC.
REHAN SYED: Hello, everyone. My name is Rehan, I am a QX specialist in the RIPE NCC and today I am going to talk about the improvements that we are doing, working on in the RIPE Database.
But first, I would like to show you how it used to be in the RIPE Database UI and how it evolved in the past years. In 2014, we had the early interface that was primarily working on MD5 authentication, and, in 2015, we made the transition to the new LIR, but also introduced an SSO authentication. And since then, we wanted to understand how our users are using this interface and we wanted to understand the usability aspects of it as well.
So, for this, we did usability research over the years, we did interviews with all of you guys, and thank you for your feedback that you gave us. With the help of the training team, we managed to get the user feedback on the site until we started to work from home, and with that, in 2020, we started conducting interviews online, with our users from the RIPE Database and also other users who were participating from our platforms so we can get a really good sense of how each product is doing and how we can enable the functionality between them.
For this reason, we also looked at the analytics to drive better opinion, and we were able to work on the future changes, which I would like to show you.
.
First, from June 2019 to May 2020, we received around 2.4 million visits on the RIPE Database UI, and in this year, from June 2020 to May 2021, we received around 2.5 million visits per year on the RIPE Database UI. That is quite a huge traffic, but also we see here an increase in the RIPE Database UI adoption from our new users, and we see also that the 88% visits were from the desktop but also 12% were from mobile or tablet devices. We see that in the past year, I remember around 2015, when we looked at this data, it was around 3 to 4%, which is now up to 12%, and we see that increasing every year‑on‑year, this number.
With the ‑‑ jointly with all the teams in the RIPE NCC, we wanted to create a better user experience for our users and, for this, we unified layout of the RIPE NCC Services, and also, provide a better tablet or mobile experience, a responsive design and also have more space for the application, plus easier navigation, and we launched these layout changes in 2020, but, since then, we did not change the application itself. The application of the RIPE Database UI remains the same, and since then, today, with the changes which I like to show you, it's a series of the biggest changes since 2015.
So, when we took all the research, we gathered our data and, based on that, also the feedback that you guys provided, we identified four areas of improvement.
The first area is about the organisation search. Now, the primary objective of the RIPE Database UI is basically to get to the search, a quick search as possible, as fast as possible, and we see that 67% of the lookups that performed in the page are for the organisation objects and we wanted to make it easier for the user and intuitive.
And for that reason, when the user uses a search for the object ‑‑ sorry, resources in the query page, then we will show the relative objects types in the drop‑down. And for that, the user can go to these organisation objects or the abuse‑c, text‑c, admin‑c as quickly as possible from the beginning.
The second area of improvement is about the filtering. We know that it happens a lot of time that our users, when they search for the query and uploads some filters, it can happen that there are no results because there are a lot of filters and if the user doesn't have a good understanding of them, it can go, appearing as no results very quickly. So for that reason, we are introducing contextual filtering. With that, when the user goes on a search for the resource, they will be prompted with the filters which are only applicable for that resource.
The third one is about the flags. Now, the flags are for the power users and to get the optimal results. And what we would like to do is to provide the upfront information for the users, what kind of flags they are using and so then the user can take an informed decision before clicking on "search".
The fourth one is about the full next search. We see around 16% of our users going back and forth between the query page and the full text search and we see that a lot because when the query page does not conclude to any result that the user would like, then the user goes to the full text search, and we'd like to bring that, all the query page itself. And for that, the user can enable or disable by choice. It will be in the advanced filters, enable full text search, and then the functionality will remain what the user has already been familiar with.
Of course, to get to this point, we will take a of iterative steps, but also we have a design milestone that we see where this UI can go in the future and these are some screenshots that we think that might be useful for our community to see how this UI will enable in future. Of course, we need your support, we need your feedback to get there.
Also, if you have seen at RIPEstat and was introduced last year in RIPE 82, and also RIPE Labs, they follow the same suit, that basically change into this kind of UI and they like to spend more time and energy towards other applications to have this support.
Moving ahead, of course, we will do very incrementally, we will involve the community as soon as possible on the RC environment, on the dev. environments and we will take that very seriously when it comes to design decisions, by testing and getting your feedback is very crucial for any design changes. So, if you have seen in the past months that we are changing and iterating the design little by little, but also collecting feedback from our user groups as well.
For this reason, I would really love to have your feedback also, and please register on the form, if you visit ripe.net/s/usability, then you can participate in one of our testing interviews whenever we launch anything there and then you will be notified with that, you can give us your valuable feedback and we make sure that we implement those features ‑‑ yeah ‑‑ and it will be very helpful for us.
With that in mind, thank you very much for the presentation today, and I invite any questions if you have any. Thank you.
WILLIAM SYLVESTER: We have a couple of questions in the Q&A area. The first one is from Christian Bretterhofer, who is representing himself: "Can we get more ‑‑ he has got a URL in here that's basically the Web UI, My Resources of Review: All objects maintained by, for example."
Basically, he is asking, in the overview page, in the authenticated part of the website, can we get all the objects from the "maintained by"?
REHAN SYED: We are looking into this as well and we are collecting feedback in this regard. If you are interested to talk about it and how it will be useful for you, please, if you can sign up for the form or contact me or Ed and then we will take a look into it. We did receive feedback about this recently, so, we can think about how we can expand the "my resource" page into other objects, starting with maintainer, yeah.
WILLIAM SYLVESTER: Great. Next question was from Wessel at Prefix Broker:
"RIPE Database query... the hierarchy flag selection for those of us who have not memorised the meanings behind ILMX, this is an improvement. Can you look into the a way to clarify what each flag stands for without having to move the CIDR to see the description?"
REHAN SYED: Yeah, absolutely. So by showing these UI, if you see that these in grey scale, and actually, it's the way to get your feedback and opinions on that. And we are getting feedback from our users, so if there is a way to improve it and if you think, please suggest to us. Otherwise we are looking into different ways. If it is not moving sliders, it's going to change the description. If that is not enough, then we can always go back and have the check box as we have right now. But we are also constantly looking at ways to improve it.
WILLIAM SYLVESTER: Great. Next question is from Raymond Jetten:
"Would full text search be available for only the LIRs own objects?"
REHAN SYED: I think full text search is available for any kind of object types and the ‑‑ that doesn't necessarily is the own LIR's object. Ed, do you want to say something about it?
ED SHRYANE: Sure. It's something we haven't considered, but it's certainly technically possible. We could add a term to the search to restrict the search to the objects and maintained by the organisation's maintainer in the same way that we show the objects on the "my resources" page. We could ‑‑ I think it's feasible. So, yeah, if we can find a way to do that in the interface as well, I think we could implement that.
WILLIAM SYLVESTER: Great. One more from Raymond Jetten on:
"I would need that option to reduce the amount of answers."
REHAN SYED: Sure, we can work on it. No problem.
WILLIAM SYLVESTER: And Rudiger Volk: "Is it clear how to identify an LIR's objects?"
REHAN SYED: Yeah, I think we can identify an LIR's objects. We have the SSO account information and, by coupling with the maintainer, we can find out your LIR's objects in the RIPE Database, of course.
WILLIAM SYLVESTER: Great. Any other questions. Thank you, Rehan.
REHAN SYED: Thank you very much. And if you have any other question, please reach out to me or in the mailing list, I will be happy to answer. Thank you.
WILLIAM SYLVESTER: Great. Thank you. Up next is the Database Requirements Task Force update from Shane Kerr.
SHANE KERR: Hello, everyone. Let me see if I can figure out how to present these slides. I don't, I can't. Sorry, everyone. Do I have to share the screen? There we go. Thank you. I apologise to everyone.
So, I was I was going to start off by saying how nervous I was. I think this was even better. I demonstrated it. So welcome, my name is Shane Kerr, I am one of the members of the Ripe Database Requirements Task Force, and we recently finished up our ‑‑ the document that we were organised in order to create, and this is part of our efforts to present the findings of this and circulate them in the RIPE community.
So, you can see the task force members here, and you also see that we also have people on the RIPE NCC who gave us an enormous amount of help in this effort, it was really a lot of work from everyone involved, and we appreciate the ongoing support from the RIPE NCC.
What is the task force? We were created in 2019, and this was sort of a bit of navel‑gazing on behalf of the RIPE NCC, and one of the outcomes of that was, the observation was that we have this database which is very important for everybody, but we're not exactly ‑‑ which is a historical thing that came about and we never really wrote down what this was for, how it works or anything. So that's kind of the idea of the task force, which is to document the requirements.
And as I mentioned, we just finished up the work, publishing the final report.
So, I am not going to go through all of these things. This is an effort to describe how we work. I think we tried to be transparent and get continuous feedback from the community and everyone that we think of might have interesting things to about the RIPE Database requirements. So it hasn't been a group of people in a smoke‑filled room chuckling to ourselves and lighting our cigars with €100 bills; we have really tried to be involved and open and make sure that everyone was involved.
So, having said that, of course it wasn't always easy. Certainly, Covid interrupted our work, like it did many people's, and of course the document itself was ‑‑ the RIPE Database does a lot of things and has a long history and there is a lot of people that are interested in it, so it was kind of a big thing to chew off, or to take on.
Also, the RIPE community isn't always of one mind as to what it wants to do, especially around the database. And there is a lot of technical details. With any requirements document, there is always an effort to figure out what the appropriate level of detail is for it. So, we tried to steer away from specific details like individual flags in the implementation, or attribute names on the objects and things like that. We tried to give a little bit of a higher focus for that. We thought that was appropriate, and yeah, we felt happy doing that.
.
So what went well? We actually did have a fairly diverse group of people on the task force. We all worked well together and we were able to get feedback from the community when we tried to elicit people's opinions and things like that. So that was pretty good. As I mentioned before, we had a lot of really great help from the RIPE NCC.
So, if ‑‑ so this document is now RIPE 767, it's a RIPE document, you can download it there, but if you just Google "RIPE Database requirements", it will be near the top of your search. And we start off early in the document by talking about data management principles, we describe, in what we hope is sufficient detail, what we mean by each of these principles: accuracy, consistency, minimisation and security. And from those, we lay out what we think the purposes of the RIPE Database are, and these are listed here. Certainly, a primary, if not the primary, purpose is to provide registration information about number resource, it also contains reverse DNS information which are linked to those resources, routing information which is also linked to those resources, and having all that information ‑‑ once all that information is available, the way it's used is to facilitate Internet operation and coordination and so on.
We also added a purpose of enabling research. This is important. This feedback came back from various people in the community. So, there is that.
And how do we ‑‑ so those are kind of the ‑‑ like, what it's here for, and then we are moving on to the specific requirements, and so, based on some feedback that we got, we decided to make a kind of template for it, so each requirement has a rationale which is sort of explaining why it's a requirement and the scope that we thought was appropriate for each requirement, recommendation, and so on, and what purpose ‑‑ like, why is it a requirement? What is it really to do?
.
We also had a lot of things that kind of came up which we thought, this isn't actually a requirement, but it's too important and people are going to wonder if it's missing, so we decided to include sort of almost flavour text, just describing other things.
And the recommendation that we listed there, these are all only suggestions, we're just a task force, we don't have any ‑‑ we don't have any authority or any power to make anything happen, so we were conscious throughout the whole process that anything that we came up with as a recommendation, would just be that, and that the further work would have to be done in the various Working Groups or other ways in the RIPE community, and I'll talk about that more in a couple of slides.
Well, I'll talk about it in this slide.
.
So, you can see here we kind of went through the requirements and thought who is the one that actually would be the one that would be implementing, or not, each of the recommendations that we made, and so you can see them listed here on this slide. And a lot, although not all, of these, are for the Database Working Group. So, for example, the very first requirement lists what actually is important to include for a number resources, and so the kind of implications is that there is things which aren't important and maybe they should be handled in a different way and make sure that the things that are important are listed and handled properly. And some of these requirements are probably going to be controversial. For example, this third requirement, 6.1.3: "Discourage using the RIPE database as an IPAM solution." One of the things that we found surprising and/or feedback from the community, was how many people use the RIPE Database for address management, that's what IPAM means if you don't know. And so we had many discussions about this, and ultimately we thought it's not actually something that the RIPE Database is built for, and if you have very, very light requirements for IPAM, then maybe it is okay for you, but it's not really what it's for. We weren't ‑‑ we were unable to find out if this was based on misunderstanding of the question or things like that. We think there is probably good ways to go forward with that. For example, maybe making it so that there is hooks, so that external IPAM solutions can hook into it. If the RIPE NCC wants to provide that and hook into the database like that, that makes sense, but there is certainly commercial vendors that provide IPAM products that would be happy to use hooks. Full disclosure, my own company sells an IPAM solution, so there is many ways that third parties could use this, but probably not a requirement. But as I said, like, all of these recommendations are that, only that, recommendation.
Let's see, another one for the database is access to historical data. This one is tricky because when people were interacting with the database in the past, the purpose and requirements and how the data was going to be used going forward might not have always been clear. So, taking data that people put in earlier and using it later, for example, data that they have deleted, because they didn't want people to see it, having access to that data in an historical context, might or might not be okay.
We recommended that this be done on a case‑by‑case basis, so, for example, if a researcher wants access to historical data, or an organisation needs access to historical data to check for previous use of a block, that would be considered on a case‑by‑case basis. Now, again, that's a recommendation to the Database Working Group. If the Database Working Group wants to handle it it in a different way, if you think, no, the community really feels it important that everybody ever written into the database ever should be publicly available to anyone, then that's the decision and that's the way the Working Group can go.
I am not going to talk to the recommendations for routing, except for the one that's also to the Database Working Group, and that recommendation is that the RPKI effort involves routing information but doesn't actually sit in the RIPE Database. We actually don't think that necessarily needs to change. However, we recommend that the RPKI database be changed from a RIPE NCC service where the policies are dictated solely by the RIPE NCC and its members, to one that's community‑based, like the RIPE Database. That may not be the way that the routing or the database community want to go, and the RIPE NCC may not be willing to change the way it works there, but that's our recommendation there.
And let's see, the final two recommendations that are for the Database Working Group is: One is to change the way that Person Objects are used. We think that Person Objects should be de‑preferenced, I guess you could say. We think that people should ‑‑ an organisation should use Role Objects preferentially and not provide private information in the database when they can avoid it. We didn't actually go as far as to recommend that Person Objects be completely removed from the database, in case there are situations where people find it important to list contact details or other information about persons. And we also recognise the fact that it's very difficult to restrict what people will put into Role Objects, so if people want to put their own phone number in there, there is not really a very easy way to restrict that. But we hope that by declaring it a Role Object and explaining what the purpose is, that it will encourage people to not use personal identifiable information or other privacy‑sensitive stuff in the database.
And finally, another possibly contentious decision is about legal address of resource holders. This is something that various law enforcement agencies have wanted for a while, and the idea is to make it easy to contact people who have number resources. The community has, in the past, basically rejected that, and we kind of stand by that decision and don't think that it's a good idea to do it. But, as always, as with any of these recommendations, if the RIPE community feels strongly that this is not the way to go forward, then that can be changed.
So, that was a long list, and I can go back to it during the discussion, the Q&A phase, whatever, and I'm happy to talk through any points, and hopefully some of my other task force members are with me here and can also help answer things, if necessary.
But what's up next? Basically, the RIPE Chair team, so that's Mirjam and Niall, will coordinate with the relevant Working Groups, and the Working Groups are going to be asked to discuss the recommendations on their mailing lists or in person if they want, or however they want to organise that, and the RIPE NCC will implement them.
Basically, this slide is to say that all of the normal existing RIPE procedures and policies for making changes to the way things work are what we expect going forward here.
So all of the recommendations are intended to be channelled through existing policy development process or whatever, whatever approach makes the most sense for them.
And that is it. So ‑‑
WILLIAM SYLVESTER: We have a question. The question is from Elvis Velea:
"RIPE Database was used as an IPAM solution because the RIPE NCC requested registration of assignments in RIPE Database to show previous usage and prove future need in order to allocate more space. Unless address policy decides the assignments are not a requirement when address space is used and a mere recommendation, members would consistently violate the policy by not registering assignments." So basically, point 3 is linked to point 2, right?
SHANE KERR: So, I'm not ‑‑ I think... you know, earlier, earlier, just today, I said that we shouldn't waste our time talking about definitions, and yet here I am about to suggest that it also depends on what the definition of "IPAM" is. So, I mean, when I think of IPAM, I think of, like, I am opening a new branch office and I need to allocate a certain amount of space for the servers that are running there, a certain amount of space for printers and things like that, and then maybe space for address, for bring your own device stuff and so on and so forth. I mean ‑‑ and then put each of those in various pools with access control list for access to certain data, you know, all these kind of things are what I think of when I think of IP address management. Another perfectly valid way to think about it is just documenting, you know, which blocks of address are used where. Not in an operational sense, but in an administrative sense. If you are thinking about things from that administrative point of view, Elvis, then I think your point makes a lot of sense, right, because, basically, the RIPE policy requires, or required, I don't know what the current policy is, it used to require that if you had a ledger saying everything is used for, that you have to open up a certain part of that and stick it in the database so that everyone can see. So from that point of view, yes, I think you can say certain kinds of IPAM were required, but ‑‑ I don't know if that answers your question or ‑‑ yeah... sorry, if that's a little muddled and confused.
WILLIAM SYLVESTER: Mirjam was in the queue, so you are now added.
MIRJAM KUHNE: I just wanted to say a big thanks to the task force and all the task force members. I think you did a fantastic job. As you said, it wasn't always easy, but I think you came up with a really good list of concrete things that the community can now take and consider and address, so thanks.
SHANE KERR: Yeah. Great. Thanks, Mirjam. That was only ever, our goal was to ‑‑ is to create a clear document explaining how things work and how they should work and then handing that over to the people to do all the actual work.
WILLIAM SYLVESTER: So we have ‑‑ Elvis has another question, he is on audio now. Elvis, go ahead. Rudiger is in queue. Elvis, if you can figure out your stuff, requeue. Rudiger, go ahead.
RUDIGER VOLK: Kind of, many things come to mind. One thing is, kind of, it is ‑‑ yeah ‑‑ looking at the document, looking at the document now, I find ‑‑ and comparing it to the slide that is up there, kind of I find ‑‑ I am surprised to find stuff that would be in the IETF RFCs in the leading boilerplate sadly missing, which is to point out, well, okay, this is a report that makes some recommendations, but kind of ‑‑ well, okay, it doesn't really claim consensus in the RFCs, you have a boilerplate that tells well, okay, this is work by the IETF and it has gone through IETF process or it has not been ‑‑ did not go through RFC process and is just non‑standardising informational. I certainly appreciate a lot of the work that has gone in there. On the other hand, I have to say, remembering the discussion that I think kicked off the task force, that the momentum for kicking this off really had in mind to figure out with a view to the future, what the supposed requirements or purposes should be, recognising that all the old documents really were old and I think there is more work to review and ‑‑ well, okay ‑‑ review and make more specific statements out of what we have in hand right now. Unfortunately, a lot of work, but the document certainly is a really good starting point, and thanks for that.
SHANE KERR: Thanks, Rudiger, I think ‑‑ if I can respond. I think several of our recommendations are to discontinue the certain functionality the database has now. So, other recommendations we have are to clarify and clean up parts of the database. I think your observation is correct. I don't want to call it a criticism, but your observation is correct, that it's not really forward‑looking necessarily. We are trying to set a point in time and make sure we know where we're at. I don't think there is any expectation, though, that this will be the last word on the database and where it goes. I think quite the contrary. For my own feeling, I think we have got ‑ as you can see from this slide here ‑ quite a few recommendations. Getting through these is not necessarily a prerequisite. It's not something we have to do before we add additional purposes or change the existing purposes to new ways, but I think it's probably a good idea. So, I think there is ‑‑ I don't even know how we would have gone about, like, imagining the future, so...
.
But if anyone is interested in and has their own ideas for what the new databases needs to do, then, please, let's do it.
WILLIAM SYLVESTER: Great. Well, thank you so much, Shane. We're out of time. Moving on, we have Denis Walker with the RIPE Database purposes. So, Denis, with that, I'll let you take over.
DENIS WALKER: Following on from what Shane just said, we want to look at now, one of the purpose of the database, as Shane said, looking forward and take it from now and consider where we go with the RIPE Database.
I did a pre‑recorded presentation which was released last week, which I hope some of you watched, and this is following on from the work of the Database Task Force. But the last time we had a community consensus on what the purpose of the database are, was back in 2011, when the terms and conditions, which included the purposes, was finalised. So the question is: Had the purposes actually evolved or changed over the last 10, 20 or 30 years? Have the stakeholder groups changed or diversified and do we need a policy dedicated to the RIPE Database? My reasoning for that is explained in the video, so I suggest you do go and have a look at that.
And we do need input from as many stakeholder groups as possible. We'd like to put everything on the table for a discussion on this. What does the RIPE Database mean to you? What does it do for you? What do you use it for? Is it helpful, absolutely essential for the work you do? What else could it do for you? What information does it need to contain for you to do your work?
.
I think we do need a consensus on what this product and service is in the 2020s and beyond. Now, when I mentioned this in the Anti‑Abuse Working Group earlier today, one of the comments was that: Well even if we do have a consensus on what the purposes are now, they are not set in stone, they could change again. But that's my whole point. Have the purposes changed in the last 30 years? Because, I know the task force considered many things like IPAM's potential purposes, but the final document really only reflected those historical purposes.
So what I'm saying is today, going forward in the 2020s, have the purposes evolved and do we need to document this and define what the purposes are and have a consensus on it? A lot of the recommendations that Shane has just gone through, some of those depend on what the purpose of the database is. So if we don't know, if we're not absolutely sure what the purposes are, it's going to be difficult to make decisions on some of those recommendations.
So, that's basically a quick summary. Any thoughts on this?
WILLIAM SYLVESTER: If anyone has any questions, you can either place them in the Q&A through Meetecho or you can join the queue and we can give you audio or video access.
Great. Well, I'm seeing no questions. Wait, no, here we go, hold on. Mirjam, go ahead.
MIRJAM KUHNE: I was waiting on maybe somebody else wants to come in and respond before I take up the stage too much.
My name is Mirjam Kuhne, I am the RIPE Chair. Sorry, I forgot to say earlier on. Just, maybe I am just confused a little bit in what you are proposing, Denis. We had a bit of discussion in Anti‑Abuse already. Because we have the Database Task Force report now with a number of quite concrete suggestions and recommendations, and I believe what the task force actually did is to review the purpose and the purpose of the database and what it's used for and how it reflects policy made by the community, you know, for instance in other Working Groups. And so I'm just kind of maybe a little bit of caution and not to, you know, meddle or mix too much or to start too many activities at once, maybe you should take the task force report and go through it and if you feel that one or more of these recommendations that we need to define, like purposes a bit more, maybe we should do it that way rather than starting another kind of very deep activity, as I think you are suggesting, but maybe I am mistaken in what your goals are.
DENIS WALKER: That's a perfectly valid point. But I thought really building on the work that the task force, it would be nice to have this kind of open, public discussion on whether people think the purposes have evolved. If they haven't, fine, then we move on. But some of those recommendations I think do ‑‑ we do need to know exactly what this database is. And, you know, IPAM is a classic example. From what Shane, the recommendation was to discourage it, well then we hadn't actually defined what IPAM is, or there is some areas of IPAM that the database could be used for? Do people want to use this for IPAM? Is it ‑‑ should it be recognised as a purpose? So, even that one point, there is a number of issues that are still open.
MIRJAM KUHNE: So you are saying we should go through the recommendations and then maybe if we come to those where we get stuck or where we don't have agreements, we could actually look a bit more into the underlying purposes. I think I would agree with that. I am just kind of cautioning a little bit to kind of disrupting the process right now, that we have the report, I don't want to just brush that aside and then start from scratch.
DENIS WALKER: No, no, no absolutely. That's certainly an option, to consider this while we consider the recommendations.
MIRJAM KUHNE: Okay, that makes sense.
WILLIAM SYLVESTER: Great. So we have a couple of other questions in Q&A and a couple of other folks in the queue. Thank you, Mirjam.
Christian Bretterhofer, representing himself: "Database stays to be a great resource, so keep it as max as possible."
.
Monika Ermert is a journalist: "If you repurpose the data collected, what would that mean from a data protection law standpoint? Can you easily repurpose?"
DENIS WALKER: I don't think we are trying to repurpose anything, but there are issues like, for example, nobody realised so many people considered the database as an IPAM solution. So, it's a question of how are people using it today, which are undocumented, which I would like to have documented. So, we're not trying to look for new purposes; we're just trying to perhaps document the existing purposes.
WILLIAM SYLVESTER: All right. So, Rudiger, go ahead with your question.
RUDIGER VOLK: Sorry, some technical confusion here.
Well, okay, I would agree with Mirjam about not mixing two separate discussions at the same time. On the other hand, I would say, kind of, the way, Denis, you are talking about purposes, looks, to me, a little bit very abstract and to be ‑‑ to do a really nasty interpretation, well, okay, of course we do not know what is going to be a valid purpose in 10 years, 50 years, so we have to be very open for everything and we don't get anywhere. What I would suggest to consider is, taking the long slides that you did, and actually go through that item by item and check whether, well, okay, that item is worth to be discussed and where and how to do that, in kind of a similar fashion like going through the specific recommendations of the task force. Let me add another point: On the opposite side of a very abstract concept of purpose, there is requirements like: Do we need and have we ‑‑ are we maintaining a reference, a data model for transporting data information? And what are the techniques used for maintaining the relevant specifications? Kind of, as far as I understand it, the transfer syntax for database content is RPSL‑defined. And kind of, I would see a requirement of maintaining a grammar like we had in the RPSL RFCs that actually defines that and yes, you go there and figure out how and where to do the UTF‑8 for coming back to something very specific that Denis raised, and other people as well.
.
So, kind of, yes, the Requirements Task Force paper stays out of those technicalities, but actually I think there are a few technicalities, like what I mentioned, and supporting continued operation of current users that we probably should figure out more in detail and also add to the stuff that goes into the consensus process.
.
Thanks.
DENIS WALKER: I think something like UTF‑8, we can steer clear, because technically the database is capable of handling UTF‑8, but it's the policy side and the interpretation of it that we need to consider, as I said in my video presentation.
WILLIAM SYLVESTER: So we are out of time right now. We have a couple of other questions in the Q&A, and one more in the queue. Real quick before we get to the questions, I just wanted to say thank you to RIPE NCC for their support and help hosting this session. Also, I want to thank the stenographer for their help in transcribing everything that we say. With that, Daniel Karrenberg of the RIPE NCC asks the question that said: "Shouldn't we deal with the task force recommendations now and avoid having two related discussions at the same time? Would it hurt to have the purpose discussion at a later time?"
DENIS WALKER: No, that's a perfect valid point. Yes, I accept that.
WILLIAM SYLVESTER: And Tobias Knecht: "Shouldn't the purpose of the database be connected with the public policy process? If a new purpose comes up with a new policy proposal, it means directly that the purpose has to be extended when the policy passes." Tobias is with Abusix.
DENIS WALKER: Policies and purposes have never been linked before, but maybe, as I said in my presentation, perhaps this is why we need a database policy as well.
WILLIAM SYLVESTER: And, Elvis, go ahead with your question. He seems to be still having some technical issues. In the chat, Athina from RIPE NCC: "Some clarifications from a legal perspective. Any use not in line with the already‑defined purposes in the RIPE Database, T&Cs, is in breach of the T&C's and not allowed. Article 3 and 4 RIPE Database terms and conditions, also indeed any changes in the current purpose would have GDPR implications."
.
So...
DENIS WALKER: Maybe we're not changing the purpose. Maybe we are acknowledging the purpose, that it is being used for.
WILLIAM SYLVESTER: Well, thank you so much, Denis. Thank you, everyone, for attending the Working Group today. We're a little bit over time, but we still have some time left in your break, we will see you next time. Thanks so much.
