[address-policy-wg] 2023-04 Review Phase (Add AGGREGATED-BY-LIR status for IPv4 PA assignments)

Hi James,

Thank you for your message.


> I always understood them as a way of recording who/what was using a piece of address space so that you can contact the right organisation in the case of an issue. In this case, there were explicit carve-outs for blocks of dynamic address space so that the ISP could be contacted to determine who was using that particular piece of address space at a single time.
> 
> Where address space was allocated on a more permanent basis the contact details of the end site would be added so the organisation who was trying to address the problem had a direct route to contact that end network.

I think in cases of the AGGREGATED-BY-LIR it will be used for LIRs that are also something like an ISP. LIRs that delegate their prefix to another entity would use sub-allocated pa for doing this. Personally, I prefer as an LIR/ISP to use our contact information in the assignments that we also delegate to customers this is because I value knowing what is going on by our customers in matters of technical problems and abuse cases that are using our network and IP space. I am convinced that in this way, we can advise and help our customers better and also solve the problem sooner.


> From a technical point of view, it was useful as a reference to be able to work out if several IP addresses in a subnet had been allocated to the same customer or if there was a wider issue. This means that having the assignment size fixed for each block and included in the RipeDB entry is rather important.

Is it possible to give a detailed example of this?


> This policy appears to take the standard approach for IPv6 and apply it to IPv4 (this is a good thing) it will reduce the number of individual entries in the system (neutral) and hopefully increase the accuracy (a good thing) but at the loss of explicitly including the contact details of the end user site and replacing it with a contact for the LIR (neutral). The last step appears to be the most controversial as it stops people from going directly to the source as it were.
> 
> I think the operational impact here is a potential issue, some LIRs are less than stellar in dealing with requests about things listed in the RipeDB (mostly because of spam) so I can see the concern that some have raised about not being able to get hold of people. However that's not a Ripe issue explicitly but rather a function of the world of capitalism (it's free to send an email, let's send lots of emails, we only need a few people to respond to make money...) 
> 
> If we want to fix this problem then maybe we need to add a new capability onto the db that allows authenticated users to contact LIRs about their address space (without using the published contact details) in a way that would allow anti-abuse and LEAs to access the information they need, that is very much not something that needs discussion in the WG because were here to talk about address policy.

It would be good if some research would be done on your point of why LIRs become less stellar in dealing with the requests. Is it indeed because of the spam or just because the abuse department is an easy thing to save money on? In both or other cases it is good to see what we can do to improve the situation. I think that AGGREGATED-BY-LIR won’t affect this because a customer next to being portably less technically capable, can just as good save money on their abuse department or be annoyed by the spam as the LIR. 

> This policy is optional...
> 
> I think people have missed this, from my reading an LIR is not prevented from continuing to put entries without marking them as aggregated so from that point of view if you want to continue to include customer details (and you have their consent) you can still do it.

Yes, indeed it is optional.


Regards,

Jeroen and Tore.