[db-wg] Further cleanup (was: RIPE NONAUTH route(6) objects using unregistered space cleanup - deployment *today*)

Hi Working Group,

I'd like to clarify my position, Ronald lists three restrictions, the
totality of those restrictions is what I consider brittle.

On Tue, Jul 06, 2021 at 06:57:20PM -0700, Ronald F. Guilmette via db-wg wrote:
> Who is insisting that the RIPE data base should be effectively endorsing
> the *public* use of ASNs that are reserved, and that have been reserved,
> by various RFC(s), since time immemorial (e.g. 65535)?

Preventing object creation where the origin AS is any of the following 

    0                       # RFC 7607
    23456                   # RFC 4893 AS_TRANS
    64496..64511            # RFC 5398 and documentation/example ASNs
    64512..65534            # RFC 6996 Private ASNs
    65535                   # RFC 7300 Last 16 bit ASN
    65536..65551            # RFC 5398 and documentation/example ASNs
    65552..131071           # RFC IANA reserved ASNs
    4200000000..4294967294  # RFC 6996 Private ASNs
    4294967295 		    # RFC 7300 Last 32 bit ASN

seems reasonable to me, I believe that in the Hosted RPKI environment similar
restrictions apply.

However, the following two restrictions are not optimal in my opinion.

> Who is insisting that the RIPE data base should be effectively endorsing
> the *public* use of ASNs that have -never- been assigned by any RIR to
> any party?
> 
> Who is insisting that the RIPE data base should be effectively endorsing
> the *public* use of ASNs whose registrations have been revoked by the
> applicable RIR, e.g. due to either the non-payment of fees, or worse,
> due to outright fraud on the part of the relevant registrant?

For me this style of anthropomorphistic writing makes dialogue harder,
for example the RIPE database lacks the ability to 'endorse' anything.

Kind regards,

Job