On Tue, 29 Nov 2022 at 20:44, Nick Hilliard <[email protected]> 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 > -- To unsubscribe from this mailing list, get a password reminder, or change your subscription options, please visit: https://lists.ripe.net/mailman/listinfo/db-wg
