[address-policy-wg] IPv4 waiting list policy

Hi Guys

I have some more questions now as I dig deeper into these allocations.
Marco mentioned in his email that the situation is quite fluid because of
consolidations, transfers, and opening of new LIR accounts that occur all
the time. I have found the transfer information, where can I find details
of consolidations? Also is the waiting list published anywhere? I have seen
companies with say 25 LIRs where 22 have already received a /24 this year.
I would like to know if the other 3 LIRs are on the waiting list and at
what position.

Now I have some detailed questions about what is meant by consolidation. I
will illustrate with an anonymous example. For all my analysis I will not
identify any company by name. My intention is to expose behaviour.

So we have a parent company ABC Networks BV. They set up 5 child companies.
One in 2017 and 4 in early 2019. One of them is XYZ Networks BV.

XYZ networks BV opens 12 LIRs. Throughout 2019 each of these LIRs receive a
/22 allocation. In December 2019 all these LIRs/allocations moved to the
parent company ABC Networks BV and the child company XYZ Networks BV was
deregistered according to the Chamber of Commerce.

In total the 5 child companies opened 50 LIRs. They each received a /22
throughout 2019 and all these child companies were deregistered in December
2019 with their LIRs/allocations 'transferred' to the parent company. Is
this what is meant by consolidation? Not sure what the business case is to
register several companies who open several LIRs each to get allocations,
then close the companies a few months later and merge all the resources
into the parent company...unless it is to try to hide the true number of
LIRs the parent company has set up.

The timing is also interesting. All of these child companies were merged
with the parent company on 2 December 2019, according to the Chamber of
Commerce:
"Merger deed passed on 02-12-2019. Acquiring legal entity: ABC Networks BV
Disappearing legal entities: XYZ Networks BV..."
The child companies were then all deregistered on 5 December 2019,
according to the Chamber of Commerce:
"As of 5-12-2019, the legal entity has been deregistered due to Termination
of registration"

According to the Transfer Statistics the date of the transfer of the
resources was 23 December 2019 from the child company XYZ Networks BV to
the parent company ABC Networks BV. The ORGANISATION objects in the RIPE
Database were also modified on 23 December 2019 to change the "org-name:"
to that of the parent company ABC Networks BV. But the child company XYZ
Networks BV did not exist on 23 December 2019. So was this a valid
transfer? This applies to all 50 of the allocated resources to these child
companies's LIRs.

I suspect that when the merger took place on 2 December 2019 the parent
company took legal ownership of the assets of the child company, including
the LIR accounts with the allocated resources. That means the transfer
actually took place on 2 December 2019, not the 23 December 2019 as stated
in the Transfer Statistics. That makes the Transfer Statistics wrong. If
this is meant to be a legal document that is not good. Something needs to
be tightened up here. Maybe it is a chicken & egg situation. The merger has
to legally occur and documents supplied to the RIPE NCC before the transfer
can be acknowledged. But then the transfer stats should make it clear the
transfer actually took place on 2 December when the merger occurred, not
the date it was acknowledged by the RIE NCC on 23 December.

It is also not clear to me what has actually been transferred/acquired? Is
it the allocations or the LIR accounts with the allocations? In the
delegated stats there still exists several entries for nl.xyz1, nl.xyz2,
etc. These all refer to the legal name of the parent company ABC Networks
BV. Does this mean the parent company has taken control (acquired) all 50
of these LIR accounts with their allocations, not just the allocations? Is
this still a consolidation?

Another general question. When a whole resource is transferred (within RIPE
region) it looks like the RIPE NCC deletes and recreates the allocation
object in the RIPE Database with 'todays' date as the creation date. But
the entry in the delegated stats keeps the original allocation date. Is
this how it is meant to be documented? (A good example of why a historical
query in the RIPE Database should show the full history.)

None of this is explained very well, or at all, in the policies or
documentation. It assumes people know a lot more about this registration
stuff than a database expert does (but I am learning). If someone can
answer these points it may well help some of the new LIRs as well. I am
sure there is a steep learning curve here for the newbies.

cheers
denis
co-chair DB-WG

On Mon, 13 Dec 2021 at 17:17, Albanian Hosting SH.P.K. via
address-policy-wg <address-policy-wg at ripe.net> wrote:

> Hey Denis Walker,
>
> in 2019 until the end of december the last /22 allocation was assigned to
> the members/Lirs, once the ripe stopped assigning /22, there was not that
> much interest in 2020 for only a /24 subnet. And no, it was not free! Since
> in 2021 the price per IP skyrocketed, and ripe announced that they are out
> of stock, due because of this and due because the price per IP is going to
> the moon, the LIRs (mostly big boys) with multiple allocations started to
> apply for more and believe me they are making a good profit from this. For
> now is 200€/month is the price for /24 subnet to rent out, and it will be
> higher and higher.
>
> Cheers.
>
> --
> *Sinqerisht / Sincerely,*
> AlbHost [image: Logo] <https://www.albahost.net/>
>
> Albanian Hosting SH.P.K.
> Besim Beka p.n.
> 50000 Gjakovë, Kosovë.
> NIPT/VAT ID: 811442657
> T: +386900501502
> E: info at albahost.net
>
> W*: *wWw.AlbaHost.Net <http://www.albahost.net/> [image: Facebook icon]
> <https://www.facebook.com/albanianhosting>   [image: Twitter icon]
> <https://twitter.com/albahost>   [image: Instagram icon]
> <https://www.instagram.com/albahost_vpn/>
>
> [image: Banner]
>
>
> Përmbajtja e këtij emaili është konfidenciale dhe ka për qëllim marrësin e
> specifikuar vetëm në mesazh. Ndalohet rreptësisht shpërndarja e ndonjë
> pjese të këtij mesazhi me ndonjë palë të tretë, pa pëlqimin me shkrim të
> dërguesit. Nëse e keni marrë këtë mesazh gabimisht, ju lutemi përgjigjuni
> këtij mesazhi dhe ndiqni me fshirjen e tij, në mënyrë që të sigurohemi që
> një gabim i tillë të mos ndodhë në të ardhmen.
>
> The content of this email is confidential and intended for the recipient
> specified in message only. It is strictly forbidden to share any part of
> this message with any third party, without a written consent of the sender.
> If you received this message by mistake, please reply to this message and
> follow with its deletion, so that we can ensure such a mistake does not
> occur in the future.
>
>
> --
>
> To unsubscribe from this mailing list, get a password reminder, or change
> your subscription options, please visit:
> https://mailman.ripe.net/
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </ripe/mail/archives/address-policy-wg/attachments/20211214/081eadcc/attachment.html>