Hi Denis, While I agree with your goal of trying to clean up the DB more generally, I think all of the more general issues have to be left for another time as I don't think that is appropriate for a NWI and should be done through the PDP. I think we should purely tackle the issue of as-sets for now as I think there is enough unanimity in it and it is small enough in scope that it makes sense to do it through the NWI process. (I think the main person raising any objections was myself) I have a question though, do we know if all current hierarchical as-sets were authorized by the ASN holder when they were created? I wrote the above question and then I looked into it, but as it is a bit off-topic and some other things that popped up, I decided to put it in a separate thread. The TL;DR of it though is that, I am pretty sure that the answer is no. There are at least some that weren't authorized. Another issue is how to deal with the short as-sets that already exist and are potentially causing issues. Just as an example, I can see that there is currently an AS-AMAZON in the RIPE DB that I assume was not authorized by Amazon and looks to not have any good reason to exist (no members). I think having a way for trademark holders and well-known entities to deal with dubious as-sets would be good. Maybe just during a limited time period to prevent any future uncertainty. -Cynthia On Sat, Nov 19, 2022 at 4:01 PM denis walker via db-wg <db-wg@ripe.net> wrote:
Colleagues
I know it is a weekend but there does seem to be some urgency on this matter. The chairs have been following this discussion and have a couple of questions before we move on.
The chairs believe we can consider this to be a feature request for the RIPE Database and handle it through the Numbered Work Item (NWI) mechanism. This will address the matter much faster, unless anyone believes it should be based on a formal policy.
To assist the RIPE NCC with their impact analysis can we be clear on how you want to change the syntax. My understanding is you want rules along these lines:
-An AS-SET name must be hierarchical -There must be at least one colon (:) character in the name -The first element of the name must be an ASN -The second element of the name must be an AS-SET name starting with 'AS-' -Any further elements can be either ASNs or AS-SET names -Any other existing syntax rules that don't conflict with this change -These rules to only apply to creating new AS-SET objects -Existing non-hierarchical AS-SET objects can still be updated
This discussion has focused on the AS-SET object and the authorisation problems they can cause. Should we make this change to all set object types? The benefits of doing this include:
-Consistent rules applied to all set object types -Accountability for all (new) set objects in the database -Close the one exception where anyone can create a cluster of objects in the database and link them to a (operationally empty) set object to protect them from automated deletion -Objects can then only be created in the database by holders of Internet resources or more specifics
If we apply it to all set objects then my original question still stands, is there any legitimate reason for someone to create any set object if they don't hold an ASN resource?
If we can address these issues then the chairs can move this process on quickly at the start of next week.
cheers denis co-chair 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