Denis, I am very surprised by your statements. To be honest your email seems quite detached from reality so it is somewhat hard to formulate a coherent response. I'll try to explain this as simple as possible: the users of IRRd (you clearly are not one of them) have come to realise that the 20-ish year old codebase (https://github.com/irrdnet/irrd) is no longer meeting today's requirements in terms of maintainability and extendability. To address this concern a full rewrite is underway (https://github.com/irrdnet/irrd4). In the spirit of the original IRRd, this is work is open source and published under a very liberal license, you're welcome! Statements such as "This is being done without the decades of experience, knowledge and understanding that has gone into developing the RIPE Database software on which all 4 IRRs are based that are operated by the RIRs." are not only false but also insulting and discouraging. It actually may be you who lacks decades of experience on how to operate a network and generate high quality BGP filters and what the role of IRRd instances are. I had the feeling that some people in this working group thought that the third party IRRs are making zero attempt to increase the security of their offering, so I hoped to illustate that people actually are putting thought, money, and time into improving that situation. This IRRd rewrite will ultimately result in the possiblity for operators of "third party" IRRs to provide more secure, higher quality services. Kind regards, Job On Mon, Jun 18, 2018 at 12:43:22PM +0000, denis walker via db-wg wrote:

During the current discussion on out-of-region ROUTE objects, Job announced that IRRd is being re-written and will have some 'potentially' fantastic features including 'possibly' authentication against the RIRs number registries. The alternative/commercial IRRs have also been heavily promoted at many points in this discussion as 'the answer' to the current problems. I personally, and some others, have some issues with this. So I thought it appropriate to open a discussion on this issue as it does impact on, or is influenced by, the operation of the RIPE Database.

Firstly it is unfortunate that all the RIRs that operate an IRR may not be in a position to accomodate all routing requirements that are currently provided for by the designed security hole in the RIPE Database at the time this security hole will be closed. To push operators to switch to commercial services as the answer simply monetarises routing which, as Randy pointed out, may affect smaller operators more, as perhaps the IPv4 market has done.

I looked at the github details of this new IRRd. I get the feeling that this is simply trying to re-invent the RIPE Database software in yet another language. This is being done without the decades of experience, knowledge and understanding that has gone into developing the RIPE Database software on which all 4 IRRs are based that are operated by the RIRs.

Job also pointed out that "One of the possible (and desired) extensions is an authorisation link to the authoritative RIR." This suggests some form of cross registry authorisation with/between the RIRs. During the years of debate about these out of region ROUTE objects this has been discussed and virtually dismissed on several occasions.

If the RIRs, and certainly the RIPE NCC, are going to devote time, effort and members money to develop some form of authorisation system for a remote IRR to connect to each of the 5 RIR number registries to authorise ROUTE creation, then I personally would prefer to see the development of a single, global IRR operated by the RIRs. This cross registry authorisation is probably the main element of having a single IRR.

Currently 4 of the 5 RIRs operate an IRR and they are all based on a version of the RIPE Database software. So we already have a common IRR database format. Add in this cross registry authorisation and we have a global IRR. I don't see the point of putting in the effort to develop a multitude of alternative/commercial IRRs when we can go the other way and have a single, authoritative, free IRR service. We have one internet, one DNS, why not one IRR?

I know the first comment is probably going to be, "we already have this with RPKI". But for whatever reason, not all operators use, or want to use, RPKI. That is a reality, just as much as everyone switching to IPv6...not. Since RPKI is not the complete answer, we still need an IRR where the ROUTE objects are validated and trusted. I think the RIRs are in the best position to each develop a trusted IRR linked to their own number registry, then take the leap to create a single IRR. I personally think this is the better way to go than develop secure authorisation modules for IRRd.

cheers denis co-chair DB-WG

please note that the rirs are a small minority of the irr instances. i do not have time to deal with putting more lipstick on the poor pig. randy