There is a catch, 20 LIRs cannot be merged into a single LIR of the new parent company, unless it has passed 2years from the /24 allocation date. So after the merge, the new parent company still has to pay for 20 LIRs till the time /24 can be transferred,
Regards, Arash >>So merging a shell company with 20 LIRs, each with a /24, with the parent company with a single LIR, allows those 20 /24s to be registered with the single LIR of the parent company and closure of the 20 LIRs. On Thu, Dec 23, 2021 at 2:01 AM denis walker <[email protected]> wrote: > Colleagues > > The Transfer Policy ripe-682 is so vague you can drive a train through > the holes in it. I have some questions that I hope someone can answer > before Christmas as I would like to propose an amendment to this > policy in the new year. > > "Any legitimate resource holder is allowed to transfer" > What does 'legitimate' mean in this context? It is not defined in this > policy document. It is no use referring to a dictionary or even some > other policy document. It needs to be defined in this policy. If it > has no specific meaning in the context of this policy, then the word > should be removed. > > My understanding of a 'policy document' is that it is self contained > and consistent. None of the terms: > -RIPE NCC Member > -LIR > -Resource holder > are defined anywhere in the Transfer Policy or ripe-733, IPv4 > Allocation... A policy may be dependent on another policy being in > place. You cannot transfer a resource unless it has been allocated. > You cannot allocate a resource unless there is a RIPE NCC Member and > an LIR. But you should not have to backtrack through a whole sequence > of documents to find out what a term in this policy means. This policy > can only work if people understand 'commonly accepted' definitions of > these terms. But that is open to interpretation and mis-understanding. > That could make legal enforcement of, for example, restrictions more > difficult to apply. > > [As a side issue I have just quickly read through a whole series of > documents and forms on becoming a RIPE NCC Member and getting > resources. In every document/form I found: > -Legal errors > -English grammar errors > -Procedural errors > -Webpage errors > The whole process is a complete mess and needs a serious Legal/Comms > review.] > > I found the definition of a Member in one document but nowhere have I > found any definition of LIR. These terms are so fundamental to all > these policies, to not define them leaves a massive hole in their > meaning and authority. These terms seem to be so interchangeable from > one paragraph to the next. In some places the wrong term is used. > > ripe-733 says allocations are made to LIRs > ripe-682 says allocations are transferred to members > ripe-682 says transfer restrictions apply to resource holders > > Then we have this document > > https://www.ripe.net/manage-ips-and-asns/resource-transfers-and-mergers/transfer-of-ip-addresses-and-as-numbers > which talks about 'hodership', another term not defined. > > Then we have this document > > https://www.ripe.net/manage-ips-and-asns/resource-transfers-and-mergers/transfer-of-ip-addresses-and-as-numbers/transfers-in-the-ripe-ncc-service-region > that conflicts with the Transfer Policy. > It also refers to Members as organisations, again without any actual > definition. > > The above document says: > "Exception: For transfers between multiple LIR accounts belonging to > the same organisation, also referred to as consolidations, the 24 > months restriction will only apply once after the resources were > received from the RIPE NCC or from another organisation." > > This is NOT what the Transfer Policy says. The policy makes no mention > anywhere of consolidation. The only definition we have of a transfer > in any POLICY is this one line: > "Allocated resources may only be transferred to another RIPE NCC member." > This does not even make sense. A Member cannot 'hold' a resource. > Resources are held by Member LIRs. So if a resource is transferred to > a Member with 5 LIRs, which one receives it? Does it matter? Is it > whichever LIR the Member writes on the transfer request form? > > Now a consolidation is not a transfer. In the policy a transfer is > defined as moving a resource to 'another Member'. So consolidating a > resource by moving it from one LIR to another LIR of the same Member > is by policy definition, not a transfer. So consolidation is not > subject to Transfer Restrictions because it is not a transfer. > > So all the shell companies that have been set up this year to hoover > up the last /24s can now be merged with their parent company and then > all the /24s can be consolidated into one LIR. The other LIRs can then > be closed. Nothing in this policy document says a /24 allocation must > remain for 24 months with the LIR that it was allocated to. It says it > cannot be transferred, but mergers are allowed and consolidation is > not a transfer. > > This is even confirmed in a procedural document ripe-758, Transfer of > Internet Number Resources... (which doesn't appear to be policy) > "Internet number resources that are subject to transfer restrictions > imposed by the RIPE Policy "RIPE Resource Transfer Policies", and that > are transferred due to a change in a member's business structure, must > either remain registered with the original LIR account or be > registered with a new LIR account." > > So merging a shell company with 20 LIRs, each with a /24, with the > parent company with a single LIR, allows those 20 /24s to be > registered with the single LIR of the parent company and closure of > the 20 LIRs. > > Also ripe-758 introduces yet another term, parties, without any > definition or clarity. > > This whole transfer process is totally confused with contradictory, > inconsistent and poorly written documents and policies. > > cheers > denis > co-chair DB-WG > > -- > > 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 >
-- 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
