25 May 2023
Database Working Group
At 2 p.m.:
WILLIAM SYLVESTER: Welcome everyone to the Database Working Group, I see we saw some folks coming in. Up today we have a great agenda, our usual operational update from Ed, tennis has some stuff he wants to talk about with regards to some concepts we have been discussing regards the RIPE database and we have Maria who is going to talk about some database use cases.
As well as any other business.
There's a few housekeeping items, I want to make sure everyone knows where the fire exits are, you never know when the fire alarm is going to go off, but they are in the back and off to the side. And with that, we are still looking for chairs so if you are interested come up and see the Chairs, I know a few folks have expressed some interest but definitely need help with the Working Group and as always, we conduct all or business on the mailing list. So if you are not subscribed on the mailing list, please do. And if you have any questions or otherwise interested in the database we encourage you to bring all of that to the mailing list. But with that, Ed.
EDWARD SHRYANE: Thank you. Good afternoon, everyone, I am Ed Shrayne, I am a specialist software engineer with RIPE NCC working on the RIPE database and here is the operational update. There is now five of us in the team and this is ‑‑ this update is a summary of all the good work we have been doing since the last RIPE meeting at RIPE 85 in October.
So we have had three Whois releases, two feature releases and one kind of a bug fix release, 1.105. There was an issue late last year to do with a short‑named AS sets colliding between different IRR databases, and to solve that, we switched to only allowing hierarchical IRR sets to be created, existing short named AS sets were unaffected.
The next release 106 we implemented an improvement to set the source correctly for the ‑‑ that it should match the NONAUTH source and that affected a couple of hundred AS sets.
And we started work on the NRTM version 4 so that release contained snapshots and various improvements to our RDAP implementation.
The final release in April we made more improvements to NRTM; we implemented deltas and notification files and made further improvements to RDAP.
We had three outages to go along with the three releases but not coincidental. In late December we had a server migration and mail updates were large were not processed and even worse we didn't send any replies so the mails disappeared into a black hole. We had a new script to process to put mail updates into the database but large updates overflowed the script but we have improved the script and the monitoring so that it shouldn't happen again.
Secondly, on 23rd March the NRTM service was unreachable for a few minutes, we were updating our load balancer and adding a new name and we inadvertently affected the existing service but thankfully we had monitoring and we caught it pretty quickly.
Finally in April there were intermittent interruptions to the Whois query series, we had spikes and we have made some structural changes to address that and that will be in the next release, in the meantime we have mitigated it.
And the last point, there is a new website status.ripe.net, it's independent from the old website where the announcements were posted and you can check that site for outages and if you have a problem with the service, please let us know as well.
So statistics.
So, as usual, a bunch of statistics on recently created features, regular Abuse‑C validation, we are about halfway through, there are 93,000 Abuse‑C addresses in the database and there are 55,000 left to be validated, but we are on track seeing as we are half ‑‑ nearly halfway through the year. There's two related clean‑ups for the NONAUTH source, we deleted 107, 47 and 77 Route‑6 objects to do ‑‑ conflicting with RPKI and also unregistered prefixes.
So the NONAUTH source is still over 50,000 objects in total, but automated clean‑ups like this are really helping to reduce the size of it.
NWI‑8 to syncronise portal users to the default maintainer, we have seen that there's less organisations syncronising, not sure why, slightly fewer I think it's a really useful feature.
And lastly, the NWI‑9 to the ‑‑ now that the NRTM service is open, there's no agreement needed, we have nearly 1,000 distinct client IPs now using the service which is three times more than around the last RIPE meeting.
So, we have had two database clean‑ups related to NWI 19, it was 76 so we moved 76 AS Z objects to match the aut‑num source and we notified maintainers. And secondly, we unlocked nearly 500 assigned PA and legacy resources; they were locked a long time ago, 2004. And our registry services department from time to time get requests from LIRs to unlock them, but it was time to clean that up and do a blanket fix, as many as we could so they are now set to the LIR default maintainer and again we notified maintainers of those objects.
Operational work, we now have an operational person within our team which really helps with operational stuff, we found that grey listed responses in the Abuse‑C e‑mail validation job was not being supported properly so we fixed that. So it means there's a lot less false positives on the Abuse‑C validation which really helps, reduces the ticket load and the false positives going out to our users.
And we made some progress on passwords, we are protecting secrets better in our pipeline when we deploy Whois. Previously secrets were mixed up with the properties and now they are separated and a bit more secure. And we are improving the password rotation process as well; it was quite cumbersome and hard to do so we are trying to make it now a more regular and easier to retain passwords.
The web application, the focus for that since the last RIPE meeting was to ‑‑ we are continuing on the work to make it Open Source. We believe it's a good thing we work in the open and all of our software should be open, as much as possible. But we need to clean up the code before we do that. And one major thing was to remove test data from ‑‑ identifying test data from the production database into tests, we need to make the tests anonymised tests basically. And we got feedback from our info secretary department, external review of the code is a good idea or we are planning to do that before we proceed with making it Open Source.
RIPE database documentation, I think I mentioned this at the last RIPE meeting as well, we want to make the documentation easier to maintain and also we want to accept feedback and changes from users so we have switched to using Markdown, the documentation is using its own repository now, it's Open Source, and we are deploying from that repository and in progress we are continuing to migrate documentation, there is a DB support area on the website with a lot of very old documentation in there, we are either deleting really old content that is or we are ‑‑ yeah, where we can, where it's still useful, relevant, we will put it on the new documentation website and we are putting redirects in place in case anyone has bookmarked the previous location.
RDAP, our registration data access protocol, it's standard across all the RIR supporters, we made some improvements, we are now redirecting inverse to main queries so to the authoritative source in the same way as we do for aut‑num, Inetnum and I 6num and we made various improvements to a line with how the other RIRs are doing it so we are ‑‑ we had networks and aut‑nums elements, we are not returning AS block any more so it's flat model for the service, we are including descriptions, ordering elements so the response is consistent and finally, events and notices.
So you will find that the response from the RIPE database is a lot more consistent now with the responses you would get from the other RIRs.
Full text search API. So we were asked in the past to Open Source the full text search AP, and make it available, because it's a nice complement to using the Whois, the Whois service, and it was open, it was open ‑‑ it has been open, but it was tailored more for the web application, so rather than end users we focused on making it ‑‑ we fit with the full text search page. On the website, but it is more generally usable, I think, useful, we are ‑‑ firstly we had to Switch the Open Source ‑‑ the engine to Elasticsearch to make it a bit more robust. Previously we were using the Lucene engine which is built into Whois but if we have a problem in Lucene we can crash. It's more available, clustered and we have it in a separate process so should be more reliable and it means we can develop changes faster in the full text search engine, that we don't need to wait for Whois release to make operational or changes to the index.
So we have raised per request limit, and removed the ten page request limit which is also tied to the web application, made some bug fixes, which is in progress we are improving the documentation so you a need documentation to be able to use the API. So we will publish that and announce it shortly.
And just to go through some examples, the end point is there, it's public, pubically available, you have a choice of XML or JSON, you can query for string, you will get a lot more matches than with Whois, so you can match remarks, descriptions, AS sets, imports, exports, query by string, limit by object type and/or the attribute and you can have pagination because of the per request limit, if you want more results you will have to start using pagination but I think it's pretty straightforward to use.
Moving on to numbered work items. So the progress we have made since the last RIPE meeting. Firstly NWI‑4, role of status field in multi valued status context, published impact analysis in December and that is for a specific proposal to use the ‑‑ solve the problem definition by adding a new status, allocate it assigned PA, the advantage is it's more straightforward solution, the drawback is that the LIR and the customer, the end user cannot share the object, it's already co‑maintained between the RIPE NCC and the LIR, so it means the customer can't make edits and it's going to be pretty cumbersome and in bold here. Is this acceptable to the Database Working Group? And thank you, Vessel, for his contribution yesterday. The alternative is to use a topple, the prefix plus the status, that's to be because we already do something with route and Route‑6 objects, but the drawback is clients need to be aware of this and use the topple because as more of these objects go in, there's more likely there will be a collision and if you just use prefix you will have multiple matches.
NWI‑10 as we said at RIPE 85 we were wrapping up the definition of country, we populated the country code where available, the vast majority of end user organisations we had data for that at the RIPE meeting so the following week we populated the database, and then I think in the following month we finished, the changes are now syncronised from internal registry, so changes to the country code, the legal address in the internal registry are reflected in the RIPE database and one of the change we made was to make the country code editable in organisations without co‑maintained resources, this is consistent with how other attributes in other types of organisation objects. The downside is, what it means is not defined, so it can be ‑‑ it can cause some confusion so I think we need to define what it means so to make it a bit more useful.
NRTM version 4, this has been the focus of our development since the last RIPE meeting, we contributed to the draft RFCdocument and thank you to my colleagues on the community on their hard work on this. We have now mostly finished the server side implementation, it's there for testing and the URL is there and links to the notification file to the latest snapshot and delta files. If you go to the RFCenvironment and make some changes you will see them reflected in the delta files. So it's ready for testing. It's not enabled in production yet, the co‑changes have been in the last two Whois releases but it's not feature complete, we are working on signing notifications, key rotation and we want to set up a CDN because they are multiples of hundreds of megabytes and if we have a thousand clients as we have we see in the current version 3, we want to put a CDN in front of that traffic. We expect an upcoming client side implementation to take advantage of version 4.
This has been a long time coming and apologies, it hasn't had the priority of the other numbered work items but this is a proposal to protect references to object in the RIPE database because extending the MT ref to four more object types, the solution definition and impact analysis are in the Working Group now, there have been no objections, I think there was one e‑mail of support so you can expect that in the next Whois release.
NWI 19, as discussed the last ‑‑ the first two Whois releases since the last RIPE meeting implemented NWI 19, that only hierarchical As‑set names are now ‑‑ can be created now. And the AS‑sets referencing NONAUTH numbs have the NONAUTH source.
Moving on to upcoming changes. So the work that we see us working on between now and the next RIPE meeting:
So firstly client certificate authentication and this has been in the pipeline for a while. We implemented using our proxy layer, years ago it was a Beta, so the idea here is you can use the certificate that you use to make the TLS connection as the way that you authenticate the Whois updates. And it was working, we removed the proxy layer which we had to go back to drawing board, we found it difficult to implement this using the load balancer set‑up that we have. So we are going to now move this TLS support from the load balancer to the back‑end servers so we have more control over the session; this will give us other advantages as well. Like in singleserving test environments where load balancer is not necessary. This will allow us to support optional client test certificates in the HTTPS request.
Secondly, cleaning up remarks attributes, there are various remarks in the RIPE database from years ago, decades ago and there's four examples: ERX transfer, references by names, NONE authentication scheme dep rated and the REV SRV so we proposed doing a clean‑up to remove those remarks, they are no longer necessary. But I will e‑mail the Working Group with a more complete proposal to do that, I want to let you know we are planning it.
More RDAP features so these are in the pipeline, other RIRs are implementing them. Firstly redacted fields so there are some attributes we don't want to send ‑‑ to reveal in the RDAP responses such as auth attribute in maintainers, and rather than not return anything, we want ‑‑ we are going to implement this feature that will tell the clients which attribute we have not returned. And we are using redaction by removal right now.
The RIR search so you can research for entities already but we want to extend that to searching for INET by net name and auth nums by AS name. And you can do relation searches and searching by status, we think this will be a useful feature for RDAP.
We have one more section, using the Cloud, and I want to quickly give an update.
Building on a fully based presentation yesterday at the Services Working Group I want to revisit the work we have done for the Cloud, and firstly trying to explain why would he use the Cloud? There are some challenges we have with the current on premise environment we would like to address we feel that the Cloud has a role in helping us with this. So I see there's four main areas. And again, Felipe's presentation and the framework we have on the website goes into this a little bit.
Firstly availability or on premise environment is vulnerable to denial of service attacks and it is in one geographical location. So we would like to spread the database a little bit more, and make it more available using Cloud services.
Resiliency, we want to improve the resiliency of the Cloud ‑‑ of the database using the Cloud.
Security, they are much security frameworks and giving you more fine‑grained control over your data, using Cloud services.
And finally, we want some more flexibility, we see Cloud services is a way to ‑‑ more easily roll out new services and future‑proof the Whois that we can make improvements using these services.
So in summary, a Cloud architecture will help us deliver better service to the community. But that said we will still maintain an on‑premise environment for fail‑over.
And using the Cloud just to recap what was said yesterday, we have recently updated the Cloud strategy framework together with service criticality definitions which were agreed with the community over the last two years, the external ‑‑ in the Database Working Group specifically, we sent a questionnaire on the external criticality levels for the external areas, published that in the Working Group last year and asked for feedback; that was finalised a couple of months ago. And internally we also determined impact levels on various internal areas so different departments in the RIPE NCC gave us their feedback on what they expected the impact levels to be for different issues with the database.
And the final service criticality ratings are a blend of those two external and internal feed backs and the, in particular for the RIPE NCC we see data confidentiality as high, data integrity as very high and data availability as high, and we would use the data availability level as the basis for our Cloud migration.
And finally, next steps:
So, I didn't come today to present a plan on the Cloud migration but I would like to instead start a consultation with community, like we do with other areas. We are going to create a high level architecture so you have something to discuss, something to talk about in the coming weeks and we will publish that on the website and then we can start a discussion in the mailing list.
Secondly, once the high level architecture is there, we want to address concerns previously raised and we want to engage the community more and refine the architecture based on that feedback, and finally we need to make a decision on whether to use the Cloud or stay on premise for the challenges we are facing with the current architecture. Thank you for your attention. Any questions?
(Applause)
AUDIENCE SPEAKER: Regarding NWI‑4 on I think it's page 15, I seem to recall there being discussions about using the tool ‑ in the past as in having a primary key for Inetnum and status but was considered to be like the impact was too big, because I liked that idea more, I think it's a better idea but well if ‑‑ so, has something changed am I completely misremembering?
EDWARD SHRYANE: You are correct, there were two tracks or possible solutions to this, I presented a proposal in December around the new status because it seems more straightforward. On the other hand you can't could maintain the object so that might be not acceptable. If not, I will create a new impact analysis for the other solution and absolutely, that is quite feasible because we have already done it for route around 6 objects there is a Tupple there but the problem is potential for client breakage because the prefix is not enough any more.
AUDIENCE SPEAKER: Yes, I would appreciate an input analysis.
EDWARD SHRYANE: If the community can comment on their preference and I will create a new impact analysis for the Tupple, thank you.
DENIS WALKER: Thanks for bringing up the issue about comments as well, particularly the ERX, ERX stands for early registration transfer. In the early days, a lot of the legacy space ended up in the wrong RIR databases and some in multiple data bases so the idea of the transfer 20 years ago was to move it into the RIPE databases. Some of those comments are actually where the objects coexisted in both ARIN and RIPE databases, we merged the data into the new RIPE object and we put a comment asking the resource holder to actually fix it, and to put ‑‑ to put the RIPE data in those objects, 20 years on we still have those comments because we still have the combined data, nobody has actually touched those objects in 20 years. So a question I would like to throw out to the community: Should we do anything about that? It's not just the comments that's a problem, it's the data in those objects that's a problem. So, does it matter to anybody, does it anybody to anything or anyone? Should there be any process to try and fix that data?
EDWARD SHRYANE: Thanks, Denis, I would ask then if there's still a purpose for that data in the database and if not we can make create a proposal to clean it up.
DENIS WALKER: The objects are there because the data exists but ‑‑ surely the object still exists because they are legacy resources, but we don't know who owns them, we don't know what the data means, if it's correct so what should we do?
EDWARD SHRYANE: I will ask that question in addition to the clean‑up when I propose it on the Working Group.
AUDIENCE SPEAKER: I am Magnus, when I automate things I prefer RDAP in front of Whois and in the Whois repository at GitHub you have a read me for RDAP with 15 things, that's not in there yet but it doesn't say much if it's things like lack of time to implement it or if it's lack of standardisation in the RFC and how much involved are you in sorting out things that may be lacking in the RFCwith the data model like managed by objects that's put in the registrant field like ‑‑ it would be better if this read me field had no, like, what will be the way forward for each of these bullets
EDWARD SHRYANE: Thanks for your feedback. We are involved with the IETF and other RIRs, we collaborate with them, and this kind of effort the last six months have been to standardise the protocol where possible and the sticking points in that "read me" are to do with inconsistency between the protocol and the RIPE database. For example, if you look for entity with specific name you can have a collision with maintainer and person of the same name and without a fix in the spec, it's really difficult to resolve things like that. So we are reducing that list and that list has gotten shorter since the last RIPE meeting but eliminating it completely is going to it be tricky. So we are down to the trickiest issues with the protocol now.
AUDIENCE SPEAKER: I understand that. Just a little bit more information if it's like data model problem or lack of time or whatever or decisions, so it would be more informative.
EDWARD SHRYANE: Thank you, I will do that.
PETER HESSLER: Peter Hessler from Globalways, because we have it coming up on the slide please inform the meeting before making any changes, I am sure those are already in your plan and will be communicated to us in the future but I say the words clean‑up and please inform
EDWARD SHRYANE: Thank you, duly noted in. In the previous clean‑ups we did make sure to ‑‑ it's a point well taken, it's something we need to do, keep the community informed and the Database Working Group informed. Okay. Thanks for your time.
(Applause)
WILLIAM SYLVESTER: Up next is managing the RIPE database with Denis Walker.
DENIS WALKER: I just need to wash the coffee down. Okay. One of the benefits of being retired is you have plenty of time, at least in the short term. That gives you time to think, time to reflect, time to review, time to do what if, kind of analysis, particularly being an analyst as well. So this gives me time to think about the RIPE database, how have we managed it in the recent years; is it working? Is it optimal? Is there a better way of doing it? So I came up with this, well, these thoughts have been building in my mind for quite some time so I thought I'd just throw the idea out to you and see what you think.
And one of the questions is: Is it time for a change?
There has been a frustration in recent years about the community involvement in database management, sometimes the lack of, but is the real problem our expectation of the community?
The RIPE NCC provides a lot of services to the membership, to resource holders to the wider community, things like RIPEstat, LIR Portal, RPKI, web services, SSO and the database. None of these other services demand a higher level of community involvement over the fine detail of every small technical change. So, why should we demand or expect this for the RIPE database?
Is the RIPE database was one of the foundation pillars of the RIPE NCC, it's still kind of a unique service but has matured.
Everybody is busy these days, there's lot of demands on your time, in a business sense you will only invest your time in something that gives you a return. What is your return on a small technical operational change to the RIPE database?
You may see a comment on the mailing list and think, yeah, that would be useful. If only someone else would sort it out.
And for us to expect you to get heavily involved in the discussions, the analysis, the design, the implementation, and all these details for these little changes, it's just completely unrealistic. And the reality over the last few years proves that point.
So, what is important to you:
Let's create two categories of changes to the RIPE database. Those changes that involve registry and policy issues, and those changes have more of a technical and operational nature. And these two categories of changes can be managed in different ways. Over time we can fine tune it to decide what is a policy issue and what is more of a small technical change.
For the registry and policy changes, these are usually more critical changes; they do need a wide discussion and they do need a consensus, they may need full PDP process, examples are things like discussions on privacy, how we use legal addresses, change of the database purposes and that kind of thing.
For the technical and operational changes, we use this numbered work item system now. Well, it still requires the community discussion and a consensus on that discussion, well the community is often indifferent on the detail of that change or sometimes even the outcome if it's not relevant to you. If there's no discussion or comments, there can be no consensus and if there's no consensus, nothing changes.
Even though nobody has any objections to a possible change, the database is just technically frozen in time because we don't have the discussion, we don't have a consensus, we can't change anything.
So the Chairs are proposing a new way to manage these kind of changes. We should still announce any issue or problem as we do now with the NWIs, out on the mailing lists, anyone in the community can choose to comment, or not, as you wish.
Then we shall allow the RIPE NCC, who have some fantastic engineers, to propose ways to solve these issues and to implement those solutions.
So, we should give the RIPE NCC a mandate then to actually make these changes overseen perhaps by the Chairs.
And some examples of this is one we just mentioned, how we assign an allocation object, historical queries that go beyond the most deletion point, NRTM version 4, that level of change.
So what effect will this have?
If the community comments and discusses on the issue that we have put on the mailing list, then that's fine, all those comments will be taken into account as we make a decision. But if the community's indifferent on the detail of how we make these changes, the outcome of the change, then we listen to the silence and then the Chairs instruct the NCC to get on with it.
Everything will be done openly and transparently, everything will still be on the mailing list, nothing is going to be hidden. The community can start or restart a discussion on any of these issues, at any time, as you can do now, and changes to the database are rarely irreversible. If we were going to do something that is actually irreversible, then that would be a major change that would perhaps require PDP or serious discussion and real consensus.
But at least this allows the database to evolve and improve as a service, which at the moment we just can't get, so many of these little issues implemented because nobody wants to talk about them. To you, they are not that relevant, they are not interesting, you don't have the time, but you done object to it, so we are stuck.
Well, the community is still in control, even if you don't say anything but you don't object to it, we take that silence effectively as consensus, we tell the NCC to get on with it and fix the problem or sort out the issue. You are still in control. If you don't like a decision, you can talk to us on the mailing list, you can say hang on a minute, we don't agree with that, maybe this is the multi version that will prompt you to actually say something sometimes on these issues. But silence would be consent.
I also think there are many issues around and surround the database that could be considered as policy issues, outside of existence poll like Address Policy and sometimes anti‑abuse policy. So we are thinking perhaps we do need now a basic RIPE database policy where these sort of issues can sit and the at the moment we don't have anywhere to put these and that could be developed and extended over time. Some examples of what could be in that kind of policy is the database purposes.
We have the terms and conditions of use of the RIPE database, we never say that bit of use, we just talk about terms and conditions, but that's what they actually are. This was ‑‑ the terms and conditions were put together way back in 2010 by the task force we had at the time and as part of that task force we also identified and listed the purposes of the RIPE database and it was just convenient at the time to pull it all together into one document. But really the terms and conditions of using something isn't where you would normally define what it is, what it means, why it exists, so that is perhaps more suited to a policy. Also this process for managing technical changes to the database, if we were to put that into a policy it gives it a bit more authority to actually do these things.
So, where do we go from here?
This presentation is basically giving you the bare bones of an idea of how we can move forward and break this stalemate we have on a lot of these issues. If we decide to move on with it, we can expand on the detail. But the goals are basically to keep the RIPE database moving forward as the industry and as society changes and to keep up with those changes, to improve it over time as a product and a service; avoid these technical freezes due to the indifference, and to make changes efficiently and conclusively.
So please discuss and if you have any questions, fire them at me.
AUDIENCE SPEAKER: I really support this, because well yeah, it's a big issue. There are very few people who are active on the mailing list and even I sometimes I guess don't feel like I have the time or energy to do something or like to say yes I support this or I support ‑ it's good that ‑‑ or I think it would be good if the database team could like propose things because even if I can give input, it's very rare that I have like new ideas of things that could be improved because, well, the database team knows this best. So that was the main thing that I just ‑‑ I really support this.
With regard ‑‑ and then there was the whole thing about the having a data policy and I was thinking has the legal team given some impact ‑‑ or input I mean on the proposal to move things away from terms and conditions and into a policy?
DENIS WALKER: If we were to do something like that, it would be via a policy proposal and the PDP and as part of that process it will have a legal review so all of that will work into it and we are not going to sidestep anything.
AUDIENCE SPEAKER: Has there been some input on the general idea? Is that a ‑‑ there's some obvious issue that would would make it work?
DENIS WALKER: I haven't sat down at any point with the legal team and said specifically what do you think about having a RIPE database policy, but I have hinted at it quite a number of times in recent meetings.
AUDIENCE SPEAKER: Hello, I agree with the additional flexibility, I am not against it. The only thing I want to spend a word on is on the wording difference, sometimes in ‑‑ sometimes it's not indifference but as sometimes it can be that requires a lot of interaction and in some mailing lists more than others so basically at some point I feel it for myself, never mind, I am going to regret doing ‑‑ what I am saying is we could do a way because I quite like how organised and structured the work is with the NWI items, we can to a way where we can vote, we are all behind the RIPE NCC so we could just say yes/no, instead ‑‑ because also in mailing list like at the meeting there are people more vocal than others so sometimes you start and it never ends and then it gets annoying. And nobody interacts any more. So I think a way in the middle where it's easier to just vote would maybe simplify the process.
DENIS WALKER: One of the problems with a mailing list is you get a narrow group of people who commonly speak about various things, you get other people in the fringes who then feel a little bit shy or intimidated to speak up and actually question somebody with more experience or apparent authority than they have so you get narrow views, sometimes whether it's indifference, whether you don't have the time, whether you don't even have the technical knowledge of how the database works internally to be able to argue about how to do something, that's why the RIPE NCC has full‑time engineers who know the database inside out. So one of the ideas behind this is to give the NCC that authority to actually propose the ways of finding solutions to these problems because they know how the database works, a lot of other people just know how to use it.
AUDIENCE SPEAKER: I agree with that, especially for the small technical things that's totally fine, I wanted to clarify on the indifference.
PETER HESSLER: I have found NWI process to be incredibly frustrating to deal with, if you remember when it was introduced there was a lot of activity and discussions around it and then it died because nothing would happen or change and I actually feel like it would be better for us as a community to go back to the traditional PDP process, like that's actually has more structure about it, we have time frames and I think time frames for knowing when your comments would help, would make a big difference. I am also a little confused that I thought the database team in the NCC was able to submit suggestions to the community, I thought they have always had this ability.
DENIS WALKER: Well, there is this discussion in parallel that Mirjam started as the RIPE Chair about how the RIPE NCC staff get involved in community matters so there's kind of an overlap here. I mean, some RIPE NCC staff don't feel comfortable pushing their ideas or views out into the community, so it's a bit of a double‑edged sword.
AUDIENCE SPEAKER: True but on one hand you have, for example, a proposal that would change a policy within the database itself and then the other hand, you have technical suggestions, for example, NTR MV4 or client certificates for authication where their knowledge and their ability to push that to us to at least bring it to our attention would be hugely beneficial for them.
DENIS WALKER: Yes.
RUEDIGER VOLK: It seemed to me that your slides had a lot of details that may be actually a little bit hard and wrong to put altogether in one pot. I am not able to go through all of them and I think there's certainly got problems and I think it is important to use the word in the plural and the various problems are relevant for potentially different people, so let me at least point out something that I think was not in your sketch. In some cases ‑‑ well okay, the frustrations with the NWI process that I personally had, was that at ‑‑ in some cases, there was actually quite some activity in discussion and kind of what I think would be very appropriate is to make sure that for progressing stuff one puts out a schedule with milestones and one makes sure that, actually, for each milestone, a summary of the current understanding of someone like the Chairs or a discussion leader for a specific item, gives and ‑‑ well, okay, removes the necessity for going through all the mails of the last six weeks to figure out what has been said and figure out for everyone the personal evaluation of what probably is the common understanding. If ten people are trying to do this, we might actually end up with eleven pictures and kind of for getting actual involvement of community, it is important to have a few people who really actively drive the considerations, but community actually means you need the observation and consensus from a wider population. And I think that's really important, and getting the consensus in that sense really would use a lot of help from getting summaries at the critical milestones, and I think that hasn't been organised so far; it's actually real work for someone.
DENIS WALKER: This is how we have worked in the past and the problem there is, when you don't get a discussion, there is nothing to summarise. Somebody came up with an idea or highlighted a problem and nobody else really cares but it's something that technically if you fixed it it would make the product better.
RUEDIGER VOLK: Well kind of, if nobody cares, well okay there's one single person who has a problem.
DENIS WALKER: Many of you may have the problem, most of you just read his comments and said that's okay.
RUEDIGER VOLK: Kind of, whether you take silence as consent or dissent, kind of, well, okay, that's a wild guess. And, in fact, I would say I feel much safer, really security, if no active consent about a change is achieved if that's ‑‑ that does not happen, even in the version of nobody talks about it.
DENIS WALKER: That gives a technical freeze.
RUEDIGER VOLK: Well okay, sure, sure, people who are concerned about security, usually prefer stability.
DENIS WALKER: And they will speak up.
RUEDIGER VOLK: Yeah, and at the times back couple of years, when the database team decided that they wanted to be agile and not tell the community that they just messed around with the software again, I was in big ways hit, and we had heavy discussions and made sure that we got the test environment so we actually can make sure that changes are fine and for more policy‑orientated stuff, yes, just being agile per se is not necessarily better.
DENIS WALKER: The problem with that approach is human nature is that if you don't like something you speak up. If something is fine, you don't bother saying anything. And that's why with a lot of these issues that nobody objects to, nobody says anything, but they think, if you did it, I will probably use that feature.
AUDIENCE SPEAKER: I can say that I ‑‑ for the things that don't have much discussion, I do, even if you don't give input because like I don't feel I have energy to send an e‑mail, I do generally read it all, and like if I disagree with it, then I will speak up; or if I agree with it, then I probably won't speak up at all.
DENIS WALKER: A lot of people do read the mailing list but they don't speak about it.
AUDIENCE SPEAKER: There are a few cases where there's a lot of discussion, where there's too much discussion and like, when you can have so much text about this one thing and it's just back and forth,
Back and forth, back and forth.
DENIS WALKER: Well, geofeed was a good example of that, but that's because a lot of people really wanted it so they spoke up.
AUDIENCE SPEAKER: Then you reach a point, I am not sure if it was geofeed or the thing about removal personal data you get so much that you just like ‑‑ check out, I took a break from interacting around the ‑‑ on the Database Working Group mailing list because I couldn't handle it, it was just too many e‑mails, too much, and it was ‑‑ it's like either there's no discussion or way too much. Or if possible, just say okay, for sure maybe earlier this is not going anywhere, but like let's summarise this and then just not continue this specific part of it any more because it's not going anywhere. That's it.
DENIS WALKER: The last two commentators and then we will wrap it up for today.
PETER HESSLER: One of my frustrations with the NWI work was that there was a lot of discussion at the beginning and then, because nothing happened, I felt demotivated and like, well, if the community doesn't care, I don't care to spend my time on this. And even though for several of those, I can't remember which ones, I have to look back at archives, I felt like we had achieved consensus on several of them but there was no declaration of consensus that was made and there was ‑‑ so there was no progress being made so okay, if we are not going to do anything I'm not going to do anything so why should I care. And then also, unfortunately, the last few years we have had a pandemic, it's been time consuming, it's been taking a lot of mental energy from a lot of people so a lot of activity in the last three‑ish years has dropped because of this.
DENIS WALKER: This issue predates the pandemic.
PETER HESSLER: It predates the pandemic, but the pandemic made it a lot worse.
DENIS WALKER: The reason no consensus on some of those issues is because, you got a comment, three months later and two months later another comment, can you really lump those comments from months ago and say, now we have a consensus because three months ago somebody said that?
PETER HESSLER: I would respond with, at the very beginning of NWI there would be ten e‑mails within a week, all of them positive, nobody had any objections, nobody had any concerns, they wanted to ‑‑ too much on mailing list and then nothing happened and that was where I got discouraged separately from it.
RUEDIGER VOLK: Peter, I think, was pointing in some of his comments about ‑‑ at some point a summary was missing which kind of matches a point I made earlier. And Denis, your question, well, if, with two months time in between, five comments come in, how figure we out what the consensus is?
Well, if the five comments all were saying, yes, this specific document is fully endorsed by me, well, okay, the message is easy and clear and Mark, it is referencing a very specific clearly defined text. If you have a discussion with five comments over whatever time or 25 comments over some other time, and they all ‑‑ they all are contributing some idea, interesting question is: Well okay, what is the supposed text that actually codifies what people are agreeing about. In IETF the procedures are, you essentially are working on an Internet draft as a text that has multiple sequential versions and the consensus process is to work on that document and when the last call is made, it is quite clear what the consensus call is and the comments that come in then may be detailed arguments and the Chair of a Working Group is empowered to say, well, okay, yes, this ‑‑ this ‑‑ these various comments are fine and covered by what's in the text or these comments are not really relevant or something and one has clear thing.
With the NWI process, we do not have that reference document, and by the way, actually, in the PDP we have a similar problem. And I think ‑‑ I think that's something that actually has to ‑‑ has to be dealt with with the ‑‑ with the existing processes just saying, well, okay, take silence as consent; I think that is not sufficient to actually improve process and output.
DENIS WALKER: Okay, thank you.
WILLIAM SYLVESTER: Thank you, Denis.
(Applause).
Up next, RIPE database use cases, Maria from RIPE NCC.
MARIA STAFYLA: Hello, everyone, I am senior legal counsel at the RIPE NCC. And I am here to present you some observations that we made from certain RIPE database use cases.
Our goal is to present and create awareness on how we have seen the RIPE database being used and interpreted, and more specifically, how information was misinterpreted and the confusion that arose consequently.
How did we get here?
We made these observations from the various Whois cases, namely we have seen published research about the location of specific resources while using RIPE database information, from binding and non‑binding LEA requests and orders and also requests for information from other stakeholders on how to use the RIPE database. We have grouped and analysed the use case and we will present them per category or attribute of information that was used by the use. But before we dive into the different categories, just a reminder of the big picture here that the RIPE database is there to provide information about the registration of specific Internet number resources, different objects are available to show who the responsible parties for resources and how the resources are being used and it is a co‑maintained database meaning the RIPE NCC maintains only certain data, the rest is by the resource holders themselves.
Now, the first category is regarding location of resource or resource holder and the attributes that were used were the country and the address.
So first of all, the country attribute:
We see the organisation objects and in Inetnum and Inet(6)num objects so ‑‑ as mentioned, since we implemented NWI‑10 in organisation objects that are referencing resources that are co‑maintained by the RIPE NCC, for example an organisation object of a member, then the RIPE NCC maintains the country attribute and it will point to the country where the resource holder is legally based.
We have included links to the implementation plan and the impact of the first phase here. Whereas in organisation objects that are referencing resources that are not co‑maintained by the RIPE NCC, for example organisation object of a customer of a member, the resource holders themselves maintain the country attribute and they are allowed to insert whatever code suits their needs.
Again, as mentioned, initially when we implemented NWI‑10 nobody could add the country code in these organisation objects, but later on we changed the practice so that we bring alignment with the rest non‑RIPE NCC maintained data.
In Inetnum objects, it is always maintained by the resource holder themselves and they are allowed to edit it as they see fit.
So, when country attributes are allowed to be edited by the resource holders, there is no definition to what country these attributes should refer to. There has been recently in discussion in the Database Working Group with different views on the matter and there was no clear definition or the need for a definition was not agreed by the entire Working Group.
The use case and what we have seen happening, we have seen research using the country codes inserted in inetnum objects in order to tie specific resources to a specific country. From our point of view, this was not an accurate interpretation of the RIPE database information because there is no agreed definition how these attributes should be used. So in our initial response we explained the difference between the types of the country codes and who is responsible ‑‑ the country attributes, who is responsible for maintaining them, for what purposes they might be used and what is the process for updating RIPE NCC maintained data. We have alos recently published RIPE Labs article explaining all about the country codes in the RIPE database.
Now, the second attribute that was used in the first category is the address in an organisation object, which is in all cases maintained by the resource holders themselves.
There is ‑‑ the address could point to the postal address of the resource holder, however there is no strict definition and anyone can update it as they see fit, which could result in having contact details, address in an organisation object, especially in an organisation object with co‑maintained resources with the RIPE NCC where the country attribute is maintained by us, the address might point to a different country from where the country attribute points to. So for example the country code points to country A whereas the address details point to country B.
We have received questions on how to read and interpret this information, what the address should point to about the validity of the data and what can we do with regards to this.
Overall we saw confusion and uncertainty about the validity, correctness and the value of this data.
So, just to summarise a bit the difference between the objects, the attributes and who is maintaining what, we have included this table here where we are explaining the differences in who is responsible for maintaining this information, and of course, we will be following any discussions that are relevant and are happening in the Working Group and we remain at your disposal if you need any support from us.
The second category is regarding resource holdership and the attributes that were used were the org type and status attribute. Each has mandatory org type with a purpose to indicate the type of the organisation and whether they are an LIR, RIR or other. And each resource object has a mandated status attribute with a status to indicate the key and who is responsible for particular resource.
We have received binding and non‑binding LEA requests and orders to take actions or provide information about resources that are mistakenly thought to be registered to a particular party. For example requests for information about resources that have been registered by a member to one of their customers or orders to take actions on resources that are not co‑maintained by the RIPE NCC, for example the member has further allocated them to one of their customers. We believe that this was because the requesting party had misinterpreted the org type and the status attribute, so when they queried the RIPE database they did not understand they were not the ultimate holder of this block or the particular resources.
We are currently considering adding further clarifications, a glossary on the web application of them ‑‑ of the RIPE database so that certain terms becomes clearer and it's easy for someone who is not familiar to understand what the information shows.
Of course if there are any other suggestions, we are here to hear them.
And with that, that's the end of my presentation. Any questions?
(Applause)
AUDIENCE SPEAKER: I want to say I think the idea of a cluster is a great idea, that's it.
MASSIMO: Thank you for the great presentation. Just a question: Since the country for Inetnum is apparently will remain unspecified, if I understood correctly, can we make it optional?
MARIA STAFYLA: I think this is for the Working Group to decide.
AUDIENCE SPEAKER: Because at the moment it's unspecified and mandatory, so it's a bit ‑‑ you know ‑‑
RUEDIGER VOLK: I would agree with Massimo and should we kick off an NVI?
WILLIAM SYLVESTER: Any other questions?
PETER HESSLER: For the attributes that are maintained by the RIPE NCC versus the attributes maintained by the community, would it make sense to have different labelling for that so it becomes much more clear to somebody who is just looking briefly at the database that these are not the same thing and that one group is more controlled by one and ‑ of the other?
MARIA STAFYLA: It is already visible in the database which values by the RIPE NCC, they are highlighted. But perhaps I did not understand your question.
PETER HESSLER: You can't see the highlights if you are using text‑based Whois so as far as I understand you can only see that in the website.
MARIA STAFYLA: Feel free to correct me if I'm wrong, you will see it on the website, only on the website.
PETER HESSLER: My comment is more having a different naming scheme for that could simplify that for users who are not generally users of the RIPE database?
MARIA STAFYLA: We can think of that, thank you.
AUDIENCE SPEAKER: I think ‑‑ I don't think they apply to your thing, but if Peter and someone else wants to talk about this afterwards or on the mailing list I am happy to do so because I also have some thoughts about this.
DENIS WALKER: Co‑chair of the Database Working Group. If you are going to write a glossary, not just to the RIPE database but covering this industry, RIPE documents, policies, I mean I still cannot find anywhere a definition of an LIR, and yet it's used in all our documents, so can we have a wider glossary of terms that are used commonly in documents?
MARIA STAFYLA: I will take that feedback internally.
WILLIAM SYLVESTER: Thank you so much.
(Applause)
We have any other business, about 10, 15 minutes left, is there anything else anyone wants to discuss about the database, proposals, anything we have talked about? If nobody comes up, Denis is going to speak more.
DENIS WALKER: We have consensus on silence.
WILLIAM SYLVESTER: With that, I want to take a minute and thank our stenographer for doing such great work and our audio team in the back and let's also thank RIPE NCC and the secretariat for all of their help on the presentations and for helping us out with the scribe. We will look to see everybody in Rome and hopefully on the mailing list. If you haven't subscribed, please do. And look forward to seeing everybody next time. Thank you so much.
(Applause)
LIVE CAPTIONING BY AOIFE DOWNES, RPR
DUBLIN, IRELAND
