Based on what has been said in this thread so far, I cannot support automatic clean-up of AS-SETs even if they are empty. There is simply way too little to be gained compared to the issues it could cause. Also if there is someone who maliciously created a short AS-SET, they could simply just add an ASN into it to exclude it from automatic clean-up.
It might be complicated but I really think the better way to go about it is to handle each of the individual cases in which this is an issue as I suspect that there are not many and they are probably pretty clear cases. I know of AS-AMAZON but are we aware of any other potentially problematic AS-SETs in the RIPE DB currently? Also I don't even know if it is currently causing issues for amazon, but maybe Fredrik could answer that? -Cynthia On Thu, Nov 24, 2022 at 4:14 PM Nick Hilliard via db-wg <db-wg@ripe.net> wrote: > > Niall O'Reilly via db-wg wrote on 23/11/2022 18:17: > > What I have in mind is AS-NIALLSPECIAL, which I populate with a list of > > AS numbers which I want to advertise to let others know that these > > are to be handled in some special way, unlike those in AS-NIALLNORMAL. > > > > According to operational circumstances, there might be periods, even > > long ones, with nothing special going on; AS-NIALLSPECIAL would then be > > empty, but only for as long as this continued to be the case. > > this ^^^ is one of the failure modes. > > It would not be safe to assume that empty as-sets named in RPSL policies > are unused. It would be less unsafe to assume that unreferenced as-sets > are unused. A reasonable middle ground might be - after the proposed > new unqualified as-set block has been implemented - to check out all > unreferenced as-sets older than a specific period of time and flag those > for deletion. > > It would also be worthwhile inspecting rpsl in other IRRDBs to see if > there are any references. The reason for this is that lots of people > use tools like bgpq3 / peval / etc, and query aggregate IRRDBs, e.g. > RADB, NTT, etc. > > So if you have RPSL in another IRRDB and this references an empty as-set > in the RIPE IRRDB, that definition may be picked up in preference to > other as-set definitions. I.e. by removing an as-set definition in the > RIPE IRRDB, it could unexpectedly influence routing policies elsewhere. > > These are corner cases, but they should show why some care will be > needed to figure out whether deleting these objects is a good idea. > > 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 -- 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
