I have just been informed that AS-AMAZON in the RIPE DB is indeed causing issues for Amazon currently, so please disregard that question.
-Cynthia On Fri, Nov 25, 2022 at 12:20 AM Cynthia Revström <[email protected]> wrote: > > 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 <[email protected]> > 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
