Hi, On Tue, Jun 03, 2025 at 02:51:54AM +0200, denis walker wrote:
If it was a week's work for 2 engineers to build some complex solution I would probably agree with you. But in reality, to set a limit would probably be a couple of lines of code and maybe 2 test cases in the test suite. You can always make a case for "why bother to set limits on anything?" But do we want anyone to be able to mess up the DB intentionally, or with a script that went wild, and create hundreds of these objects? When a couple of lines of code would cap it at a reasonable level. I see it as tidying up loose ends while reviewing the status rules.
I find it very unlikely that a script-went-wild would create "hundreds" of *deeply nested* objects. Now, a script-went-wild that creates thousands of leaf-level inetnum: objects ("let's just sync all IPv4 /32 from our IPAM to the RIPE DB") is somewhat likely - but this won't be stopped by introducing limits on the nesting level of sub-allocations. Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard, Karin Schuler, Sebastian Cler Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279