Hi Yang On Wed, 16 Nov 2022 at 11:06, Yang Yu <yang.yu.list@gmail.com> wrote:
I support this proposal.
It seems Amazon has no recourse to get the AS-AMAZON object removed from the RIPE database; because the existence of that object in the RIPE database does not violate any policies (as far as I know).
Also ran into this issue and would like to see policy support to handle this kind of abuse.
On Mon, Nov 14, 2022 at 3:08 PM denis walker via db-wg <db-wg@ripe.net> wrote:
Interesting timing. I was about to make the same suggestion but for a different reason...accountability. Currently ANYONE can create a set object in the RIPE Database. You can be completely anonymous, not a member or LIR, hold no resources. All you need to do is create a ROLE, MNTNER and set object.
Anyone with an email can make a RIPE account and start creating objects in RIPE database. In other registries there are usually some safeguards on user / mntner object creation. Limiting database updates to only accounts associated with LIR sounds reasonable.
It is not quite as open as you think. Someone with nothing at all in the database can create a ROLE/MNTNER pair of objects. If these are not referenced by any operational data within 90 days they will be automatically deleted. So if you don't hold any internet resources, or more specifics, there is not much you can do in the database. The one exception to this is with the set objects. Anyone can create any of the set object types and reference their ROLE and MNTNER objects. This group of objects is then protected from any automated cleanup. The set object can be almost empty with only the mandatory, basic attributes. This does not only apply to the AS-SET but any of the set object types. I did ask a question and although the answer is implied from some of the comments made, from a database perspective, if you want the syntax rules changed someone needs to positively confirm or deny my question. Is there any legitimate reason for anyone to create a (short named) set object who does not hold an ASN resource? Only if the answer is no, can we enforce hierarchical naming. cheers denis co-chair DB-WG
Yang