This archive is retained to ensure existing URLs remain functional. It will not contain any emails sent to this mailing list after July 1, 2024. For all messages, including those sent before and after this date, please visit the new location of the archive at https://mailman.ripe.net/archives/list/address-policy-wg@ripe.net/
[address-policy-wg] IPv4 waiting list policy
- Previous message (by thread): [address-policy-wg] IPv4 waiting list policy
- Next message (by thread): [address-policy-wg] IPv4 waiting list policy
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Florian Fuessl
flo at degnet.de
Tue Dec 14 14:34:10 CET 2021
In order to prevent resource allocation abuse like these examples, RIPE should introduce a significant one time fee for resource transfer(s) due to LIR membership mergers or acquisitions. In case the LIR member being merged or acquired can verify reasonable network activities (not just collecting IPv4 resources for the sake of making profits later), this one time fee will be deductible from the LIR membership fees of the buyer in the upcoming years. So it should not have any effect on reasonable transactions due to mergers or acquisitions but block making profits for IPv4 traders. -Florian > > 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 >
- Previous message (by thread): [address-policy-wg] IPv4 waiting list policy
- Next message (by thread): [address-policy-wg] IPv4 waiting list policy
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]