[db-wg] proposal: disallow creation of new non-hierarchically named AS-SET objects

On Tue, 29 Nov 2022 at 20:44, Nick Hilliard <nick at foobar.org> wrote:
>
> Cynthia Revström wrote on 29/11/2022 18:56:
> > I agree with Nick.
> > However there are currently as-set objects in RIPE based on aut-num
> > objects in RIPE-NONAUTH.
> > I think it might be worth considering if these should be cleaned up.
> > I posted about this about a week ago in a separate thread on db-wg.
>
> right, yes, you're correct.  I've included a list below.
>
> The RIPE NCC can't stand over the authenticity of these objects because
> the AS in question isn't a RIPE-authenticated ASN. So RIPE-NONAUTH would
> be an appropriate place for them.
>
> Changing this should not be service affecting, because the AS in
> question is already RIPE-NONAUTH.  Having said that, "should not" is not
> the same as "will not".
>
> Some of these objects are stale.
>
> Some of them are legacy resources, but can be subject to the same
> approach as defined in ripe-731.
>
> Do we need a policy change to move these, e.g. similar to ripe-731, or
> simply including them in the scope of ripe-731?

The policy ripe-731 is all about deleting objects that conflict with
RPKI. So I don't see this issue being a part of the same scope.

However, RIPE-NONAUTH is considered to be a separate IRR registry,
even if the objects are physically in the same database. As a
community we can argue that it is logical that if an ASN in the
registry RIPE-NONAUTH authorises the creation of an AS-SET object,
that new object must be located in the same registry. So putting these
previously created AS-SET objects in the RIPE registry was a bug. We
can therefore fix this bug and move these objects to the correct
registry. I don't see that needing a policy. We can add it to NWI-19.

Thoughts???

cheers
denis
co-chair DB-WG

>
> Nick
>