Hi Andrea and thanks for the update!
This would allow for PA allocations smaller than the minimum allocation size. It is our understanding that this last point would require a policy change.
Out of curiousity, how did these come about then? ripencc|SE|ipv4|193.108.42.0|512|20010406|allocated ripencc|DE|ipv4|193.218.220.0|512|19981110|allocated ripencc|PT|ipv4|194.117.48.0|512|19941206|allocated ripencc|IT|ipv4|194.153.212.0|512|20000509|allocated FWIW, I've always considered the minimum allocation size the minimum size *that the RIPE NCC may allocate* - not the minimum allocation size that may exist in the database at a given point in time. The existence of the above four allocations appears to preclude the latter interpretation in any case. With the former interpretation PI->PA conversions for blocks smaller than the minimum allocation size is quite OK by policy, as it isn't an allocation performed by the RIPE NCC from the free pool. Besides, I can't think of any reason for having a minimum allocation size in the first place except to prevent deaggregation, but these as those PI blocks are already deaggregated that's not applicable here either. IMHO, anyway... Tore