[db-wg] RIPE Policy Proposal 2018-06 Aims to Delete Conflicting Non-authorative IRR Objects

Dear Alexander,

On Mon, Oct 15, 2018 at 06:21:09PM +0300, Alexander Azimov wrote:
> Why don't delete RIPE-NONAUTH at all?

That is fine by me - but I think this community may appreciate a softer
landing. Deleting the data-set resolves a number of concerns, but I'm
also happy to just clean it up using superior data sources such as RPKI.

> If there is no legal use of it - there is no need to maintain it.  If
> there are legal use cases - you would create unpredictable operational
> problems, when the customer will set up an ROA, forgetting for a
> moment that provider is advertising its prefix for him, then he will
> fix ROA - but the route object will be already gone.
>
> You have NTTCOM to register objects for your customers, some other
> Tier1 telcos also have similar service.  The lock of RIPE-NONAUTH and
> this policy forces smaller ISPs to pay an additional fee to RADB.

"forces smaller ISPs to pay" is absolute nonsense! Please *precisely*
explain the scenario in which your statements hold true.

Do RIPE, AFRINIC, APNIC and ARIN not provide a *FREE* IRR service to
their stakeholders? LACNIC offers RPKI ROA services which are mirrored
into the NTTCOM IRR, and they are working on doing this natively. If you
are not authorised to create a route object, and thus can't create a
route object - that is a feature! That is precisely why the security
model exists.

> I agree with the idea to drop (freeze) 'invalids', but only if you are
> able to restore 'valids'.

Why? RIPE NCC is chartered to serve the RIPE region - not chartered to
facilitate hijacks and negative effects of misconfigurations related to
resources owned by entities outside the RIPE region.

If you'd like RIPE NCC to offer unvalidated 'RADB' style services, feel
free to bring a proposal to the RIPE Services Working Group!

Kind regards,

Job