Database Working Group
23rd May 2024
At 9 a.m.:
WILLIAM SYLVESTER: Glad to have everyone here this morning bright and early, before we get started I wanted to thank RIPE NCC for providing chat support. Maria, thank you. And Alain is going to be our scribe today, so thank you.
Be sure to fill out any of your surveys, that's very helpful for all of us and very useful.
With that, we have an exciting agenda today. We have our usual operational update. We have our presentation on Whois and RDAP. We have our typical NWI review. And then we have our Chair selection process as well.
So, with that, David, do you want to come up and address everyone on our Chair selection
DAVID TATLISU: Hi, everyone. As you know we have made some changes to the recent Chair selection process, the reason being we wanted to allow RIPE policy eventually leading to all Working Groups having the same process with a call for volunteers being published on the mailing list at the same time and the eventual elections taking place at the RIPE meeting. This has caused a bit of internal discussion, so the call for volunteers for was missed. After the list of volunteers was published, William to the other Chairs and this kind of started a large discussion.
So, what William wants to do or what which will Jan has offered, is that he continues in Denis's spot after Denis has recently retired from being a Working Group Chair and serves a one‑year term to keep consistency in the Working Group and allow us to keep the one‑year Chair rotation but this is bypassing the process, so I just wanted to ask the room if anyone is opposed to William putting himself up as a candidate after the list of volunteers has been published or has any other concerns?
AUDIENCE SPEAKER: Mirjam Kuhne, one question, I think you might have said but I missed it, I think you said for the remainder of Denis's term, like what another year to the term that we have basically left ‑‑
DAVID TATLISU: One year term so we can keep one‑year Chair rotation, yeah. So.
AUDIENCE SPEAKER: Many years ago we put in place a new plan because when Denis and were selected there was a poll ballots out of a hat programme that was in place for Chair selection, with that we implemented a new process that had three years (William Sylvester) with offsetting terms for each Chair. The idea here was to provide continuity and so that you never had a case where all three Chairs were being replaced on in the same year, which is what happened about eight years ago for our Working Group. So in the interests of sort of keeping that going, the idea was to finish out the term that Denis was stepping down from at this meeting and to provide that level of continuity and bridge between sort of the new Chairs and the old Chairs.
DAVID TATLISU: Okay. I don't see anyone opposed in this room, chat also looks fairly quiet so in this case I am going to go back down, start a poll on Meetecho for the Chair selection of Peter and William and we will talk about the results after Edward's talk.
WILLIAM SYLVESTER: Ed, you are up.
EDWARD SHRYANE: Good morning. From RIPE NCC working on the database team and this is the ‑‑ here is the operational update for the RIPE database. I am here representing the database team, and thank you to the hard work and effort of the ‑‑ my colleagues over the last couple of months that went into this update.
Progress since the last RIPE meeting at the end of November. We have had four Whois releases, the first two releases were focused on RDAP improvements. RDAP is a more modern alternative to querying with the RIPE database and we feel it's important to keep up to date with draft standards that are coming along and also to be compatible with the other RIRs, so a range of improvements there, including improving the documentation. So it's easier to understand. Also, as pointed out in the Address Policy Working Group, we did not document the maximum prefix size in the help text so that's now fixed. We had a deadline of the beginning of April to comply with mail sender requirements from two big mail providers and so we focused on that, two big features were to take undeliverable addresses and once we get a bounce, we no longer send, continue to try and send mail to those addresses. The second thing was to add e‑mail unsubscribed support so this is giving the user recipient of our e‑mails an option to opt out and to unsubscribe.
Given we had to comply with the mail centre requirements there was a backlog of features which we then released in May. Quite a lot of changes. The headline was to deliver NWI‑4 so this is a new status called allocated assigned PA, the intention is that you can document one assignment that's the same size as your allocation. And we already have three of these objects as of this morning in the database.
Another improvement was to add a character set flag so now on the command line if your terminal is UTF8 you can specify that and your response will be in there. And that is part of the preparation work for supporting UTF8 across the database. Also, something that got a lot of support on the mailing list was to add support for querying for sponsoring org, it wasn't mentioned when it was added but we now support this feature. And a variety of other changes.
There was one single outage in April, operationally we do update our packages regularly and that means we need to rotate our master database so we do regular switch‑overs, also it's good practice in case we ever have a failure but in this case, we ‑‑ yeah, there was a problem with the new master that it wasn't accepting updates, we took 20 minutes to resolve that, queries were unaffected but it's something we really need to get to the bottom of because since we are doing switch‑overs regularly this needs to be very reliable.
Statistics on various features we have added recently: NWI 14, we have extended the M N ref attribute to new object types, there's been only a modest take‑up of that which seems to indicate it's not really a problem but if you'd like to protect your objects from references from other objects you can now use this mechanism to do that.
Abuse‑c validation, we are a little bit behind with our validation because the registry services team has been very busy with billing in the first half, we are aware of it and are keeping track of it and we will be focusing more on validation so by the end of the year we will be ‑‑ have every Abuse‑c validation validated, according to policy.
The Geofeed attribute is now ‑‑ there's now a purpose for Geofeed in the RIPE database and now use of gey feed is comfortably ahead of the workaround for using remarks Geofeed so there's a good twice as many use of Geofeed so it's good to see there's good update. The NONAUTH clean‑ups and database is continuing to Spring it's slightly over 5,000 objects in there.
Synchronizing LIR Portal users to your default mainer in the database, easier to maintain and nearly 2000 LIRs have opted into that.
Going back to mail sender requirements to give you some more details on what we did. We rely heavily on mail to notify users when updates happen to the database. We have nearly a million distinct e‑mail addresses in there. So it's really important that we comply with these requirements to make sure that users do receive these notifications. So far, we have just over 1,000 addresses that we have detected as undeliverable. Almost about zero unsubscribed and it's now gone back to zero so that's a good vote of confidence and nobody seems to want to have opted out of this process so we feel the users who are receiving these e‑mails see value in it and they want to continue seeing them.
One surprise with this was that outgoing volume was not really affected by these changes. We qualify as a bulk sender in the eyes of the mail providers and we are sending over 30,000 outgoing mails but even after defecting these undeliverable addresses, the outgoing didn't really decrease and we didn't get a lot of complaints from our users so it seems to have gone well and we now have more data about ‑‑ and it's now more accurate, this mail ‑‑ we know more about these e‑mail addresses. But there is remaining work. I believe we are very dependent on these large mail providers to contact our users. The big three mail providers: Google, Yahoo who impose these requirements, also Microsoft, they are hosting well over 300,000 of these 884,000 addresses. So if one of these mail providers decides that we are ‑ their users we really could have a problem, there could be a lot of fallout. So should we investigate alternative notification methods?
Maybe low volume, but yeah, for now, mail is the only option.
Secondly, should we retry send to go undeliverable addresses? Now generally, the failures we have gotten have SMPT500 errors which indicate permanent errors but is there an argument for going back since there is no mechanism right now for users to resubscribe themselves, since we anticipated the volume would be low, we plan that for now, users will have to contact RIPE DBM so registry services and we will manually resubscribe them. So far, there's been absolutely no tickets so that's really encouraging so maybe that's a signal that we don't need to spend effort on this, but it's something we can improve.
Operational work: As, you know, we are not just responsible for delivering features, we also operate the RIPE database and the Whois services. One thing we have improved is separating client certificate authentication. We did turn it on on our main rest API but it's annoying if you rest rest API link with this option on. TLS will ask the end point, the browser will pop up app request to the user asking to choose a certificate. Since we want to accept a self‑signed certificates, we can't scope that to just ‑‑ we are not issuing certificates for the RIPE database either. So this pop‑up is very annoying, I don't think it's usable like that so we switched to a separate service. If you choose to use client certificate authentication use this well known service name, it's in the documentation.
I also ‑‑ it was in my slides from the last meeting, but I have added an example to the documentation: How to create a self‑signed certificate, how to sign an update and how to use to make an update.
Secondly, to ‑‑ in support of the the company targets of the budget and consolidating our footprint in the data centres, we are consolidating our servers, we are looking at all of our servers for the database service. We have improved how we deploy, every server is now identical, which is easier to maintain. We had a mix of old and new servers, where we were keeping old servers as long as we could, but we had performance problems, we had inconsistencies between the response of the old servers and new servers and we felt that the mix of new servers that we had were quite adequate in delivering the service so we were phasing out the old ones. Finally we are continuing with our effort to easier to deploy test operator or service.
RIPE database documentation, a small thing: I mean, apart from documenting the new features we have been adding we added a new service name for the documentation specifically. Since up to now it's been a part of the web application but there's really no need for that; we felt it needs to standalone, it's Whois documentation, not just a web application.
RDAP, we made some specific new features in RDAP. There is the RIR search which is cross ‑‑ across RIR effort to add missing search features to the RDAP spec, specifically for numbers for the numbers databases and one of those is to do basic search features so you can now look for names, you can search for names more easily and upcoming will be hierarchical searches, that's ‑‑ we are going to complete that next. We implemented a draft spec for Geofeed so you can now access that information over RDAP. Something that was discussed in the mailing list, we are now ‑‑ we have readded returning e‑mails in entity responses, this is something we count against the daily limit because it's considered personal data, but we didn't want to block our clients for excessively querying for personal data, we decided to remove it, our users found it useful to be in there. It's now returned for entity responses, it's not in there for resource requests but it is for entity responses so clients can choose to ask for it.
And finally something that came up in a previous RIPE meeting, somebody pointed out there's not enough in the read me on the open issues and the differences with the RFCs and other RIRs, so we have been working on resolving that, also talking to the other RIRs and the ‑‑ and draft co‑authors on how we can improve compatibility.
Numbered work items: We have implemented the new allocated assigned PA status, allows LIRs to register a single assignment and there is an impact on policy, RIPE 82 the allocation of assignment policy mentions the statuses by name and we need to document this new status there also so we will be updating that separately. And secondly, compatibility change on in NRTM version 4 implementation to be better standards compliant, we return 404 rather than 400 if a client requests an invalid path.
So, that's wrapped up all of the work that we have done. Now to talk about the upcoming changes:
A big one is authentication, I think this got everybody's attention back in January, there was a security breach. It ended up affecting single sign‑on, but it could just as easily have been the RIPE database and we do need to start planning to phase out MD 5 and look at how we use passwords in the RIPE database and to be clear, I think this is going to affect batch updates so a non‑interactive updates. I believe we have a good, existing solution for interactive updates, it's signing he will sign on, we need to encourage people to stop using passwords inter actively, please use single sign‑on, it's mature and been there for years and it's well supported. So we need to focus on improving the story for non‑interactive batch updates which comprises the vast majority of updates for Whois if you want to do update changes. Using MD 5 in this day and age is a huge security risk. There is a risk on RIPE NCC if we have data breach or a bug to expose these hashes, there is a risk on our members and our users, we have 20,000 maintainers with MD 5 hashes. If that ever leaked, we have a database procedure but there would be a lot of work for or support, we would have to invalidate those hashes, all of our users, we'd have to re‑establish who our maintainers are, reset their passwords, and in the meantime there would be disruption to the RIPE database because there will be no updates. Also we need to examine how passwords are used, it's possible to transmit passwords in security, for example mail updates right now supports passwords and mail updates, if it doesn't follow a secure path you can end up on a mail spool somewhere or transport an insecure transport so there's a risk of exposing passwords.
Also, something to consider is passwords are anonymous, they are not tied to a user, maintainers can be shared and you can have multipeople sharing that job and in the end you can't tell who is making a change, if the password is shared.
So, we need to turn to looking at more secure methods of authenticating updates.
To bullet points we already have: We have introduced client certificate authentication so that's an alternative. There's no shared secret, you set up a shared key search object with your key and you can use that to authenticate changes. For a long time we have plastic key signed updates so you can use BGP, for example, to sign updates and send it in using sync updates or mail updates. Admittedly, two drawbacks of those methods is that it's difficult to set up and use, password authentication is just very easy so there will be a story about migrating there. We also need to look at alternatives to the two methods we already have, seeing as our single sign‑on is compatible, there are an app I and open standards there, one is to use the authorisations code flow linked to your SSO account, you will get an access key which you can refresh your batch script, for example, can refresh that, you use your access token for authentication and you can refresh that periodically with a refresh token.
Secondly, something that we'd like to suggest is use API keys, this is something you can do in the LIR Portal but it's restricted to the LIR Portal. Wednesday like to extend that to the RIPE database and we feel it could be useful across all of the NCC services so these things we are talking about, not only for the RIPE database but across other RIPE NCC Services that we could find them useful there too and for our users.
So, we'd like to put that forward, that we do need to urgently migrate away from MD 5, there are alternatives there, there are standards compliant alternatives, but the migration is going to be difficult; we are all very used to using passwords over the last 20, 30 years of the database. So next steps, I believe to publish an impact analysis as usual for any large changes and we will ask for your guidance and your feedback, we depend on the mutant to let us know where we need to go next with this.
Next up is a policy that's been approved recently, aggregated by LIR, this is a status already exists for IPv6, for inet6num but not for IPv4 so there is now an option for IPv4, using a grated by LIR in a similar way to inet6num, it's an accepted policy proposal, there's a RIPE document linked, 822. We are now already implementing it, implementation is in progress, there is going to be changes across a lot of our service. Status hierarchy is going to be similar to IPv6 and the assignment size will be there, we are adding assignment size to inetnum but it will be optional, we are planning for deployment late next month.
RDAP as I have already mentioned, there are specific features we are planning to implement in the coming months. One is, objects with administrative status are not returned. This is an edge case where we have delegated space from, that we have been given from IANA but we are not allocating it. There isn't a lot of it but what we are returning, I believe we are returning 404 but we should be returning administrative block.
Secondly, the RIR search, this is the second half of this RFC, we are going to add support for relation searches, so you would have hierarchical queries.
Finally, my colleague in ARIN is working on a draft for bulk RDAP which could be useful for RDAP users so you will get access to bulk data in RDAP format, similarly to what we provide for in version 4 there's a draft available so if you'd like to review and comment I think that would be appreciated.
NRTM version 4, the co‑authors of this draft are at the meeting this week, we had a productive meeting earlier. We have a couple of remaining work items in this survey implementation before the database team. First up is key rollover, the draft gives us a year to implement a rollover but we do need to do that since it's now been in production for about a year so this is a feature we need to do soon.
Secondly we discovered there is a signature risk condition, you can download the notifications to tell you what's changed and you need to make a second request and in between those two steps it's possible for there to be a risk condition. It's actually pointed out this can happen multiple times a day depending on when the client has started, it can happen, it's not a rare event so it's something we need to fix.
We need to improve the documentation. For now, since the draft has been ‑‑ it's been a draft and there hasn't been a lot of deployment but this needs to change and that's one way we can improve adoption is to improve the documentation so we need ‑‑ especially our RIR implementation of it, we need to get the word out and to describe fully how our implementation works and how to find it.
And lastly, to help with the draft adoption, it's good practice to have multiple clients so ‑ is going to work on a client side implementation, for version 4, also it will help to go through the draft text again, helpful to have more eyes on the implementation side to see if we have missed anything, if the documentation draft needs to be improved.
And hopefully it will be useful for the community; I know the NRTM version 3 client we have in Whois does get some use.
Something that's been left over since before RIPE 87 are cleaning up remarks attributes. There were two projects from over 20 years ago now but there are traces of these remarks, these projects still live on in the RIPE database and I believe the time has come to clean it up so that the plan is to remove these remarks. We have already done it for two other projects, and as has ‑‑ as usual we will be notifying the Working Group and getting into contact with maintainers before we make any changes so we will be announcing that later.
An ongoing effort, I believe it's one of the number of work items is to implement support for UTF8 and as I have mentioned we now have a flag for specifying the character set. We do already support UTF8 in web application and ‑ APIs but there are other relied on by a lot of our community that are still Latin 1 so we proposed an impact analysis earlier this year on how we could migrate to UTF8 in three‑phases. First is to add a flag, so you can already make use of UTF on the command line, and in future if we ever change the default it means you can change back to the current legacy behaviour; Phase 2 would be to convert the database key to ‑‑ there will be no user face changes but we can start using it internally; as a final phase, we would then also store UTF8 in the RPSL objects.
So and again, we would not have any change to the user facing functionality, but it would modernise the underpinnings or application and the database that we can start using UTF8 internally but it does depend on the future decision by the company: Do we want to change any of our interfaces? Port 43 or dump files, all these are still Latin 1. And we will not change anything without strong support from the community. So it's in your hands. So we'd appreciate some feedback. I'm not sure what next steps are ‑‑ thank you, William ‑‑ to move forwards with this.
A small feature that we have added, we want to integrate with RPKI, we have some ‑‑ there are some scenarios where Route‑6 objects can conflict with ROAs, we have implemented for single ROAs but we do need also to take into account overlapping ROAs, that's a common case where you have one intersecting ROA which is valid, one which is invalid, matching the route object, so that needs to be implemented, it will be in the next Whois release at the end of next month and we will turn on in our rest application and web API.
Missing history, something I mentioned before but it bears repeating: We have some gaps in our database that we'd like to fix, it affects old data but it's something that affects version history queries, both our internal staff, some ‑‑ because the version history can be broken, external users you don't have the full picture of ‑‑ for old data. Also affects Whois code because we need work‑arounds. So we want to fix this, we do have the full history in our update logs and the internal resource registry going back to the very beginning, but we want to backfill this information into the RIPE database so we have a consistent view of our own history.
Retiring NS.ripe.net. Maarten is here and he mentioned this yesterday at the DNS Working Group, we are retiring that service, if you are ‑‑ if you know what it is. There's some information there. But I think it bears repeating because there's an impact on the Database Working Group so if you are affected, the ‑‑ please share your feedback on the DNS Working Group.
Using the Cloud. I think this is my last slide. Some news on the Cloud. We are going to stop the Cloud consultation proposal. We believe that without strong support from the community on bringing this forward, that it's better to stop the effort to migrate the RIPE database to the Cloud. We are taking RIPE community feedback into account, especially concerns around vendor locking personal data and all of that, also the negative reaction to the CID N domain registry proposal in February, that really didn't help, so we don't feel there's strong enough support to move forwards; we will instead focus on improving our on premises environment and all of the database will remain on premise. I wouldn't like to close the door completely on the Cloud and I think there's a place for it but we need to be careful. I mean, there are things that will benefit from a Cloud deployment or at least using a CDN. The version 4 that we are using has very big daily snapshots, RDAP returns large JSON responses and our ‑‑ the APNIC RIR have already migrated RDAP to the Cloud, they see benefit in doing that. But for now, to reiterate we will not make any more effort on our Cloud proposal.
I believe that's it. And hopefully I am still under time, if there's any questions? Thank you.
(Applause)
LEO VEGODA: Peering DB. So, I want to thank you for the work you are doing on UTF8, it's definitely the right thing to do. I think this is in support of the accuracy goal. We have countries in this service region using circumstance I can, Arabic, Georgian, maybe other writing systems, I don't know. If we can accurately reflect them in the database that's the right thing to do. Your plan looks sort of right, I am not going to micro‑manage it, but I have a request: You started off talking about RDAP. I know that RDAP is not fully supported for all Internet number resources. It would be great if you could do some kind of transparency report. I don't think it's actually the RIPE NCC that has the issues, so this is you with your NRO hat on but it would be really helpful for people that rely on RDAP to know, this is the gap, this is where the gap is, and maybe these are the plans, because if you have to fall back to Whois, you normally have to fall back to a manual process and this week we have seen instances where you have to fall back to R Whois and that means you have got three different things and you have got to know to do the right kind of query, depending on the resource. So, I am not saying please go and fix the problem but it will be great if you could start with the transparency report and then we can think about how we can turn off at least our Whois.
EDWARD SHRYANE: Yes, thank you, Leo, that's a great point and I completely agree with you. RDAP traffic traffic has been about 5% of query traffic for years now and isn't get any more adoption. I can see RDAP is the future of Whois, it is across RIR and ‑‑ but it is the ‑‑ it's missing a lot of features, especially the IRR and we have been making efforts on filling gaps elsewhere like the RIR search feature. There's another draft, draft proposals as well. But I think the way forward is to create a draft for missing features, especially the IRR database and as you said, create a report on where the gaps are and where we can fill it in.
LEO VEGODA: I think thinking initially just, these are the proportion of resources that can't even be queried. So I know that there's a feature gap but I am not really thinking about the feature gap; I am thinking with my PeeringDB hat on, if someone requests a registration number and they have ‑‑ we have to fall back to a manual process. And so, we have had conversations with RIRs about this and I know that RIRs want to work on it, but just defining ‑‑ this is the scale of the gap for the proportion of different Internet number resources, AS numbers, IPv6, IPv4, these are the parts of the world affected, whatever it is, the RIPE measurements that you will understand and you'll put the RIPE measurements in that report, that would be super helpful and then we have got something to go off and we can grow that 5% to more than 50 at least.
EDWARD SHRYANE: Yes, okay, thank you, Leo.
LEO VEGODA: Thank you.
AUDIENCE SPEAKER: Peter Hessler, member of the Working Group for next two, three minutes. I just wanted to comment quickly on UTF8 to follow up on what Leo was saying. I did a very quick Google search and found LACNIC is returning UTF8 objects on Whois on Port 43 right now and I was curious if you looked at the wider ecosystem of the major Whois providers, who else is already providing this and if you haven't I would recommend that we take a look.
EDWARD SHRYANE: Yes, I have done that, I have looked at all the RIRs and I don't want to name names but most of them do not return UTF8, at least not yet, most are still Latin 1, surprisingly, given the different languages and strips, our community are a very wide community who don't necessarily use that script day‑to‑day.
PETER HESSLER: There's at least one who does?
EDWARD SHRYANE: Most are still Latin one. I can share with you separately.
AUDIENCE SPEAKER: I just want to share even though there might be databases or other Whois providers who already ‑‑ the tricky thing is generally the will be hard coded in the Whois clients as there's no light way to communicate that, you have to hard code it in the client, even though LACNIC might do it it might not support RIPE doing it immediately. Thank you.
EDWARD SHRYANE: Okay, thank you, if there's no more questions, I will end it at that. Thank you.
(Applause)
DAVID TATLISU: We have got the results of the poll, I would like to ask the Meetecho staff to show them ‑‑ they are not shown in the room but Peter Hessler has received 14 yes... three abessentials with with that I would like to thank everyone who voted and we have got a new set of Chairs.
(Applause)
WILLIAM SYLVESTER: Up next we have Cynthia, Dmitry and Leo.
DMITRY KOHMANYUK: Thanks, everybody. So we had the key word RDAP and it's also here somewhere. So we did this previously, I hope you are not yet bothered, thanks to ‑‑ not yet bored, thanks to group numbers.
We talked about, basically, doing something else that people can find in the RIPE database to find people who are responsible and these are records we use and can put in right now. The two left with so far, so good.
Right, not so far not so good. Everybody wrote a postal letter according to the RIPE data? If you are a lawyer, sure. No hands, okay. How about faxing, is faxing still good? Somebody told me RIPE NCC used to use fire fax machine to open account and it's useful, right? I use that. But I lived in United States, it's a different country. So ‑‑ and so this is using my data so consider it not so personal. We have something like that, right? The right will be a structure RDAP ‑‑ well JSON like and you can put things, well, the things I mentioned, this is a context object, can also partial abuse object. The idea was that we can do things easier in Whois because they are free form objects for the implementations it's just a dump of data, now UTF8 maybe text and the formatting is for humans, there is no substructure. In RDAP, you can do interesting things. At my work, I am could manager of Ukrainian domain registry, we found the spec is very interesting, the spec keeps evolving and you can add many interesting fields and sub‑fields and data types. So, we found them RFCthat we can probably look at and you can basically now use ‑‑ my original idea was we put like signal colon number but these are a propry name and B we don't have a name space for that. The URI are let's say more ‑‑ although there is no guarantee that particular provider say, WhatsApp, would keep using the same URI if it's HTTP accessible method so it still has to be discussed further. This one for the N E domain is something they can use today and switch to another one later. So it's still an open question for the Working Group: What do you want to do with that stuff, if you ever want to do that? Something like that, go into some of these fields would be URI contact or contact column, we don't have a contact field yet and that can be inserted into the substructure of the object. With Whois it can just be a text field.
So, if that becomes a path to futurality, it should be ‑‑ and I guess we have people in the room who actually implemented database and they just spoke about RDAP being 5%. Well, still, it's something.
We can also do ‑‑ we can have discussion about the specific URLs we use and probably we want to limit those to HTTP although I don't see the strict requirement.
Any other comments from the audience? I try not to eat too much of your time, please comment now or in the group e‑mail or ‑‑ you can use this signal as well. That phone number is valid for that, not the 555 but the actual one that is in the slides. Thank you.
SHANE KERR: IBM. I think you would have a hard time finding anyone who disagreed that we should modernise these. I don't have any strong feeling about whether these private URIs make any more sense or they should TP S, I don't really know. In the you could consider polling the community or whatever but I don't know that you would get an accurate representation of what people want to use. I don't know, what's your feeling? Do you think we should adopt these private URI schemes?
DMITRY KOHMANYUK: I would prefer not to rely on vendors filling name space we are using, I don't feel like going the IETF route ‑‑ it's a good idea, we will meet in five years and see what happened, but no, I don't have a specific preference. I prefer not to use custom ‑ like SGNL that would work maybe on your Apple device but probably would not work on your computer.
SHANE KERR: Yes
DMITRY KOHMANYUK: It would definitely not work on your Linux system.
SHANE KERR: That's an interesting point as to what the behaviour would be on different systems, like, yeah, am I able to click on my phone or weird copying and pasting or things like that
DMITRY KOHMANYUK: Maybe we can add a database object called contact method and then create a link to that within the contact object.
SHANE KERR: There's nothing that can't be solved without ‑‑
DMITRY KOHMANYUK: Absolutely. So we have a blob of signal is and then you have this two or three URL magic things.
SHANE KERR: It's not crazy, yeah, yeah.
DMITRY KOHMANYUK: Maybe the separating method from the data is good and so far all these things have only one parameter so it's not difficult, don't need substitution mechanism.
CYNTHIA REVSTROM: I think how do we encode this? In Whois, it's easy. You don't ‑‑ you can just put in whatever, you could put signal, space, phone number. The issue is, we want to have this be supported in RDAP in a way that requires as little extra work as possible and preferably using standards that already exist, because otherwise we would have to first come up with a new entirely format and write an RFC for it and it's a lot more work, so that's ‑‑ and we also want to support as many things as possible, while preferably not using anything proprietary, so things like the signal ‑ and all of those things, so it seemed like a good middle ground, considering this RFC that's also on the screen now, exists, and it could probably be used for this. Thank you.
DMITRY KOHMANYUK: Yes, I apologise if I missed some of the words. Does anybody else have this problem? It's like depending where you stay, I think, I hear my voice from two directions with the slide operation. Any other comments from the audience? And the Chairs, maybe?
AUDIENCE SPEAKER: I don't have a problem with this, obviously, as a co‑proposer but I would just like to speak up the use case a little bit. You know, Ed, earlier on, talked about the large proportion of contact e‑mail addresses that are hosted by a very small number of mail providers. And phone is also often an Internet thing, nowadays. I think, just adding a third option of Internet relatively quick contact between networks, is a genuinely good thing because it's very easy for at least one of those two almost realtime options to not be available and so having a third contact option is just operationally useful. And so that's the only point that I would like to make in addition to what you have already presented.
DMITRY KOHMANYUK: Yeah, right. If you start with the problem statement that you can't reach those people fast enough, or have assurance that they have received your message, definitely would not work with the facts of postal mail ‑‑ although, no, mail can be ‑‑ e‑mail, return received, is anyone using them still? Phone? Well, yeah, you hear their voice but you are slightly annoyed especially if you are in other continent, you may not want to do that and these things cost money. So I guess the main advantage we gain is specifically for delivery and ‑‑ proof of delivery and some messages show you this proof of being read. One more thing: Since we had presented this signal has rolled out user names so significant name numbers are not phone numbers any more unless you enable that in your settings, it would be user name which can be updated by the person created that so I can start a user name tomorrow and change it the right ‑‑ to the meeting ends so that's something to keep in mind but that's true with any other information, I guess phone numbers are less ephemeral, but that's another kind of issues.
WILLIAM SYLVESTER: We have an online comment: Thanks a lot for the work, not a question, just I wanted to say I think using URIs is the most sensible way forward; however private schema sounds like a nightmare ‑‑ directors might be best.
DMITRY KOHMANYUK: Who wrote that?
WILLIAM SYLVESTER: Nico Braud‑Santoni.
DMITRY KOHMANYUK: Thanks. Well, we are fine with the timing. Thanks.
WILLIAM SYLVESTER: Thank you so much.
(Applause)
So up next we have our NWI review, Denis.
DENIS WALKER: Okay, this is my last presentation since I am stepping down as a Chair after this meeting or I think I have actually stepped down now since the new Chairs have been elected.
So, NWI update: This was kind of dropped on me at the last minute so I apologise for not having any slides; I will just basically talk over it. Okay. I have done this presentation so many times over the years, and not a lot changes from one RIPE meeting to another.
We still have a lack of community involvement on these issues. We have little bursts of activity, followed by long periods of silence. Ed mentioned that we have just implemented the option to assign a whole allocation. It's taken us eight years to get that NWI over the finishing line. These are mostly minor sort of technical changes, but it is just not sustainable to be focusing on these things for so many years.
Now, this is a problem for the new Chair team to address. But certainly timelines have got to be built into this system, because it's just ridiculous to have these things open for so long. So, I will let them talk about that probably for ‑‑ over the next few months and then the next RIPE meeting.
One of the bigger problems, of course, is people in this community don't have the time to focus on these minor sort of issues. A lot of people see them as minor technical changes, and as I have said a number of times over the years, maybe some of them we should just treat them as bugs and say to the RIPE NCC: Here is a bug, go fix it. They can come back to the community and offer either a simple couple of lines to say yes, this is what we can do; or even a full impact analysis if it's something like the assigning an allocation where you were considering that Tuple option, which was basically major heart surgery on the RIPE database. But I think again it's for the Chairs, new Chairs to think about, but some of these things are so trivial and you don't have the time to spend thinking about these minor little glitches in the software, just ask the NCC to sort it.
As we have got a bit of time, I will go through the open NWIs and give you a little bit of background on them and some idea of what would actually be involved if you went ahead and did it.
The still one that's still open is NWI‑2 and this is another of those it's been there for years and years and years but we just can't get you to say to us: Yes, do it, or no, forget it. And this is about a history of deleted objects. Now, when we implemented historical queries, I wrote the spec for this many many many years ago. At the time we didn't know if anybody really wanted to use this feature, would anybody actually query for old objects, deleted objects? So we went for the simple option, the low hanging fruit and that was basically saying if the object exists in the database today, we will let you look at the different versions as far back as the last time it was actually created or recreated. So if you have an object and you do a number of updates on it, then you delete it and you recreate it and do a few updates, all you can actually see is that series of updates since you recreated it. But it was an arbitrary decision, it was just to get something up and running quickly. There's no reason why we shouldn't give you the full history. We do redact the personal data of the object anyway so you only get in the operational information.
So, it makes no sense to have this arbitrary limit.
The RIPE NCC legal team did a presentation at RIPE 84, which is about two years ago, and they were basically saying, in order to assess it, they would like the community to come up with some requirements for this. We did ask if there were any volunteers two years down the line, we haven't had any volunteers. So, maybe one of the Chairs can actually give an option to you and say look, this is how we think it could be done, do you like the idea? Shall we just go ahead and do it? Then the legal team can assess that option and see whether they consider it legally valid. And then just get on with it and do it. Otherwise, forget it.
But I think, also, with the new aggregation feature we have introduced, it has the potential for considerable deletion of assignment objects. So I think being able to look back at deleted objects may become more important. Shane?
SHANE KERR: IBM. Is your intention to ‑‑ for us to discuss these items now or do you just want to go through the list and give a status update? Or maybe that's a question for the Chairs.
DENIS WALKER: It's your decision, if you want to go ahead and discuss any of these things, go ahead and discuss them.
SHANE KERR: If I recall correctly, when we wrote the requirements for the RIPE database we discussed historical data and I believe our recommendation was to make it not accessible except for researchers whose ‑‑ who would request access to the data and sign an NDA, so there was a recommendation made. I don't know ‑‑
DENIS WALKER: It's coming up later on the list.
SHANE KERR: Okay. Well, then, I guess there has been some action ‑‑ I guess not since two years ago but ‑‑
DENIS WALKER: The two different issues, though: You were talking about having a split level return on the queries, depending on who you are. This is about going beyond the deletion point.
SHANE KERR: This is about removing any ability to query deleted or historical data at all, and just have that available for people ‑‑
DENIS WALKER: That's not what you actually said but we will get on to that in a minute.
SHANE KERR: All right, that's fine.
DENIS WALKER: So, as I say, I think possibly this would be more important if assignments do start getting deleted but again, it's up to you to think about it.
Right. NWI‑4 was the assigning the whole allocation and as Ed has just said, finally we got that one over the line so that's now closed.
NWI 12 is the NRTM v4. Now, there's nothing for the community to do in this respect but I would suggest just leave it on the list as an open NWI until those final things are wrapped up by the database team, then you can file ‑‑ when it's finished.
Now we come up to the task force recommendations. There are four open NWIs on this. The first one was the baseline requirements for accurate registration and uniqueness of addressing. The task force gave some suggestions about what the baseline should be, now what's the basic information you should have in the RIPE database for registration?
What it needs to you do now is to look at that suggestion from the task force, look at the data they suggested should be in the database for these registrations and just decide, you know, is that reasonable or not? If you think what the task force recommended is reasonable, we just implement it. I think one of the main differences to what we have now is it's suggested the portal address should be optional so it's little tweaks like this that you need to look at, think about and give us a yes or no, and then we can move forward with it and actually tick that one off the list.
Where was I?
The task force only really talked about allocations, though, they didn't refer to assignments. Only two minutes left, right, I will have to speak a bit faster. Are we that short of time?
Right. So, when you come to assignments, again we are looking at now with the aggregation situation, whether assignments are there or not and should you require any information about assignments. It's something that's never really been discussed that much, but again, I will leave that to the new Chair team.
Then we have NWI 16 which is the I Panigl. The task force recommended limiting and discouraging the RIPE database as a solution. When the task force did their survey I think they were a little surprised that a lot of people are using the RIPE database as an I PAM system. The question I have with this NWI and their recommendation is, first of all, how do you actually discourage people from using it as an I PAM and if you are surprised that people are doing it and you don't know how many people are doing it, or why they are doing it or how they are doing it, we need to know more about it. We did ask the community for those people who are actually doing this, please tell us something about it; what are you doing? Why are you doing it? How are you doing it? And we got no response. So if you really want to move on with that, we need feedback.
Now, NWI‑17 is the historical data one. The task force said: Access to this data should be limited to what is necessary for the most common types of use cases, the task force recommends that the RIPE NCC grants access to a wider set of historical data to researchers who need it on a case‑by‑case basis and according to specific criteria should be discussed and defined by the RIPE community.
This sounds like a nice option, but it's actually I think unnecessary and an unworkable nightmare if you actually try to implement this.
First of all, the community has to consider four things and come to a consensus on each one of them: What are the most common types of use cases? What limited data is necessary? Who qualifies to get the extra data? And on what conditions? And getting the community to consider four things and come to a consensus on them would take years. Try and lump them all together and some people say I agree with this and not that, so it would be difficult.
Then, on the NCC to decide it on a case‑by‑case basis, you could have every researcher in this field, individually asking the RIPE NCC for permission to have this extra data. Every university that has an IT department could be asking for it, every IP broker could be asking for it. So, you could end up the NCC being flooded with requests from people to give them permission to access this extra data. How will the database know these people had that permission? You would need authenticated queries so it's a major feature to introduce to be able to do this. In the end we have so few objects we give you the history of, we already redact them and take out the personal data so do we really need to have it on a split level?
My suggestion, which is you can listen to or ignore, would be basically drop this idea. I think there isn't enough data to start separating this out into split levels.
Finally, we have NWI‑18, which is to promote roll objects instead of personal objects, restricted checks and measures over personal data in roll objects.
Again, I don't think it's really that easy to have stricter checks on this. You need to take a step back and as I tried to do a couple of years ago, present a privacy policy which looks at the whole area of personal data versus corporate data and where ‑‑ which objects it goes in, roll objects, personal objects, organisation objection, you need the bigger picture. Just looking at personal roll, I mean we have got two million person objects in the RIPE database so clearly recommending roll objects over person isn't working.
So that's the wrap‑up of the NWIs. Do we have any last minute questions?
AUDIENCE SPEAKER: So as one of the new could chairs what you would like to process we do is we as the Chairs send out e‑mails to the list for each of the Working Group ‑‑ each of the NWIs, in small batches, to ‑‑ two at a time and have a two or three‑week discussion on each one, decide, keep it, continue, close, etc., move on, go through all of them and for any that are more complicated we should work on we handle that in the mailing list so we can definitely clean up and try to address the ones that are simple.
DENIS WALKER: Yes.
(Applause)
DENIS WALKER: With that, I sign off as a Chair, thank you.
SPEAKER: Denis joined this Working Group both of us were selected back in 2016 (William Sylvester) prior to that Denis had worked from RIPE NCC he was a software engineer and mailing list and he has been involved with the RIPE database for well over 20 years so Denis, as you head off to retirement we just wanted to say as a community thank you for all of your contributions and if everyone can join me in giving you a round of applause.
(Applause)
WILLIAM SYLVESTER: We wish you the best and and enjoy the time away from the database.
DENIS WALKER: Thank you. I'm not saying you will never hear from me again but after 25 years of working on this community, it's going to be hard to just walk away; I mean, I will still be following the mailing lists. I can guarantee for the next few months I am going to say something, I might reply to Ed's e‑mail from yesterday about something, but generally, no, I have got to take a break, walk away, I mean I have been writing a lot of monologs recently which most people don't really need. I will give it a break and come back and make a few comments later on. I am going to plan a holiday for the next RIPE meeting, so I am not sitting in front of a screen, so you won't be seeing me at the next RIPE meeting either.
WILLIAM SYLVESTER: Thank you.
(Applause)
Last up on our agenda we have sort of a group discussion and this is one of the areas where we want to seek some feedback, we have talked about a lot of things today, we have talked about a lot of NWIs just now, these are a lot of features for those who are new in the Working Group, we have a different process numbered work items and this is where you can make a lower process‑driven request to get features pushed into the RIPE database. And usually what happens is, we have a proposal, we discuss that proposal on the mailing list, all of our work on NWIs really takes place on the mailing list and then from there, the RIPE NCC takes that as input, Ed and his team work diligently to try to implement these things. We have a process of understanding what is, say, for example, the level of effort, what the impact of the community, sometimes Maria and the team get involved from a legal perspective and comment on some of those different details but we do ask the community to both comment on the work items that we have existing but also to bring your best ideas, as we do look to constantly modernise the database to meet the needs of the operators and everyone who is using the database and sometimes this means explaining to us how you are using the database and how you would like to use the database in the future and what that would look like. If there's anyone has any comments and wants to talk about any of the things we just talked about, if you have new ideas or different ideas or other feedback the mics are open. I know we are sort of putting folks on the spot but, at the same time, we like to try to encourage everyone to be a participant in the Working Group and be a participant in the database.
CYNTHIA REVSTROM: I really like numbered work items because for a lot of the work that's been done in this Working Group, they just make a lot more sense than going through the whole PDP because it's typically smaller things that aren't that control and a bit like up to the ‑‑ well, I'm not sure quite what Ed's team is call, but Ed's team at RIPE NCC, to figure out the ‑‑ so generally, it makes a lot more sense because we are not writing a whole policy, just saying Hi we would like this feature or implement this RFC. So I would like it. Also, maybe it's time to have another NWI for the contact ‑‑
WILLIAM SYLVESTER: Great, thank you. Does anyone else have any comments? No. Okay.
Seeing then, one of the other topics that we had, obviously at the beginning we talked about Chair selection and one of the things that the community is trying to do in Mirjam's working very diligently at is standarding the chair selection process, one of the things we are hoping to introduce to the Working Group soon is that more standardised system that we want just to make sure everyone is aware of what that process is. A lot of this comes down to how do we identify when we are doing Chair selection process, do we do it in the spring or fall? How can we make sure we are doing it on a regular basis? How do we neighbouring sure that we are working to always have sort of a deep bench of people who are up to speed (make) and helping out and there is a lot of work that goes on behind the scenes to make sure everything we have work so from that we wanted to say that that's going to be coming down the line soon hopefully and keep an eye out for it, and other than that ‑‑ our new co‑chair do you want to close things out.
PETER HESSLER: Thank you, everyone, for attending, it's nice to see the room fuller than I have seen in other meetings. I am glad to see people believe that 9 a.m. on Thursday morning does tally exist, it's always nice. I want to make sure to thank Maria for monitoring the chat, thank you. Ellen our scribe and for the stenographers who do wonderful work as always.
(Applause)
With that, I call the Working Group to a close and we will see you on the mailing lists later this week. Thank you.
(Applause)
LIVE CAPTIONING BY AOIFE DOWNES, RPR
DUBLIN, IRELAND
(Coffee break)
