RIPE 91. Thursday, 23rd October 2025. Side room. 9am, database.
PETER HESSLER: Hello everyone, welcome to the database working group session here at RIPE 91. My name is Peter, I am a co‑chair together with David who you will see on stage in a few minutes, first as I said, this is database working group if you are looking for IPv6, it's that room over there. They need the nice wide room to handle it. We'd like to thank the scribe, the stenographer of course. We have sent the minutes for the previous database working group session RIPE 90 to the mailing list. We sent that in June and did a reminder last week; we received no comments, so it seems like the minutes are perfect as they always are. And opening up the floor to any last second comments or corrections?
And I see nobody going for the microphone, any comments online. No, right, then I declare the minutes for the RIPE 90 session to be final and we will get that updated on the website soon.
Geilter has done a lot of work in cleaning up the action list and minutes archives and I want to give thanks for that and we will be talking about that also during his presentation, because it's such a big task and such an important task for the working group that we also wanted to give it a how the south here in the opening.
And with that, I will hand over to David to go over the NWIs.
DAVID TATLISU: Hi everybody. Today this is going to be a short NWI update, most of the text in the slides is exactly what I'm saying in person in case I am stuttering my way through this presentation and because maybe I am kind of hard to understand, this is just so you can see what I have said.
Beginning with NWI‑2, the objectives were to lift arbitrary limitations in the retrieval of historical objects, so when the historical objects were implemented, Denis has implemented some at the time arbitrary limitations and NWI‑2 aims to remove them or reevaluate whether they are necessary.
Right now the history of recreated objects is not visible and this NWI would also make it possible to retrieve the history of an object even after it has been deleted, if you created an I net numb object, delete it, recreate it, you will be able to see the original object.
Since RIPE 69, when it was first declared, there has been little to no discussion; and going through 11 years of email threads, I didn't really find a lot of concrete information leading me to believe that there is not much interest in this NWI.
I would suggest we close this NWI after 11 years. And in case people would like to reevaluate the specific use case or interest comes up again, we can always just reopen it or create a new one.
During this presentation, I have two more of these, your thoughts slides, in case you have something to say, please come up to the microphones.
NIALL O'REILLY: Still RIPE Vice Chair, not for much longer. I suggest we all applaud this last proposal and get a clear sense of how sensible it is.
DAVID TATLISU: NWI 17 was created from the database task force specifically action 4.1, it was important to have on the RIPE database for law enforcement agencies, LAEs or for research purposes. This data needs to be treated carefully, it might contain, PII, personal identifiable information, and the database task force recommendation talks about limiting access to research and specifying criteria for researchers to access for data.
Now I have gone through all of the email threads I could find about this NWI and I couldn't find anybody talking about this specific where it says RIPE NCC grants access to researchers who need it according a specific criteria, I'd like to suggest three action points as nobody discussed my criteria.
Now, looking at the discussion, people ‑‑ some people are in favour of just closing the NWI, but there's some concern as the database task force recommendations are founded on something, and just closing the NWIs without action doesn't really help realise the purpose of the database task force.
The other people who are in favour of keeping the NWI open to evaluate GDPR compliance or the privacy compliance of the objects in the RIPE database haven't really talked about the rest of the NWI, so my action points would be one of three.
We could create another email thread to start fresh after this discussion has been lying around for quite a long time. But I'd like to say that we impact analysis that was published on this NWI clearly states that the RIPE NCC is a data controller so the RIPE community is not responsible for GDPR compliance or anything else. In this case RIPE NCC is responsible for ensuring the data is GDPR compliant and everything is within the legal means. We don't have the capacity for this, we don't have the legal team, so the RIPE NCC's legal department and, for example Maria, who has done impact analysis on this, are the experts.
I would alternatively suggest we continue with this NWI but drop the criteria to find research, drop the criteria to find research access criteria, as there has been little to no interest or close the NWI and state the NCC is responsible for realising this data protection compliance.
Does anybody have any thoughts on? Is there anything online? OK. NWI, yes.
NIALL O'REILLY: A quick question. Since nobody has any thoughts, do you have a recommendation among those three options?
DAVID TATLISU: I would personally go ahead and recommend closing the NWI since even after several attempts to heat it up again, there has been little to no interest from the community and the current situation points to it being a better NWI being closed.
NWI‑20 is an unused NWI and it concerns adding additional modes of, methods of contact to RIPE database objects and fixings an inconsistency between person and role objects, right now it's possible for person object to be created with just a phone number and a role object to be created with just an email address, this inconsistency came from the original draft now 30 years ago where it wasn't really expected for every person who have an email address but everybody had a phone number. We'd like to fix that inconsistency and maybe only make email addresses a requirement leaving out phone numbers.
We'd also like to add a new attribute to these objects allowing a URI for alternative modes of messaging, so if the splat user group came along and came together, different splat users could find their contacts in the RIPE database and use their preferred mode of communication.
Now, there's been a lot of lively discussion about this NWI, about 40 different emails in just a few weeks. Retroactively enforcing the email address and person objects, would require changing about a million person objects, and you probably also run your infrastructure, you have objects in the RIPE database and many people just create person objects and leave them be for years, and getting people to move, if you tell them to move, is kind of difficult so the chances of everybody jumping up and updating a million person objects is very slim.
There's also been some concern about this having to go through RIPE policy development process, as this a
Is an NWI, it's kind of the fast track of the policy development process. But all of this has been rectified. There's a few new things, I just want to talk about specifically we don't have to add email addresses for every person object on this, we can simply update the template and who who doesn't want to add their email address yet can leave their object as it is. In the future, email would become mandatory and this way we could have a gradual roll out or leave of the people who don't want to supply an email address, leave them be.
And there's also been a comment from the RIPE policy office and this NWI does not affect RIPE policy, so we can continue as we did.
Now, of course, this has several benefits; calling somebody on the phone or sending them a letter is becoming less and less common. So being able to, for example, message operators using Teams, Splat, Signal or whatever, is a huge benefit just to make people, just to make the communication between people easier and the amount of personally identifiable information is actually reduced. So people can now, because we need to supply both phone numbers and address, instead of email address, with the implementation of this NWI and those requirements falling, going away, it will allow users to remove their personal address and phone number from the database which is significantly more personally identifiable than an email address which can be completely anonymous. So I would say this is a big benefit for the privacy of the persons in the RIPE database.
And if you have any thoughts, please come up to the mic.
LEO VEGODA: Hi, I'm Leo Vegoda and I am one of the three people who put together the proposal for NWI‑20. I would actually reverse the order of the bullet points in your first slide. The driver for this was not to align the requirements for person and role object. The driver for this was that all the contact methods had not been updated, no new contact methods had been added for more than 20 years, and the social use of contact methods has changed significantly and so we as the proposers wanted to add the contact methods that people want to be contacted by.
And so number two, which is the adding of contact methods, adding support for contact methods like signal in the RIPE database that was the driver because if someone wants to be contacted in a particular method, they are more likely to respond to you. Now, I personally don't have a particular objection to aligning the requirements and saying, hey, the minimum standard is email; that said, in my work on PeeringDB, I have had people come to me and say, hey, we don't have email, like we have an email address, we will only open the email client to send an email, it is not integrated into our system, we don't use it.
So while I have no objection to the aligning of personal and role objects, I think it's about as reasonable ‑‑ it's fine, I don't think it's actually going to do anything useful because people who want to be contacted will give you the contact method that they want to be contacted by. If someone doesn't want to be contacted by email, they won't use an email address in the RIPE database. So I would personally go and say if you are only going to do part of this, do the adding support for new contact methods bit. And I appreciate the theoretical alignment of person and role object requirements and saying we need to have one method that is universal, but there is no universal method. And if you force people to use an email address, they will go and create one, validate it if they need to and never look at it again.
And I don't think it's a terrible thing but I don't think it's particularly useful. So that's my comment on this. Essentially we are dealing with people. I know this is a database in the middle but if the people don't want to be contacted by a particular contact method, it's not useful, and we just wanted to add new ways of letting people indicate how they wanted to be contacted.
DAVID TATLISU: Yes, the reason I formatted it this way was to have a consistent train of thought, so I wouldn't go to talk ‑‑ I wouldn't talk about the attribute when insert the inconsistency between person and role and then go back to talk about the attributes. This wasn't because ‑‑ I think the main purpose of this NWI is alying the person and role objects is kind of a side thing, of course this is the contact attributes.
LEO VEGODA: OK. Thank you:
NIALL O'REILLY: You mentioned, I think you used the words that the NWI was sometimes seen as a PDP light or some such phrase.
DAVID TATLISU: I know it isn't, this was just a very short ‑‑
NIALL O'REILLY: It's a short and convenient way of putting it, but I think there are a number of people in our community who think of it in such a way and regard it even, regard the NWI process as a means of evading proper policy foundation for what might be done. Personally, and I say this from a perspective of more than five years ago when I didn't have this role, and I think it was the same perspective next week and afterwards when I don't have the role again of RIPE vice here, engineering of changes, introduction of new changes, especially if the policy officer tells me they don't extend outside the current policy envelope is just business as usual.
Now, that said, there's the possibility of NWI creep outside the policy envelope and that is something we have to guard against. And there is sort of working group chairs, members of working groups, member of the community generally need to bear in mind that scepticism about assurances from the RIPE NCC, not just we don't trust them but because we should always have not quite a zero trust approach but a trust and verify approach. If the NCC is telling us this change doesn't affect RIPE policy, nothing that we do to support the policy will be changed by this implementation, then at least we should ask ourselves does this make sense and if it does, great. And if it raises questions, then there's a debate to be had, but we needn't get into having a debate every time somebody moves a dot or a comma about whether we need to put this through the PDP, there's a common sense to be put here. And if we remember, common sense was always something that Rob Blokzijl came back to, let's be sensible.
DAVID TATLISU: Thank you, Niall.
Is there anything online, Peter?
PETER HESSLER: No.
DAVID TATLISU: Right. Next up is Ed with his operational update and thank you for your time.
(APPLAUSE.)
ED SHRYANE: OK, good morning everyone and thank you for the introduction and my name is Ed Shryane, I work for the NCC as a product opener, this is the operational update. This is our team. So their work has gone into the update and I am presenting on their behalf.
So progress since the last RIPE meeting.
We have had three who is releases. One in July and weed added the new prefix attribute to INETNUM that was proposed at RIPE 90, it was very straightforward, we added it, it's now in use.
LIR partitioned PA, we continued the work on aligning the database model, the database objects with policy. One inconsistency we found was that LIR participation PA was allowed under allocated unspecified; it made no sense. We have now fixed that.
We have created an internal tool to allow the registry team to audit the INETNUM and Inet(6)num trees to identify any statuses and be able to contact users and ask them to resolve it, they have the ability to see all of the prefixes that are affected. Hopefully that's a help in cleaning up the status data in the database.
Next do not apply accounting for authenticated maintainers own objects, something I mentioned at the last RIPE meeting, it makes sense although the vast majority of queries are unauthenticated, this is a way for you to comply with the daily limit by identifying yourself, you shouldn't be accounted for your own data.
We implemented administrative status on RDAP look up to standardise RDAP, administrative status is meant for in region objects but are not allocated
A.
So, for example, this is reserve space in region, now we will return this administrative status, it's not the place holder objects that are in the database, it's a new type, it's cross RIR and it's defined in the RDAP spec. It's not yet in RIR search, we implementing the RIR search spec bit by bit but this is one step towards that.
We had some issues, our users had issues earlier this year with updating, creating and updating domain objects, this was due to our zone master set up; we now will wait for a maximum of ten minutes, Whois was waiting for five minutes but zone master allowed the test to run for ten minutes so it makes sense to align there. We also return a more user friendly error if it does time out. The vast majority of domain object creations an update are well within that, complete within a minute or two but there's special cases where a name server may not be responsive for the main object has a lot of name servers, it would take more time to validate and it makes sense to wait longer for that to happen.
So hopefully it seems to have a reduced a number of errors. I have looked in the logs since the last RIPE meeting, these changes seem to have helped.
We are going ‑‑ we are now running the authoritative resources task every hour, the list of in region resources from each region, we previously were only updating them once a day at midnight but different regions publish their resources at different types of the day, we are picking those up more quickly, especially for inter RIR transfers, we will pick up changes more quickly, you are going to see the correct resource in the region more quickly, both in and out of region.
Second Whois update was in August. So we made a major upgrade in 118 to our web framework. That included changes to the faults, one of those defaults was to make path separators, the encoding of path separators legacy and it was dropped; that caused an issue for some of our users, unfortunately. Apologies for that, the intention was to prevent malicious queries to bypass filtering or security checks by encoding path separators.
But it doesn't affect Whois. We don't present a file system. So the legacy behaviour is fine for us and it helps our users, so it made no sense for us to deprecate that.
So it's now supported, again.
Final release was in September; we are now supporting multiple maintainers for API keys and also 0Auth 2 access tokens, when you create an API key, if you have more than one maintainer, you can use the same API key across multiple maintainers, it might help some users. Always add a warning when add using password authentification, it's being deprecated, it will be dropped at the end of this year, so we have added a message to all of the Whois updates in case you don't know already, we are going to put a warning in there to nag you to let you know it is going away and you need to do something about it.
And finally there was a question on the mailing list about support for for e164 ENUM, the zone, we currently don't support that in RDAP, it's not part of the spec. But we are investigating that but in the meantime we are returning a more meaningful error, saying 501 not implemented.
We made some improvements to the when application. One thing that came up recently on the list was to make a query very easy for users, make it very obvious what they are querying for, what's in the response, one small change was to highlight on each attribute in the query response what the attribute means. So casual user may not be aware of the details so we are putting in the short text from Whois into each of the attributes so you can hover over that attribute key and key what it is.
There's further improvements in the pipeline but we thought that was a small incremental improvement that we could make.
Next up was to support pasting in keys when creating a key cert object, this is a longstanding improvement we wanted to make but in light of deprecating... in a very easy way to the database.
So now you can click on this little icon on the create page, creates a pop up, you paste in your key and click OK and it will separate each line into separate lines, it makes it super easy to create a key cert object.
Next up up was add a banner on the query page to get the word out are passwords are deprecated, passwords one change, we need to remove passwords from all of our environments and we have started doing that in our test environments, hard coded passwords in NCC maintainers need to go away.
So we are now ‑‑ we have removed, well, we have removed passwords from the front‑end in our test environments; what it means is you can go to update an object, you will get a pop up, you no longer need to type in the hard‑oded password, you will just need to select which maintainer you want to authenticate as, and from then on you are part of that maintainers attributes, you're logged in account is automatically added to it and you can make changes to test data for testing.
So you can do useful things like create a new allocation, create a new LIR, make fundamental changes for testing to reproduce your production environment in a safe way in test, without needing passwords.
And yeah, finally as I said, we have added support to the front‑end as well to allow multiple maintainers when creating an API key.
Whois outages. Normally this is my most interesting slide where I explain where everything went wrong and how we tried to fix it but this time I have nothing to say, there were no major outages thankfully of the Whois database between the last RIPE meeting and now, thankfully. Now I am sure I have just jinxed myself, we are due a major outage any time soon, hopefully not, I will come back to you the next RIPE meeting with more news on that.
We have updated the terms and conditions, changes to the terms and conditions were adopted at the last executive board meeting in September and these are in response to the digital operational operational resisilience act act, DORA, which came into effect at the beginning of this year. While the requirements apply to financial institutions, we are in the supply chain, the NCC, of our members who fall under DORA so we have made specific changes adding details of how we manage d and maintenance and how incidents can be reported, we have added information about security measures and audits and subcontractor service level and data protection information, it's clarifying existing data on the website already, adding them to the terms and conditions.
Our legal team notified the working group already and because our database documentation is OpenSource, the DIFF is visible, you can see exactly which terms have changed in that document. The action list has been updated and archived, the working group chairs proposed to archive the AS list in May, there was a reorganisation of the NCC website, all of the active working groups moved to in new home, there was some legacy pages left behind at the old location. One of those pages is the action list. This was historically the way to track, to do items within the working group. Now they have moved to the minutes themselves, action items will show up in the minutes, for the NCC we track those internally as well so the action list, there was no longer updated, it was considered legacy itself.
So it was archived but Piotr did a whole lot of work since the last RIPE meeting, thanks to him, he reviewed the page content and filled in a lot of gaps, including recordings, minutes, presentations, it was a lot of work. He sent us a spreadsheet with the list of all the updates to the NCC, our COMS team applied those and now the page is marked archive in the old location.
And secondly, the minutes page is also we are updating that, Piotr went through all the minutes for all of the meetings on the website, truly a lot of work. There was a redirect from the old location already in place so it goes to the new location and previous minutes are archived. So those corrections are in progress and expect that to be resolved soon.
And thirdly Piotr also made a suggestion to move the numbered work item page under the new location on the website. I think that makes sense. If there's an argument against it, please let me know; otherwise, we will make a permanent redirect from the old location under the new active working group page on the website.
A bunch of statistics, these are recent changes we have made to Whois, it may be of interest. NWI 4 first of all, allocated a signed PA allows you to register a single assignment, the same size as your allocation, particularly useful for the smaller allocations, /24 allocations. This is for Inetnum. We now have gone over a thousand of these, so there's almost 1500, 57% more than the last RIPE meeting, it's very encouraging, it's a useful feature and clearly people are using it.
Secondly we have the same number of Abuse‑C addresses as last year, we are at about 17% remaining for this year, we seem to be on track, thanks to our registry team for helping us with that. So we have an automated process where most of those Abuse‑C addresses are taken care of and validate automatically but the minority that are not, we will open tickets and the registry team will follow up with the organisation to resolve that.
Thirdly, we have a mechanism to synchronise your portal users to the ‑‑ to the default maintainer, they are only maintained in one place and the portal users can make changes on behalf of the organisation in the database, adoption is increasing, it's gone up slightly but only 10% of organisations are making use of that.
The non‑auth database, that was up for discussion also since the last RIPE meeting, it's gone slightly down since the last RIPE meeting. We have lost 2% of objects in there. That's a combination of users themselves deleting objects and the clean up jobs we already have in place taking care of objects that are no longer useful in different ways in that database so clean ups are continuing, the size of the database continues to shrink but very lowly.
Next it's a status that already exits in IPv6 but it's now being added to IPv4 to Inetnum objects, the number is quite small, now it's over 200 and net numbs are using that feature, this is useful where you have a number of assignments with the same content and same contact details, there's no longer any need to create multiple assignments in that case, you create one aggregation, it makes it easier for your users to find it and easier to maintain, you have a single object.
And as I said, it reduces the LIR efforts in registration and maintenance while still complying with policy to register your assignments.
There are now over 8,000 undeliverable email addresses, that's jumped up quite a bit since the last RIPE meeting. These are email addresses that we have tried to contact them mostly through Whois update notifications but we have had a permanent error in response from the mail server. Normally, this is you must stop, you don't continue trying to contact them for our own reputation as an organisation, we don't want to get blocked by mail providers, in sending mail.
So that number has gone up a little bit despite our efforts to reduce the number of objects, addresses in there but we are going to continue to make efforts to reduce that number because we really depend on email to contact our users, not just for Whois update notifications, especially if there's been an update which you are not aware of, it's a useful mechanism to know that something has changed. And also we have got various automated mechanisms where we need to contact an organisation or a maintainer or a user for different things. We depend on those email addresses being correct and users being reachable. So we are going to continue with efforts to improve that.
All right. That's our work since the last RIPE meeting. Work in progress. So first up obviously the big thing for us is to deprecate MD5 hashed passwords. This is work ongoing since last year. We have had a lot of work on the mailing mailing list. MD5 is a security risk for all of our users as well as the NCC. If there was a data breach or data leak or for some reason the password hashes are in your maintainer and in the database, if they are ever leaked, it's it's very easy to reverse those hashes or they show up in dumps of where else. Where if you're reusing your password, it it may show up in a public dump somewhere, there's various ways where your password could be identified and your data could be maliciously changed. We think it's very important to deal with that.
So the plan is to drop support for passwords completely by the end of 2025. Since the last RIPE meeting, we knew that there were passwords in about 20,000 maintainers in total. But the vast majority of that data, the vast majority of passwords have not been used, they are not being used regularly. About 18,000 maintainers contain passwords that had not been used since the beginning of 2024, we thought that was a good first step, a safe place to start, we are not going to, it's unlikely we are going to break people's functionality the way they update their database, so in stages we removed inactive passwords, we notified the working group and notified the maintainers beforehand, before removing those. Now we are ‑‑ and we had a lot of help from the registry team as well. There was a follow‑up, a lot of people were asking questions. We contacted so many people. Not everybody follows the database working group, the list. It was the first time a lot of people had heard about this so it was a very useful exercise. In getting the word out that passwords are going away.
But so we got some useful feedback. And now at this stage, yeah, we are now at the point where we need to do something about the remaining maintainers. So we were at about 20,000, now we are at 1500 in ‑‑ that still have passwords that we consider active, that were used at some point since the beginning of 2024.
So we have emailed the remaining maintainers, we have done that repeatedly in July, September and October. We also contacted the LIRs where the LIRs were depending on a password with a maintainer, we contacted the LIRs directly as well because we are going to try and do as much as we can to inform our community that passwords are going away. And there is an operational risk to any organisations that are continuing to use passwords; they really need to start moving to an alternative, one of the number of alternatives that are there by the end of this year.
One thing that we added was support for Oauth 2, my colleague Adonis has an article on the RIPE Labs website, it explains the details there. They say you can go to the LIR portal and apply for an access token and use an Oauth access token in your application to make changes in the RIPE database on behalf of your users.
We also added a warning in the update response, wherever passwords are used so this is, yes, it seems like a common sense improvement to get the word out about passwords and outcomes, a lot of users did not know that passwords are deprecated, very useful feedback, we need to make an effort to inform our community. And the email template is very important, we know that sending out an email that may not get ‑‑ we need to get people's attention and put the right information into the email; it needs to be self‑contained. Reduce the load on our registry team with questions that we could just answer in the email. So we had some help from our COMS team in doing that and also feedback from the community to make the subsequent communications a little bit clearer so we are striving for clarity if they need to do something, what is it they need to do and when do they need to do it by.
All right. Some statistics since the last RIPE meeting, where are we now in October 2025. I looked at all of the authentification types and how much they are being used and surprise surprise, pass records are still there, near the top of the list, not quite but nearly a third of all of our updates are still being done using passwords. It has gone down slightly, it's encouraging but only by 4% since April.
Now digging into that, it's only about 150 maintainers are accounting for all of this update traffic, 32% of all of our updates are being done by a hard‑core of 150 maintainers.
And in particular, the top two are accounting for 50% of that. So on the one hand the numbers have not really gone down significantly. In other words, we only need to movement from a small number of maintainers in order to get this over the line by the end of the year.
So I would just reiterate that time is running out and we need to encourage our maintainers to move to to an alternative.
Next step, we'll continue to send email reminders to the small group of maintainers still using passwords, we are going to monitor continued use of passwords, we expect to to to decrease in that, if we don't see it quickly enough we are going to have to consider next steps. We are obviously going to support any users who need assistance, please let us know through our contact form or ripedbm@ripe.net, send us an email and we will support you from moving from passwords, the registry team are well aware of the alternatives and can help you with that. We are preparing internal application details, we need to remove reference to say passwords and any support for them internally and as usual we are going to announce to the working group as well for taking any action so watch this space, we will continue to discuss this with you between now and the end of the year.
And in summary. I thought NetHack was a useful presentation here since it's about the same age as Whois. So yeah. We have to bid fair well to MD5 password, it's been around since 2002 and it's going to join its friends, none, mail from and crypt PW in the authentification graveyard
A.
All right, moving on, NWI‑20 was already discussed earlier in the session, I will just reiterate the problem statement from the proposals in May, the requirement method for contact levels is inconsistent and it's confusing an inconvenient. This is a proposal to add flexibility from the contact methods, it's not a proposal to change policy requirements for the contact methods. The link is there, there's a lively discussion on the list but it's gone quiet recently. The detail of the proposal from May, one is align the contact methods between person and role objects using admin‑c and tech‑c, the second is add support for the mew cpmtact, etjpds om tje RIPE database; Third ismakes sense an as a consequence and fourth, one thing that came up during the discussion was multiple people feel that email is important and that it should be a mandatory attribute.
So that seems to make sense to add that to the proposal as well.
I went back to the early 90s on the list to see why email optional on person and not on role, I couldn't find any real reason for it, if anyone knows the context, I would be delighted to hear about it. But all the way back into the 1990s the person email was optional, first the RFC, the original RFC 2622 email was mandatory there, I don't tell why there's a mismatch but whatever reason in the mists of time, email was seen as optional, there was already an effort in 2003 on the list to make email mandatory on person to align with role, the reasoning was that maybe in the past the personal email addresses weren't as common and we shouldn't be insisting on it but at the time in 2003 it was felt time has passed, time has come to make it mandatory because it's easier to get an email address, but for whatever reason the discussion fizzled out, there was no change at the time. So this is an opportunity to change that.
OK. So discussion was ongoing on the list but I have a draft solution definition from the requirements that were raised on list so far. So just to put that into context to translate that /OT object model, the proposal implies that email address will now become mandatory on person, it's already man tree on role objects.
The address attribute becomes optional on person and role, the phone attribute becomes option on person and I propose to add a new attribute called contact as an attribute type on person, role organisation and IR T and it should contain a URI value so the messaging applications that were mentioned in the proposal, a URI will fit for all of those, WhatsApp, Telecom, Signal, etc, you can encode your contact information as a URI, it seems to make senses as the value.
So I will wait to hear the discussion on the proposal to conclude. We have a draft solution definition and an impact analysis. I feel I shouldn't preempt the discussion by publishing that yet. But once the discussion has come to a close, I am ready to share that with the list, for further discussion, it's not written in stone so I welcome your feedback when the time comes.
OK, next up, cleaning up the RIPE non‑auth database.
So the RIPE non‑auth database was created in 2018 as a way of separating non‑authoritative data out of the authoritative data that's in the RIPE database, so it is mostly route 6 objects for outer region space, the data was created with a hard code, password in a well known maintainer. And we have been trying to get rid of it ever since. We started out with 64,000 objects in there, we are down to about 47,000 now. So we are depending on the community to clean up their objects, to delete their objects, that's happening very slowly. Additionally we have existing clean ups. Where the prefixes are route 6 prefix is using unregistered space, it seems to make no sense, we have an automated clean up to notify the maintainer and delete those objects. Secondly we have an existing clean‑up job where a non‑auth objects conflicts with an RPKI ROA, we notify the resource holder and eventually delete those objects. So both of those clean‑ups have been effective, but in total they are only dealing with a small amount of space every year.
So we are talking about hundreds, maybe a couple of thousand objects a year. So the bulk of objects remain there. At the last RIPE meeting I proposed we get rid of the non‑auth database already which would be a pretty radical step, the ARIN region it's already happened but there were really good comments at the last RIPE meeting, we don't know how the data is being used, so we should progress a little bit more carefully, slowly, and I proposed there was ‑‑ from discussion on the list, it seemed to resolve around two proposals, one is to delete NONAUTH objects with a matching valid ROA which would impact about 16,000 objects. And secondly to delete NONAUTH objects with a matching object in another RIR database. If there's a matching, a duplicate, effectively, in the authoritative database, there seems to be no reason to keep the duplicate around in the NONAUTH database. And that impacts potentially most of the NONAUTH database, it's 27,000 objects and obviously there's some overlap between those two clean‑ups, you are matching the same objects a lot of the time.
There was a good point made on the list that we should notify because we don't know how the objects are being used, we need to notify the maintainers beforehand, say there's a proposal, we don't know how these objects are being used and we ask for feedback. And we sent just over 2,000 emails to all of the maintainers for all of those objects potentially impacted.
We received 33 replies, there was a variety of responses, I have posted them all to the list. 23 of those asked us not to delete their objects. 10 of them we discussed with them now they were using their objects. And we helped them create an alternative in the authoritative database so they no longer needed object in the NONAUTH database but going one by one through this database an contacting maintainers and doing it with support, it's going to be a lot of work. So it seems not feasible either for the maintainers or for us to keep that up. With you we got some useful feedback. I now propose the NCC proceeds with both clean‑ups using a new number at work item, but that's for the group working group to decide and I will suggest it goes back to the list for discussion.
Next up is to support e164 in RDAP. What is e164? It's a DNS reverse zone, it's been around for a very long time; it's a mechanism for users to map between a telephone number and the internet. Using it maps a telephone number to a URI through the DNS so for a long time we have hosted these reverse domain objects in the e164.ARRPA zones, we get tens to hundreds of queries for these objects every day but there was a question on the mailing list why are we not supporting these objects through RDAP and the short answer was it never came up in discussion during the protocol design. These objects only exist in the RIPE database, the NCC were selected as the operators of this zone, they don't exist in any of the other RIR database, there are a couple of hundred objects and there's tense to hundreds ever queries for these queries every day, we already support the main objects in the RIPE database so it would not be a lot of work to support these also. But it would need a draft document and an implementation to do that.
So we are planning to raise this with the ITU since the ITU are the, they are responsible for the ENUM standard, we are going to raise it early next year and we will find out what they want to do, both with the ENUM zone and also RDAP support in particular.
So if we get an affirmative response, we are happy to create a draft RFC and implement support for it but for now we are turning......
This is a proposal that's been going on for a long time on the list, I saw references back to 2011. Specifically this proposal is to support UTF‑8 in the description and remarks attributes. It was proposed at the RIPE 89 and RIPE 90 meetings and it turns out in 2015 our colleague Piotr from the community suggested exactly the same thing. Sop that we should support multi‑language, the UTF‑8 standard in description and remarks attributes. We are in an an enormously diverse region, something like 78 or 80 countries in our region, the majority of those don't use the Latin script for their language. It makes sense to start supporting those, that community in the RIPE database also. With regard to interoperability also, it remains so we published a problem statement and impact analysis for discussion and it was really encouraging the response yesterday to see the support for it so it seems really encouraging, there's a lot of positive support for it in the community.
So the question is now should we move to implementation, in the same way I am proposing we have a numbered work item to track the progress and make the implementation but I will send it, I will send that question back to the list.
NWI‑12 and NRTMv4 mirroring, this is going on for a while. There's a draft RFC document, we have five different implementations which is really great. We worked on implementation report for the IETF, that's now complete, it's in review in the IETF, we have answered questions over the summer on it, we have decided not to ask for it to be marked finished yet until RFC document is more final. Support for that standard is coming in the upcoming IRRD software, it's now in Beta.
And finally as I said, we are completely feature complete, we have both a server and client implementation in our own code. If you are interested in using it, you can use it on the client side. Also.
And future work, there is a yearly key role over we have already done two of those but the next one is due up next March.
RDAP. RDAP is a very important cross‑community cross‑RIR protocol, a modern alternative to using Whois and work in progress, the transparency report, there was a question last year where are the gaps between RDAP and Whois, the biggest gap is we don't support IRR object types in RDAP, we are working to correct that and we are writing a draft document to define how IRR data should be returned in RDAP so work on that is progressing.
Planned work, I have said already we supported administrative status with RDAP queries, now we are going to support in RIR search, we are also going to support the feature in RIR search reverse search, and then we can consider ourselves completely compliant with that RFC, they are the two remaining parts. And RDAP paging an sorting seems like a useful improvement. We already have paging an sorting in our Whois search rest API, it makes sense to also support that in RDAP because some of the responses, especially the queries, you can end up with a huge response.
It was already mentioned at the RIPE meeting, it came up in the Services Working Group Ged and at the general meeting, the draft plan was published in September, please read the document and share any feedback. Your feedback will be taken into account and a final version of the activity plan is due to be approved by the executive board and published in December.
For the RIPE database specifically, a couple of points out of that action, the activity plan.
The budget for the team is unchanged from this year ‑‑ for next year.
The strategic goal for next year is to ensure that the registry and RIPE database are the appropriate level of accuracy, compliance, resilience and security and in particular in 2026. We commit to these activities, we will work on improving the security or authentification methods like dropping MD5, like improving the alternatives. Improving the resilience of our on promise environment so we are not moving to the cloud, we have no plans to. On the other hand, that means that our on premise environment, we need to spend more effort on improving that, improving resiliency in particular so we'll continue the work there, we'll work the IETF community in implementing standards, that means RDAP, there is an audit coming up in the coming months, we are making preparations for the ISO‑27001 compliance, we have a risk matrix, we are working on controls, we are working with our colleagues in the software engineering and across the company on defining standards. So we comply with this standard.
All right, I have said enough. Questions and comments, thank you.
(APPLAUSE.)
PETER HESSLER: Speaking for myself right now, I want to mention that first for MD5 updates, we at our day job do use MD5 because we use a third party application to update our objects in the database. And that only has the support of MD5 in the region. I have been harassing them to update but there's nothing yet, all of our humans who touch the database do use the SSL method so we have done as much as we can in preparation for this while still depending on a third party.
The other thing I want to mention is for the NONAUTH database, we did create an object that was originally allocated in another RIR because it was easier to update that object within the RIPE database, since then the other RIR has made it relatively straightforward for us to update the object so that one is the more preferred one and I don't think we replied to your email but we are ready for you to delete it whenever you are happy.
ED SHRYANE: Thank you, just for the MD5, I hope you received our emails that we have reached out.
PETER HESSLER: Yeah. I received I can remember at least two of them. I am positive I received all of them. But yeah, we are stuck waiting on somebody else to do work and we can only tell them to do so much because their priorities are not our priorities.
ED SHRYANE: Many of the other maintainers are in the same situation, it's something we need to discuss together before the end of the year, since we raised that deadline, we need to meet it, what are we going to do it.
PETER HESSLER: I don't want to name and shame, I am thinking about it but not yet. Shrine the replies we did get echo what you said on NONAUTH, it's easier to update an object, also they have said that it's become useful, more easier so other users of NONAUTH have also removed their objects so I think over time, yeah, that's a good alternative. Thank you.
STAVROS KONSTANTARAS: Stavros with AmSix hat, thank you for the presentation, it was very useful, I would like to say I fully supported the commissioning of NONAUTH database and I would recommend do not remove it from the action plan but keep it there, we have ditched RIPE NONAUTH database from our operations a few years ago, we don't use RIPE NONAUTH to configure route server filters any more and we didn't have any impact or complaints. The only impact we saw was the AS 112 which is the ASN number of the DNS router server, however the guys from the DNS Org, I was in contact with them, they are moving to the official RIR. And they are going to put their objects there and they are going to sign with RPKI by mid November so this problem will be fixed very soon. Other than that, I don't see any meaningful reason to keep RIPE NONAUTH in our ecosystem and those objects can be safely moved top A the RIPE database or AfriNIC because I guess quite some of them should belong there and after that we should proceed with the clean up because the less we have of those database the better for the ecosystem. Thank you. If you want we can discuss it more, if you want more information or data from my side, I'm happy to share.
ED SHRYANE: Thank you for the information and I would be happy to hear from other operators who may depend on NONAUTH, I'd like to know why and are there ways for us to work together to end the dependency on NONAUTH and maybe we can move away.
SPEAKER: I think it's just legacy that people forget it exists, if it works, it works, I don't care.
ED SHRYANE: Because these two proposed clean‑ups touch so many objects in NONAUTH, it's important not to affect people operationally, we need to be careful.
SPEAKER: You cannot succeed 100% but if people do not wake up, then somehow they have to wake up to start fixing things.
ED SHRYANE: It's something we'll take into account in any proposal to do any clean up. Thank you.
PETER HESSLER: Speaking on behalf of the working group as co‑chair ‑‑ actually thank you Stavros for mentioning the AS 112 problem. Is there a way that this team can look at the NONAUTH database and find all of the objects that are ‑‑ that were created under IANA or ICANN action? That's a special reserved ASN and special reserved Inetnum and INET 6 numbs from them, that would be fantastic to look into and see if any of those objects exist in the NONAUTH database so we can, those maintainers are not necessarily maintainers, this was created by IANA action and the RFC process. So we would probably have to do special activities for those types of objects. This would be great for us to research and double check before updating.
ED SHRYANE: If we can identify which resources are affected, we can go and have a look, we don't know who created any of those objects or Whois maintaining them but we can definitely go and look and match any prefixes.
PETER HESSLER: In the IANA registration documentation, they have special use numbers and always of them have references to who created them.
ED SHRYANE: That's something we can share with with you, thank you.
NIALL O'REILLY: Speaking this time as somebody who is involved in the microenterprise tolerant networks limited and as a private citizen on the web. And especially someone who espouses the Larry Wall's virtue of laziness, to save me doing the homework, have you compiled a nice list of top three RDAP clients.
ED SHRYANE: It's completely down to the user agent in the request but it doeses HTTP so we can do, we can look at the user agent string and see Whois using RDAP but overall the use of RDAP, it's in the minority for queries, it's less than 5%.
NIALL O'REILLY: If I want to stop using Whois, I have got to have something convenient to me as Whois today.
ED SHRYANE: It's a cross require effort to fill in the gaps, we want to make RDAP as featureful as Whois is already, but Whois had a massive head start, there's at least 30 years of history there.
NIALL O'REILLY: The look upside is ‑‑ we see this with DNS SEC validation, it's always on the information consumption side that delays are.
ED SHRYANE: OK but overwhelmingly for now, the query rate is completely, it's port 43 still, more than 90% of all traffic is port 43, we have some way to go.
NIALL O'REILLY: I am prepared to do my bit.
ED SHRYANE: Thank you.
EMANUELE IOVINI: Hello, so I have some curiosity because I am starting to understand better how it works. You say that 8,000 emails didn't answer to you, so I was trying to rise the problem of contactability so are these people being contactable in some way and what are the consequences for not being able to be contacted by RIPE NCC.
ED SHRYANE: Great yes, overall there are over 900,000 email addresses in the database, it's an enormous amount of data, two million personal objects, 900,000 email addresses, so it's not, it's a difficult problem to try and tackle, to try and validate all of those mass of email addresses but we will, at the point where we need to contact somebody, that's where we will use that email address, it's mostly Whois update notifications, where an email address is referenced in on object, where an update is happening, we will try and contact those email addresses to notify them that a change is happened and that's the point where we'll see, we now process bounce responses so we will see where where there's bounce and where there's permanent failure we will mark that address undeliverable, we want to be good citizens and we don't want to continually send bad email bad requests to email providers, they will block us and consider us spammers. So we mark those addresses as undeliverable. So it's really important that we do contact ‑‑ users need to be contactable because a change may have been malicious and we need to let them know, inform them that something has happened, it may not be something intentional they wanted to happen, email is the main mechanism currently we use to contact our users.
EMANUELE IOVINI: You are making a draft for the next year like mandatory mail and other contactable attributes, you should focus on consequences if someone puts himself in dark and not being contactable in some way, I think 90.9% of the community should be able to be contacted because they are in good faith, there are so the some kind of people who will not do that, maybe this could be a potential vulnerability especially because we speak in public so someone knowing this would exploit this situation and use it to his own advantage. Also the problem of legacy resources, I could never know what is this resources, what I can do with this, sometimes because I have trainings in Europol, my colleagues ask me how do I know Whois behind the resources, what happens those are users for malicious intent so this is for my power just to force a bit of discussion, I don't know which is the solution but I will like to speak about this because being able could be contacted is very important.
ED SHRYANE: The first thing you mentioned the vast majority of the email addresses are user maintained, we have no control of that data or those objects, maybe it's is something for the community to discuss. We do have a mechanism for Abuse‑C but it's a RIPE policy, so we will validate all of the Abuse‑C. And there's an effort every year but we are talking about 84,000 email addresses, the bulk of them, 900,000, it's a different scale altogether, in order of magnitude more addresses work potentially, if we were ever to go invalidate all of them. But now it's the responsibility of the maintainer to make sure those addresses are Val valid and users are contactable. Most of those objects are contained in assignments and it's RIPE policy that is requiring operators to put, to register their assignments and the email addresses come from the contacts on the assignments, for legacy space, there's separate efforts on legacy space, I might talk to you separately on that.
EMANUELE IOVINI: Ow, thank you for your response.
LEO VEGODA: Hi, Leo Vegoda speaking for myself. In response to the email deliverability thing, this is something I have raised in the RIPE plenary, the community plenary previously and there's a lot of mail service providers who will go and accept receipt of an email but not pass it on to the end users and so when we talk about deliverability, it's not a binary, it's really complicated. And the fact that you have an email address in a database and it's working for some correspondents doesn't mean it works for everyone. So I mean, I really appreciate the problem. I don't know what the solution is. But that was one of the drivers for the NWI‑20 and the ‑‑ we want to be contacted by Signal or whatever because email is hard.
ED SHRYANE: Thank you. And maybe we as a community need to look at alternatives to email. We are very dependent on it in Whois, and that's what prompted the work on email deliverability, we want to make sure we can contact users to let them know when something has changed on the database. But operational reasons. Currently very important. We have seen those problems with the large mail providers, a huge amount of users on their own domains are behind sitting behind a large mail provider and it can be difficult indeed to contact those users or if there's a failure, the failure we get is often a non‑standard response, it's not according to an RFC, it's very difficult to parse the response and make sense of it. It's very specific to that provider. So supporting that is a lot of work. And also because we depend on email so so much, when it comes undeliverable, there's no way to contact the users to let them know it's undeliverable, but that number of 8,000.
One final point, just to say that out of the vast amount of 900,000, I am sure the true total is far higher, but this is only the number of emails we are trying to contact day to day. So I think if we went through 900,000, the total would be a lot higher. Thank you.
ANGELA DALL'ARRA: Angela Dall'arra, policy officer, RIPE NCC. I hope to offer a couple of clarifications, also to the comment from Emanuele. So first of all, regarding NWI‑20, I made a comment on the discussion to specify that changing business rules in the database in this case, does not affect the policies because what is in the policy is just speaking specifically for the IPv4 allocation and assignment policy is to have a contact. And this, how can I say, having a contact is actually mandatory by policy and having an email address that is the, how can I say, most easy to check and verify. Also in the discussion was looking like the best option as a mandatory contact. Adding an optional contact is not affecting the policy at all and as specified, we are not going to verify that and it's the choice of the user to insert which contact they want to use additionally.
Another consideration to make to make about this unreachable email adress, we work on an organisational level, so each... can have his own email address, but this is always hierarchically referred to the organisation, there is different kind of follow up depending on which email address is not deliverable.
And another thing I wanted to signal is that later on in the Address Policy working group, Marco is going to address some of these topics in his presentation, so I invite you to join the session later.
NIALL O'REILLY: I am not sure which hat I am wearing this time, but some thoughts about division of labour and hierarchy of contacts. In this working group and in Ed's, the group in the NCC that Ed leads, the concern is about a database and its engineering. In the registry work, in the registry team in the RIPE NCC whose help Ed acknowledged earlier a number of times, is the responsibility for knowing the customer, and this is what I think is more important for Emanuele's purposes and the purposes of his colleagues in the other law enforcement agencies.
And of course there's a cascade, a hierarchy of customer provider relationships. So the immediate customers of the RIPE NCC are the LIRs and those are the customers they have an obligation to know, but the more remote customers, they are somebody else's responsible and this cascade of responsibility is something that I know is understood in the law enforcement agency community because I had the chance to speak at a social event with one of our police people in Ireland, so it makes things much more complicated but it's not something that Ed can fix. So let's, again, let's recognise the partitions of responsibility. And it would be lovely if we all could solve our problems, you know, mine, Ed's, Emanuele's colleagues, with a one‑stop shop, but it never works like that.
ED SHRYANE: Yes, thank you, Niall.
EMANUELE IOVINI: My question is was this actually, because if things are only known at technical level, are they escalated up to be understood better than at our level, if I have a problem already to contact the technical contact, are there issues even at higher level that has to be escalated, then the police can ask and do all the steps to understand the cascade and reach of the end user but I have 8,000 emails I cannot reach, it's maybe it's a technical problem Ed is trying to fix but this Ed is collating this to see if there are other problems, other than just putting an email which is not correct, this was my IP tension, I understood really, because this is what it is, I know customer is another thing but the problem even if it starts at technical level, beyond the technical contact there is always a person. An organisation. So is the same with Abuse‑C, I know Abuse‑C is always every year you check it, it's working or not. But it doesn't mean I have any mail address which receives any mail. And then OK, I put an email, but I never check it and I never receive any actual communication, that's why I was speaking about contactability. It's not just something which works, it's just someone wants it, who is there, who receives it, actually the communication. So even if we put the mail mandatory attribute and other contacts, in the end what matters is I contact this entity or not, this is what matters, this is my opinion.
ED SHRYANE: Thank you Emanuele. Obviously yes, as Niall has said, there is an awareness at the organisational level. The RIPE NCC do know our customers and we do validate our data and have contact information for all of our members, as you go down the database, there are levels, there's a hierarchy and it can be a third‑party organisation can be responsible for data in an assignment, if the first stop if there's that can crass see, you need to contact the organisation and ask them to fix it. They have a responsibility to put accurate contact information in the database for their resources.
Also there's ‑‑ I mean, there's something that we are already working on that's in progress, a small change is highlight more obviously the difference between data that we know about that we validated that we are responsible for the NCC's maintaining in your query response, highlight that more accurately versus the data that's the responsibility of the third party. So I think that needs to be clearer so we are, that's work in progress I am doing with my colleagues and others in the company so it's more obvious on a query response who is responsible and who is responsible for the data you are later looking at. So yeah, thank you.
PETER HESSLER: Speaking as an internet user. I feel your pain. We already do have several contact methods that are mandatory in the database. Most famously Abuse‑C. And I have found Abuse‑C to be utterly worthless. I received network abuse from a network and a well‑known network of ‑‑ half the people in this room probably use this organisation's service. I was sent an Abuse‑C email and I would get a response from the email server saying access denied, go F U and this is a reteen response that I received, the NCC validates it on a regular basis, so somehow you get accepted and I get rejected. And this is probably very similar aspect, and that's even ignoring the fact that even if a human does receive the email, the human responds to the email, which is also very different problems. I don't know how we can, I don't think we can solve that in anyway, shame or form but deliverability would be half the battle.
ED SHRYANE: We are focused on, Abuse‑C validation means deliverable, if we can deliver the Abuse‑C message, then we are satisfied, validation is satisfied, what happens after that is out of our control but if there is a misbehaving organisation, please get in touch with the NCC and we'll see what we can do about it. Thank you.
PETER KOCH: Just sharing up the vision, it sounds a bit of confusion regarding the presence or not of manned try object in the database versus any expression or implied policy or legal obligation that would be connected to that and of course RIPE NCC cannot impose any legal obligations on anyone because they arise somewhere else and at the same time also the region internet registry might not be the case place to impose other obligations that have so much to do with the operation of the network rather than withholding and maintaining the resource and these instruments don't have to tell Mikayla about the evidence somehow, the instruments just originate elsewhere and we need to mitigate that conclusion more than dealing more with the technology that might increase the confusion overall.
ED SHRYANE: Thank you Peter.
PETER HESSLER: Now speaking as co‑chair. David and I had a quick discussion and the chairs would like to propose that, one, for NWI‑20 that you send your draft solution definition to the list. Your little bullet points look quite reasonable and we would like to see discussion. One thing I would like you to include is previously when we have changed an attribute from required to optional, there's been activity in the database and we just would like you to describe what your proposal would be for those. Because that is famously how I joined the working group.
Secondly for the UT. ..discussion, I think we should have, I think there should be a two week discussion period so end of next week. And then we can find a consensus and move on from there, so that way this process doesn't take another eleven years.
ED SHRYANE: Hopefully not. Thank you, Peter.
(APPLAUSE.)
PETER HESSLER: OK, that is the send end of our scheduled session, is there any other business that somebody would like to bring up to the working group? (Inaudible.)
Thank you for reminding me, there's an email about the changes to the NWI process on the lists, please send your comments, we'd like to hear feedback on this.
Are there any comments from online at AOB? No, great.
Then just before I close the session, a reminder to vote in the Programme Committee election by 17:00 local time today. Vote in the NRO election, vote by Friday at 9:00 am local time. You can chat with the NRO representatives from 13.30 to 14:00 during the lunch break at the Meet&Greet desk. If you are a member of the NCC, please vote in the general election meeting. And with that, I close the session for RIPE 91.
Thank you very much.
(APPLAUSE.)
(Coffee break)