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] Fwd: IPv4 waiting list policy
- Next message (by thread): [address-policy-wg] IPv4 waiting list policy
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Marco Schmidt
mschmidt at ripe.net
Thu Dec 16 16:57:14 CET 2021
Hello Denis, Thank you for your questions. Allow me to answer as many as I can right now. As you indicated, getting the data for some of the requests in your email from 9 December would require quite some time and effort. Considering that Registry Services is currently in the busiest time of the year, I would prefer to first identify if this data would really be beneficial for the ongoing discussion about the IPv4 waiting list policy and potential policy proposal. For example, you asked if some members with 10+ LIR accounts are brokers or are from a certain country. What I can say is that these members are quite diverse. They are located in several countries inside and outside of our service region. Some of these 98 organisations only became members in the last two years, while others opened multiple LIR accounts in the past several years and so received multiple /22 IPv4 allocations under the former "Last /8” policy, and later /24 IPv4 allocations under the current policy. Those members received around 1,100 /22s between September 2012 and November 2019, when the "Last /8" policy was in place. As for your comments about consolidations, I would like to clarify that the RIPE NCC uses this term when a member consolidates some of their LIR accounts into another LIR account. When an LIR receives resources that are restricted by a holding period, those resources must be kept in that LIR account until the holding period has passed. After that 24-month period, these members usually decide to consolidate their LIR accounts, including their resources. If a company were to take over one of its child companies, this would be processed by the RIPE NCC as a merger of two different legal bodies. To provide some more numbers, besides the 98 members that hold 10 or more accounts, we currently have 112 members that hold between 5 and 9 LIR accounts. The maximum amount of /24 allocations that a single member has received under the current policy is 33. So far, no allocations received under the current waiting list policy have been transferred due to the fact that the first such allocation was provided around 24 months ago and almost all allocations are still within their holding period. I hope this answers most of your questions. Kind regards, Marco Schmidt Assistant Manager Registry Services RIPE NCC On 14/12/2021 14:20, denis walker wrote: > 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 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/> Facebook icon > <https://www.facebook.com/albanianhosting> Twitter icon > <https://twitter.com/albahost> Instagram icon > <https://www.instagram.com/albahost_vpn/> > 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/20211216/3eae973d/attachment.html>
- Previous message (by thread): [address-policy-wg] Fwd: IPv4 waiting list policy
- Next message (by thread): [address-policy-wg] IPv4 waiting list policy
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]