Hi Radu,

It was all hand written. I think your LLM radar is broken.

With kind regards,
James Bensley (he/him)
From: Radu Anghel via routing-wg <routing-wg@ripe.net>
Sent: 28 July 2026 10:09
To: routing-wg@ripe.net <routing-wg@ripe.net>
Subject: [routing-wg] Re: ASPA AS0 Records for unallocated ASNs
 
Hi James,

Perhaps your LLM went a bit over board on this one, "emotionally"
speaking. Personally I'd like to think the RIPE mailing lists are still
human-ish interaction.

Job made some very good points your LLM wall of text missed. Sorry but I
am not going to expand on this, but maybe human reading his message
would help.

Radu


On 27/07/2026 20:32, James Bensley wrote:
> Hey Job,
>
> Thanks for providing more info that was helpful.
>
> I don’t agree with quite a lot of what has been written (simply because
> there seems to be more emotional that strong/clear logical reasoning),
> summarising some of the points across the archives:
>
> *  "It’s a lot of effort" → maybe it was in 2021, to put together a
> pipeline today that generates an AS0 ROA when a prefix changes state of
> unallocated, and removing it when it loses that state, should take a
> couple of days to churn out in today, maximum 1 week. So I don’t buy the
> effort argument at all. If it really is a serious amount of work, that
> just raises more question about the RIPE NCC.
>
> * "We’re failing closed" → this is a logical fallacy. The general
> approach with RPKI based validation is “if there is a signal to reject,
> then reject, otherwise accept”, this is fail open logic. That logic is
> not being changed. What is being changed is that there are no signals
> for these resources we’re discussing, so for those resources
> specifically we hit the default accept clause in our routing policies.
> We’re taking about adding in signals for those resources so that we hit
> the “there is a signal to reject” clause in the if statement. The
> suggestion that the logic would be changed to fail closed is simply not
> correct.
>
> * "It’s a slippery slope" → this is another logical fallacy. If we
> decide to do something because it's easy ($old_thing we did in the past
> makes $new_thing easier to achieve than it would have been, had we not
> done $old_this already), rather than deciding to do something because
> it's the right thing to do; then the problem is that we are doing
> something which isn’t the right thing to be doing, we doing something
> which is easy. We can decide to do many things because they are easy,
> they could be easy without any past work laying a foundation, that still
> doesn’t me we should do those things. We should always do things because
> we decided they are the right thing to do. If we are evaluating things
> properly, the easiness to achieve the goal has no bearing (only in
> extreme scenarios where $effort >= some absurd value).
>
> Having thought about this, I think a more water tight argument I can get
> behind is specifically the risk that comes from the extremely low
> propagation times for the RPKI; Even though I hate prefix lists, one of
> the few benefits is that there is a 24 hour window (the industry
> standard interval IMO) afforded to operators between making a mistake in
> your IRR data, and getting it fixed before the poop decorates the walls.
> And it’s a risk I have been musing on recently regarding the RPKI and
> what to do about it. I would guess that a new ROA is in the control
> plane of the major of routers in the global DFZ within about 30 minutes.
> So I think a serious risk is; if something goes wrong with RIPE’s
> automated process, *there is no time buffer to correct anything* (on
> it’s own, some sort of bug or mistake is not enough of a reason for me,
> we’re not talking about launching a rocket to mars, but it’s
> specifically the combination of a bug /mistake + near real time
> propagation).
>
> For background/context:
>
> I was musing recently on auto generating SLURM files internally, as you
> mentioned, to get rid of our static filters for all the IANA special
> allocations. And then I thought, I could include all the RIR unallocated
> stuff too. And then I thought; why are 90k networks each creating their
> own BOGON filter lists today, even though we all want the same stuff
> filtered, and as a result of so many networks having to repeat the same
> task, what a shocker, many get it wrong or just don’t do it, and even
> those that do it, do it differently. It’s a mess. Why don’t we just
> centralise this, do it once, do it right, and everyone benefits? That
> was the brain fart that let to my original mailing list post.
>
> Now what about this as a follow-up brain fart; why doesn’t the RIPE NCC
> just announce their unallocated space? No adding or removing of ROAs,
> just announce it without a ROA? It will become ROA “unknown” so it will
> be accepted, and that will disincentivise the squatters from using the
> space because it’s no longer effective. If someone buys this space from
> RIPE, RIPE stop announcing it and the new owner can announce it and
> create a ROA and go on with their day.
>
> With kind regards,
> James Bensley (he/him)
> ------------------------------------------------------------------------
> *From:* Job Snijders <job@bsd.nl>
> *Sent:* 27 July 2026 14:55
> *To:* James Bensley <james@inter.link>
> *Cc:* Routing WG <routing-wg@ripe.net>
> *Subject:* Re: [routing-wg] Re: ASPA AS0 Records for unallocated ASNs
> ⚠️ Caution: This email originated from outside of your organization. Do
> not click on links or open attachments unless you recognize the sender
> and know the content is safe.
>
> Hello James, others
>
> Thanks for asking, I'll attempt to summarize the last few years --
>
> And what happens if RIPE NCC issues a so-called 'AS0' in error?
> Lawsuits? Probably! Luckily, at present this is (nearly) impossible
> because RIPE NCC has implemented many controls to mitigate exactly that.
> Only the resource holder can create RPKI objects. However, proposals
> like these create additional, automated, pathways towards yeeting
> resources off the Internet. Proposals like these _increase_ the surface
> for bugs. I think you may be underestimating the burden of properly
> running a RPKI Trust Anchor!
>
> In the past there already have been incidents where an (accidental!)
> change in contract status resulted in automated removal of ROAs. This
> type of administrative error can happen, but a world with AS0 TALs
> instead of going from "valid -> notfound" things go "valid -> invalid".
> This is highly problematic. Why make the error path more severe?
> Proposals like these change the dynamic from "FAIL OPEN" to "FAIL CLOSED"!
>
> Which brings me to the obvious counter-question: why are you not doing
> this yourself with the existing information? Surely you can easily
> generate a SLURM file based on https://ftp.ripe.net/pub/stats/ripencc/
> <https://ftp.ripe.net/pub/stats/ripencc/>,
> right? If this type of blocklisting was so valuable, surely everyone
> would already today be converting delegated-stats into SLURMs and using
> that in production environments, right?
>
> Putting risk aside - the implementation of separate AS0 TALs also turns
> out to be a very costly and a very time consuming activity for RIR staff
> (this is the lived experience from some other RIRs). These resources
> would be much better spend on actually improving the RPKI feature set
> itself (rather than implementing gazillion extra controls to wrap around
> something dangerous). AS0 TALs are an expensive feature that doesn't
> accomplish much in the happy path and destroys confidence in the RPKI in
> the failure path. Tall order if you ask me.
>
>> So this wouldn't be given the RIPE NCC any technical capabilities they
>> don't already have.
>
> At present the 0.0.0.0/0, ::/0, AS 0 -- 4294967295 root certificate is
> unavoidable due to operational reasons. A side-effect is that quite some
> time and effort is being spend to REDUCE privileges to avoid accidental
> mishap resulting from the unavoidable absolute authority. Consider this
> analogy: you install an operating system and gain root privileges, you
> then work to set things up so that you do not do everything with your
> root privileges. Just because you _could_ elevate to root privileges
> doesn't mean you _should_.
>
>> We're also only talking about them doing it for unallocated space,
>
> Exactly... unallocated space is the least valuable space (it is not even
> allocated yet). The space becomes valuable upon allocation, the receiver
> of the space can choose to make RPKI objects (or not). The problem with
> the proposals like these is that in order to protect the least valuable
> resources all of a sudden the valuable resources end up being put at
> risk.
>
>> Please can someone spell it out for me what the reason(s) for not
>> doing this is, which outweigh the reason(s) for doing it?
>
> Please read:
>
> https://web.archive.org/web/20260416125626/https://lists.afrinic.net/
> pipermail/rpd/2021/013314.html <https://web.archive.org/
> web/20260416125626/https://lists.afrinic.net/pipermail/rpd/2021/013314.html>
> https://web.archive.org/web/20260416124914/https://lists.afrinic.net/
> pipermail/rpd/2021/013308.html <https://web.archive.org/
> web/20260416124914/https://lists.afrinic.net/pipermail/rpd/2021/013308.html>
> https://web.archive.org/web/20201217144338/https://www.ripe.net/support/
> service-announcements/rpki-roas-deleted-for-some-legacy-resources
> <https://web.archive.org/web/20201217144338/https://www.ripe.net/
> support/service-announcements/rpki-roas-deleted-for-some-legacy-resources>
> https://web.archive.org/web/20260416125539/https://lists.afrinic.net/
> pipermail/rpd/2021/013312.html <https://web.archive.org/
> web/20260416125539/https://lists.afrinic.net/pipermail/rpd/2021/013312.html>
> https://web.archive.org/web/20260416124817/https://lists.afrinic.net/
> pipermail/rpd/2021/013328.html <https://web.archive.org/
> web/20260416124817/https://lists.afrinic.net/pipermail/rpd/2021/013328.html>
>
> How many BGP announcements are there for unallocated RIPE space?
> 500? Less? Whatever it is, is that really worth spending hundreds of
> thousands of euros on to increase our collective risk? I SAY BAD DEAL! :-)
>
> Kind regards,
>
> Job
>
> ps. I consider AS0 TALs so risky that I added a protection mechanism
> in the rpki-client validator which detects AS0 TALs and automatically
> ignores them by default. In order to increase the barrier the operator
> has to explicitly enable support for AS0 TALs: https://man.openbsd.org/
> rpki-client#0 <https://man.openbsd.org/rpki-client#0>
> [CompanySignature]
> Inter..link GmbH *|* Boxhagener Straße 80, 10245 Berlin, Germany *|*
> Managing Directors: Marc Korthaus, Theo Voss *|* Commercial Register:
> Amtsgericht Charlottenburg, HRB 138876 *|* VAT ID: DE281288887 *|*
> Email: hello@inter.link <mailto:hello@inter.link> *|* Web: inter.link
> <https://inter.link>
>
> -----
> To unsubscribe from this mailing list or change your subscription options, please visit: https://mailman.ripe.net/mailman3/lists/routing-wg.ripe.net/
> As we have migrated to Mailman 3, you will need to create an account with the email matching your subscription before you can change your settings.
> More details at: https://www.ripe.net/membership/mail/mailman-3-migration/

-----
To unsubscribe from this mailing list or change your subscription options, please visit: https://mailman.ripe.net/mailman3/lists/routing-wg.ripe.net/
As we have migrated to Mailman 3, you will need to create an account with the email matching your subscription before you can change your settings.
More details at: https://www.ripe.net/membership/mail/mailman-3-migration/