[address-policy-wg] 2023-04 New Policy Proposal (Add AGGREGATED-BY-LIR status for IPv4 PA assignments)

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