Tore

Thanks for the clear explanation of the use case. The proposal seems to be “sane” so, unless somene can point out a fundamental flaw with it, we’d be supportive.

Regards

Michele

--

Mr Michele Neylon

Blacknight Solutions

Hosting, Colocation & Domains

https://www.blacknight.com/

https://blacknight.blog/

Intl. +353 (0) 59  9183072

Direct Dial: +353 (0)59 9183090

Personal blog: https://michele.blog/

Some thoughts: https://ceo.hosting/

-------------------------------

Blacknight Internet Solutions Ltd, Unit 12A,Barrowside Business Park,Sleaty Road,Graiguecullen,Carlow,R93 X265,Ireland  Company No.: 370845

I have sent this email at a time that is convenient for me. I do not expect you to respond to it outside of your usual working hours.

From: address-policy-wg <address-policy-wg-bounces@ripe.net> on behalf of Tore Anderson <tore@fud.no>
Date: Monday, 4 September 2023 at 12:21
To: Andrii Syrovatko <andrey_syrovatko@trifle.net>, address-policy-wg@ripe.net <address-policy-wg@ripe.net>, adallara@ripe.net <adallara@ripe.net>
Cc: APEX NCC ORG <registry@apex.dp.ua>, Trifle NOC <noc@trifle.net>
Subject: Re: [address-policy-wg] 2023-04 New Policy Proposal (Add AGGREGATED-BY-LIR status for IPv4 PA assignments)

[EXTERNAL EMAIL] Please use caution when opening attachments from unrecognised sources.

* APEX NCC ORG

> Hello, Team!
> I read the offer provided:
> https://www.ripe.net/participate/policies/proposals/2023-04
> three times.
> However, I still don't understand the real reason for introducing the
> AGGREGATED-BY-LIR status
> The text of the proposal contains only general provisions.
> Can you provide a more detailed description and examples?

Hi Andrii!

There are several possible examples, but let me give you just one:

Let's say you're a small cloud VPS provider in the business of leasing
out virtual machines to small businesses and private individuals. Your
cloud management software dynamically assigns IPv4 addresses out of
192.0.2.0/24 to customers, so you have for example:

192.0.2.1/32 = assigned to Alice's first VM - used for a web server
192.0.2.2/32 = assigned to Bob - used for a Minecraft server
192.0.2.3/32 = assigned to Bob's hair salon business = web server
192.0.2.4/32 = assigned to Alice's second VM - mail server

…and so on.

Current policy requires you to register four individual INETNUM
assignments of size /32 for the above four virtual machines.

However, due to the GDPR requirements, you usually cannot put Alice's
and Bob's names or contact info into the RIPE database, so instead you
typically substitute your own (this is allowed by policy).

That means you have now four individual INETNUMs with identical contact
information (your own). You need to add or remove these /32 INETNUMs as
customer VMs come and go. You can automate this, but it is a pointless
exercise in any case.

To avoid this, we propose allowing you to create a single INETNUM that
covers the entire 192.0.2.0 - 192.0.2.255 range, just like you can
already do with any IPv6 assignments made to the same VMs. This
aggregated object will cover all customer VMs in your cloud
infrastructure, present and future, and makes it so that you don't have
to send a RIPE database update every time a customer VM is provisioned
or discontinued.

Tore

--

To unsubscribe from this mailing list, get a password reminder, or change your subscription options, please visit: https://lists.ripe.net/mailman/listinfo/address-policy-wg