Hello Cynthia, * Cynthia Revström
After reading denis's response I realized that I responded a bit too hastily with my +1. I am going to retract my support for this proposal as I really don't get why you would need this without the "assignment-size" attribute. I might have missed something but I can't see what possible benefit "AGGREGATED-BY-LIR" has over "SUB-ALLOCATED PA" without it. The only thing that I can think of is if you just want to just comply with the policy without providing any additional info, in which case the policy should just be updated to not require it if that is what the community wants.
The reason why we took "assignment-size" out, is that we understood its purpose (in the IPv6 policy) to be related to calculating the HD-ratio, which in turn is done to justify subsequent allocations. As I'm sure you're well aware, none of those things exist in IPv4, so there did not appear to be any purpose in keeping it in.
My reason for saying this is that some LIRs might choose to remove specific inet(6)num objects that they have already created and just create a big "AGGREGATED-BY-LIR" inet(6)num object as you can't have inet(6)num objects under it. Personally I would prefer it if an LIR just chose to document some of their assignments while leaving some undocumented over "documenting" them in a way that really doesn't specify any meaningful information.
If I have missed something and there actually is a true benefit[0] to using "AGGREGATED-BY-LIR" without an "assignment-size" attribute then do let me know.
I would really prefer if this was considered carefully before implementing it due to the potential risk of losing data currently in the database.
You include inet6num objects here, so I want to make it crystal clear that AGGREGATED-BY-LIR already exists in IPv6 and that this proposal does not in any way change it. Therefore, if there really is something to worry about here, we ought to have seen evidence of it happening already in IPv6. I am not aware of anything like that, though.
[0]: "true benefit" here referring to something beyond just making it compliant with RIPE policy as I think there are better solutions if that is the case.
We believe policy compliance is a goal worth striving for. As Gert said: «Anyone unwilling to register proper data is able to do so already today», but this requires ignoring certain requirements of the policy. This is not a hypothetical situation. As noted in the proposal text: «As of August 2023, there were 19,221 PA allocations without any child PA assignments held by 10,052 LIRs» (for the record: this data comes from the RIPE NCC, not us proposers) Our hypothesis is that a fair share of those are used for high-churn and automated small assignments (think cloud VPS instances, customer DHCP pools, etc.) which it is impractical to keep the RIPE database updated with in a synchronous manner. So they don't bother to even try to comply with the registration requirements in the policy. Another set of LIRs of unknown quantity will instead (ab)use the «solely for the connection» exception to improperly register such assignments as being part of their own infrastructure. While perhaps a lesser evil compared to the above, this approach is not compliant with the policy either. With AGGREGATED-BY-LIR, we want to provide an attainable way for such LIRs to become policy compliant. We do believe there is a "true benefit" in that. Tore