On 4 Apr 2022, at 7:42 PM, Dan Mahoney (Gushi) <danm@prime.gushi.org> wrote:

On Tue, 5 Apr 2022, Job Snijders via NANOG wrote:

I think all of us recognize a need to declaw "third party" IRR databases
like RADB and ALTDB ("declawing" meaning that it is not desirable that
anyone can just register *anything*); on the other hand our community
also has to be cognizant about there being parts of the Internet which
are not squatting on anyone's numbers *and* also are not contracted to a
specific RIR.

As one datapoint, two tiny /24's I (not-dayjob) originate are legacy resources. They cannot be added to either RPKI or the ARIN IRR objects without endeavoring to spend an at-least-this-much-money-price-will-only-go-up-over-time amount.

Dan -

I’ve frequently spoken with people with legacy resources in this situation, and some opt to sign an RSA & become an ARIN customer, and others do not… It’s your choice, and those with concerns about the NONAUTH RIR shutdown who didn't want to become ARIN customers and use our authenticated IRR were directed towards several of the other perfectly fine IRR projects out there (e.g. RADB, ALTDB, etc.)

There’s nothing amiss with putting routing objects in these other IRR systems, and no one I spoke with had any challenge with the concept. As far going with the RPKI ROA route, I’ll admit that I didn’t raise it very much (since it inherently requires a level of validation that many organizations don’t particularly want or need to go through with their legacy number resources...)

Ironically, to find the way forward, ARIN would require incorporation, the signing of a RSA, and Moar Money for this same organization to have similar v6 blocks, in order to eventually retire these v4 resources.

IRRExplorer presently flags these with a warning "expected object in ARIN db" because there's no programmatic way (via either WHOIS or IRR) to detect a legacy resource that I can find.

This is an edge case which will only diminish over time, but it does exist.

The “edge case” of having IRR objects for legacy resources doesn’t necessarily have to be a problematic situation for the operator community – so long as the operator community continues recognizes a nominal set of community-run IRR projects for such situations, and those responsible for maintaining their routing objects actually do that… There is obviously tradeoffs involved in having “open" IRR systems (e.g. the issue of “declawing” issue referenced by Job) but hopefully deciding what to follow becomes easier for everyone if there fewer of them out there echoing years of crufty/unmaintained data - as was the case with the ARIN-NONAUTH IRR.

Thanks,