On Tue, 29 Nov 2022 at 20:44, Nick Hilliard <nick@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