On Thu, 31 Oct 2024 at 17:04, Gert Doering <[email protected]> wrote: > Hi, > > On Thu, Oct 31, 2024 at 04:59:34PM +0100, denis walker wrote: > > On Thu, 31 Oct 2024 at 15:23, Gert Doering <[email protected]> wrote: > > > On Thu, Oct 31, 2024 at 01:24:45PM +0100, denis walker wrote: > > > > An LIR with an allocation can now simply split that allocation in > half > > > > and create two objects with status 'aggregated-by-lir'. The boundary > > > > between the two aggregations does not even need to match the > > > > boundaries of any more specific ranges. There are NO rules about > using > > > > this status. Absolutely nothing else more specific to these > > > > aggregations needs to be documented in the RIPE Database, in any > > > > public domain or notified to the RIPE NCC. The LIR may make a > > > > sub-allocation of, say, a /24 below one of these aggregations. Or > > > > maybe below both of them, crossing the boundary. > > > > > > Denis, you are talking nonsense. There are very clear rules what > > > can be under AGGREGATED-BY-LIR (namely, ASSIGNED, with the same > > > contact data). Not SUB-ALLOCATED. > > > > Where are these rules? > > The policy proposal that introduced AGGREGATED-BY-LIR was very clear > on the circumstances where it can be used.
The proposal text is irrelevant when it comes to actual policy. But in any case it wasn't clear. In fact it was very misleading. > I'm fairly sure you know > whether these have made it to policy text, so asking me to go chasing > the details would be wasting my time. > I will save you the time and I won't bore you with an analysis of the actual policy text. But the policy text does not prohibit a hierarchy like this: allocated pa aggregated-by-lir sub-allocated pa sub-allocated pa assigned pa It can be argued they all use the LIR's contact details and purpose has never been publicly documented anywhere. > > But you missed the two major points in my e-mail: please accept that > you have been considered to be in the rough on 2023-04 and stop > complaining. I was in the rough with the brexit referendum. The outcome and the implementation still have negative consequences. I do accept that both brexit and 2023-04 were declared by consensus. In both cases by a very small number/percentage of people. > If you want to actually *change* the situation (like, > having more detailed documentation, rules, requirements), your approach > is not the way to achieve anyhting. > The only way to (partially) fix what it broke is by another policy change to build in clear rules on hierarchical structure. In the past such detail was handled by the business rules built into the database software, based to some extent on the RIPE NCC's understanding of what was intended. Sometimes the NCC asked for clarification from the community and built that into the software rules. But software rules cannot be applied to what is not there. We are now talking about potential 'hidden' data structures. With no clear rules on the hierarchy in the policy text and the option to hide the structure you have set up, there is no public scrutiny of what people may do. When law enforcement is chasing the End User along a chain of sub-allocations, they can all argue they are policy compliant. Even if we fix the policy text and prohibit sub-allocations more specific to aggregations, it still doesn't stop anyone from creating an invalid hierarchy that will go unnoticed for a long time as it is hidden from public view. RIPE policy is not law. The address space can be revoked for policy violation. But that doesn't help to find a criminal End User. Probably none of the intermediates with the sub-allocations have commited a crime. They just violated RIPE policy. When the whole hierarchy had to be documented in the RIPE Database you would be able to jump straight to the End User or the one less specific sub-allocation holder. If that data was incorrect, whoever entered it could be accused of helping a criminal to evade justice. Which may be a crime. It has been argued we are doing nothing different to what we have done for a long time with IPv6. But I believe most crime is still done using IPv4 addresses. So it is a different situation. There is no doubt that aggregation of IPv4 addresses has created some problems, especially for law enforcement and rights enforcers. As an audience speaker said this morning, the EU/EC is looking at legislation. We ignore these issues at our peril... cheers denis > > Gert Doering > -- NetMaster > -- > have you enabled IPv6 on something today...? > > SpaceNet AG Vorstand: Sebastian v. Bomhard, Ingo > Lalla, > 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 >
----- To unsubscribe from this mailing list or change your subscription options, please visit: https://mailman.ripe.net/mailman3/lists/db-wg.ripe.net/ As we have migrated to Mailman 3, you will need to create an account with the email matching your subscription before you can change your settings. More details at: https://www.ripe.net/membership/mail/mailman-3-migration/
