[address-policy-wg] ripe-682 Transfer Policy Problems

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 <ripedenis at gmail.com> 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://mailman.ripe.net/
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </ripe/mail/archives/address-policy-wg/attachments/20211223/6fb449a0/attachment.html>