You are here: Home > Participate > Join a Discussion > RIPE Forum
RIPE Forum v1.4.2

Address Policy Working Group

Threaded
Collapse

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

denis walker

2021-12-22 16:01:04 CET

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

User Image

Arash Naderpour

2021-12-23 03:26:23 CET

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 _dot_ 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://lists.ripe.net/mailman/listinfo/address-policy-wg
>
User Image

Mathias Westerlund

2021-12-23 09:22:08 CET

The member cost is however easily eaten by the income of renting a single
/24 in many countries at the moment.

So it is barely an hindrance at all and especially not a hindrance for an
org betting on the finite nature of ipv4 pushing prices in 2-5 years to
crazy levels.

On Thu, Dec 23, 2021, 03:27 Arash Naderpour <arash_mpc _at_ parsun _dot_ com> wrote:

> 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 _dot_ 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://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
>

denis walker

2021-12-23 20:00:42 CET

Hi Arash

On Thu, 23 Dec 2021 at 03:26, Arash Naderpour <arash_mpc _at_ parsun _dot_ com> wrote:
>
> 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,

No, that's one of the points I am making. There is a huge difference
between the 'intent' of policies and the actual wording. Consolidation
is not mentioned in any policy, only procedural documents of the RIPE
NCC. Consolidation is therefore neither allowed nor disallowed by
policy. The 24 month restriction is on 'transfers'. The policy defines
a transfer as moving resources to 'another member'. So there is no
time constraint on consolidation....according to policy.

cheers
denis
co-chair DB-WG


>
> 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 _dot_ 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://lists.ripe.net/mailman/listinfo/address-policy-wg

User Image

Erik Bais

2021-12-23 22:46:15 CET

Hi Denis,  

As the writer of the last transfer policy document, I can put some light in this for you .. ( I hope.. ) 

The reason for wording like 'a legitmate resource holder' is to include all kind of number resources that holders might have. 
Being it .. legacy, PI assignments or PA Allocations. Or .. a holder of an AS number. 

On your statement you cannot transfer a resource unless it is allocated.. would exclude PI assignments .. or Legacy space .. which can also be transferred. 

There are some documents on the RIPE NCC website that are not policies, but operational procedures, as you already found out ..  or how I would state, explanations by interpretation of the RIPE NCC. 
Like :     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 

The way consolidations of resources between LIR's within a member org work, is written and executed by a procedure of the RIPE NCC, not by definition of the transfer policy.  
That comes originally from the M&A operational procedure that wasn't written down on the public website, but was possible under/by the Dutch legal framework. 
And when this became pubic knowledge later, explained on the NCC website and even later, adjusted after executive board direction to keep LIR's open for 24 months.  
( Yes it was possible in the beginning of the so-called 'final /8 policy' to open a new LIR, request a /22 and merge it back into the initial lir and close the LIR directly.. ) 

That was seen as a loop-hole .. against the intent of the transfer restriction of the policy and that was the reasoning this was introduced by EB decision.  

Currently there some operational differences on how 'consolidation' or m&a's are processed within the RIPE NCC and how that expected when the paperwork that is requested by the RIPE NCC and one might expect. 
If you do a M&A or consolidation, it was (originally) the case that it was required to also sign a Transfer Agreement ( https://www.ripe.net/manage-ips-and-asns/resource-transfers-and-mergers/transfer-of-ip-addresses-and-as-numbers/transfer-agreement-template ) The reasoning behind this practise (as I've been informed by legal from the RIPE NCC ) is to indemnify the RIPE NCC for legal actions .. 
which in a fact is a bit weird, because the NCC is not a party in the Transfer agreement, but only the executor of an agreement between 2 parties. 
But in this case the RIPE NCC benefits of legal exclusion on their operation.. But that is a complete different can of worms to discuss. And it actually puts the RIPE NCC in the path of legal action, instead of excluding it as a party.   

Currently if you do a transfer resources between LIR's of the same member organisation, you are only requested to upload a chamber of commerce document via the website and no other forms are needed anymore. 

With a M&A, there are notary documents required ... which typically specifies that the number resources are also changing from organisation A to org. B. 
Those are explained in detail on the RIPE NCC website : https://www.ripe.net/manage-ips-and-asns/resource-transfers-and-mergers/required-documents-for-registry-updates 
And you can see that also the transfer agreement is requested .. even if this is officially NOT a transfer .. but somehow it has been impossible for the RIPE NCC to create a specific template for M&A's ... 
The only reason for this that I can think of is .. the same legal indemnification that I mentioned earlier .. making the RIPE NCC also here a third party beneficiary to an agreement that it doesn't sign itself. ( looks weird to me .. ) 

So if you Merge a shell company with 20 LIR's to a company .. with let's say .. 3 LIR's .. you need to select the target LIR .. 
However .. as the LIR holdership is restricted via the 24 month transfer restriction due to the earlier decision by the board, this isn't executed .. and all LIR's will end up in the target company if the resource wasn't allocated longer than 24 months ago.  ( Again .. that isn't how the policy was designed or written .. as M&A's should be possible by transfer policy.  ( https://www.ripe.net/participate/policies/proposals/2015-04/?version=4#transferrestrictions ) 

During the work that we do as an IP broker, we have seen the procedures (and LIR portal interface) change over the passing years .. since the policies were created and implemented.  
Did we object with the RIPE NCC IPRA (hostmaster) if we found issues like I stated above .. and could argue, but couldn't get the actual topic fixed .. yes .. 
but in the end the customers need to be serviced .. and they can't wait for their transfer to be on hold, because someone is requesting additional paperwork to be signed. Even if I personally don't agree with it in some cases.  

One of the weird topics that I see happening with some (Legacy) transfers is that new holders are asked to convert their Legacy space (not owned by the NCC) to be changed to RIPE PA space .. 
Which basically removes the legacy holder rights of the new holder. And importing their legacy into a RIPE LIR .. and if they would stop paying to the RIPE NCC, they would have the risk of losing their IP space (as it is RIPE PA space now, liked to the membership status ) .. instead of having IP space in their organisations name, regardless if they are a RIPE NCC member or not.. 
Also this isn't described in the Legacy services policy ( https://www.ripe.net/publications/docs/ripe-639 ) .. and I have no idea why this is being asked on each Legacy transfer to the receiving party ... 

And I haven't even touched upon inter-rir transfers .. or Legacy transfers itself  .. 

And with this long read .. I come to a close of the statement by itself .. 
I don't think that the transfer policy by itself is incorrect .. ( but I could be biased ..) ... 
That the RIPE NCC operates the transfers slightly to its own interpretation I can understand .. and even with the above mentioned topics, I think they do this very good... 
There is always room for improvement .. and we pick our battles.  

I'll be more than happy to provide you some insight on transfers from various type of resources and how the LIR portal options work with it. If you don't have access to an LIR, to see how that looks these days.  
This can be via Zoom / Teams, or if you fancy to come over to our office near Amsterdam for a cup of coffee.  

Regards,
Erik Bais 

 

On 22/12/2021, 16:01, "address-policy-wg on behalf of denis walker" <address-policy-wg-bounces _at_ ripe _dot_ net on behalf of ripedenis _at_ gmail _dot_ 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://lists.ripe.net/mailman/listinfo/address-policy-wg
    

denis walker

2022-01-05 14:20:43 CET

Colleagues

Thanks Erik for the detailed reply. I have made many comments inline
below. For those who don't like to read long emails I have summarised
my main points first.

ripe-682 RIPE Resource Transfer Policies needs updating. These are my
suggestions:

1/ Policies must be self contained and consistent.

2/ There must be a definition of the most important terms within the policy.

3/ There must be a clear definition of what a 'transfer' is.

4/ There must be a clear definition of what a 'consolidation' is.

5/ The section 'Transfer Restrictions' should become 'Restrictions'
and make it clear these restrictions apply to both transfers and
consolidations.

6/ The section 'Transfer Statistics' should become 'Statistics'. Lists
of all Transfers and Consolidations will be published. An open and
transparent industry should make all changes to resource holdership
clear.

7/ For Mergers & Acquisitions (M&A), transfer of authority,
responsibility and liability for the transferred resources should move
to the receiving party when the national company registry officially
deregisters the legal entity currently holding the resources. There
should be no period where no legal entity is responsible and liable
for address space or other resources.

8/ There must be strict time periods for informing the RIPE NCC that a
M&A has taken place and for finalising all paperwork and signing of
new contracts following a M&A. For example:
   a/ The RIPE NCC must be informed of a M&A within 4 weeks of the
deregistration of a company currently holding resources.
   b/ All paperwork and signing of new contracts must be finalised
within 6 months of the date of the deregistration of the previous
resource holding company

9/ Failure to comply with these time periods, without justifiable
reasoning beyond the control of the member concerned, should allow the
RIPE NCC to close the relevant LIRs and deregister the resources.

10/ These new conditions should be back dated to 1 Jan 2021. An
amnesty can be allowed for all M&As not yet notified to the RIPE NCC
provided such M&As are reported to the RIPE NCC within 4 weeks of this
policy change being approved.


ripe-733 IPv4 Address Allocation and Assignment Policies for the RIPE
NCC Service Region also needs updating. These are my suggestions:

1/ "On application for IPv4 resources LIRs will receive IPv4 addresses
according to the following" should become
'On application for IPv4 resources Members will receive IPv4 addresses
according to the following'

2/ The following conditions should include:
Groups of Members linked through complex structures of subsidiary
companies, or companies connected through common directorships, are
considered as a single Member for the purpose of these allocations.

3/ Those Members who bypass the intent of the waiting list by setting
up complex webs of multiple (shell) companies should be required to
return, to the RIPE NCC, the allocations previously allocated to them
.

4/ These new conditions should be back dated to 1 Jan 2021.

These suggestions are controversial and will be heavily opposed,
especially by those few who have benefitted significantly from the
waiting list policy. But let me remind you all that ripe-733 says:
"Fairness: Public IPv4 address space must be fairly distributed to the
End Users operating networks."
Note "fairly" and "operating networks".
Also policy proposal 2019-02 says:
"The goal of this policy proposal is to keep providing newcomers with
a minimal amount of IPv4 space from the RIR for as long as possible."
"By extending the availability of IPv4 addresses to newcomers, the
RIPE community demonstrates goodwill with regards competition laws and
regulations."

The way the policy has been applied throughout 2021, I have seen
little sign of 'goodwill'.

more comments inline below...

On Thu, 23 Dec 2021 at 22:46, Erik Bais <erik _at_ bais _dot_ name> wrote:
>
> Hi Denis,
>
> As the writer of the last transfer policy document, I can put some light in this for you .. ( I hope.. )
>
> The reason for wording like 'a legitmate resource holder' is to include all kind of number resources that holders might have.
> Being it .. legacy, PI assignments or PA Allocations. Or .. a holder of an AS number.

That makes sense except it is the wrong word. A legal or COMMS review
by the NCC should pick up things like this. Legitimate means correct
or valid. What you meant was 'a holder of any type of resource'.

>
> On your statement you cannot transfer a resource unless it is allocated.. would exclude PI assignments .. or Legacy space .. which can also be transferred.

Agreed but I was using that statement to illustrate how one policy may
depend on another policy.

>
> There are some documents on the RIPE NCC website that are not policies, but operational procedures, as you already found out ..  or how I would state, explanations by interpretation of the RIPE NCC.
> Like :     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
>
> The way consolidations of resources between LIR's within a member org work, is written and executed by a procedure of the RIPE NCC, not by definition of the transfer policy.
> That comes originally from the M&A operational procedure that wasn't written down on the public website, but was possible under/by the Dutch legal framework.
> And when this became pubic knowledge later, explained on the NCC website and even later, adjusted after executive board direction to keep LIR's open for 24 months.
> ( Yes it was possible in the beginning of the so-called 'final /8 policy' to open a new LIR, request a /22 and merge it back into the initial lir and close the LIR directly.. )

This is a can of worms all on it's own. Consolidation is not defined
in any policy. RIPE NCC procedural documents are supposed to explain
or interpret policies. Consolidation is only referenced in a
procedural document. So the RIPE NCC is not interpreting what
consolidation means, they are defining it. That should be done by
policy.

>
> That was seen as a loop-hole .. against the intent of the transfer restriction of the policy and that was the reasoning this was introduced by EB decision.
>
> Currently there some operational differences on how 'consolidation' or m&a's are processed within the RIPE NCC and how that expected when the paperwork that is requested by the RIPE NCC and one might expect.
> If you do a M&A or consolidation, it was (originally) the case that it was required to also sign a Transfer Agreement ( https://www.ripe.net/manage-ips-and-asns/resource-transfers-and-mergers/transfer-of-ip-addresses-and-as-numbers/transfer-agreement-template ) The reasoning behind this practise (as I've been informed by legal from the RIPE NCC ) is to indemnify the RIPE NCC for legal actions ..
> which in a fact is a bit weird, because the NCC is not a party in the Transfer agreement, but only the executor of an agreement between 2 parties.
> But in this case the RIPE NCC benefits of legal exclusion on their operation.. But that is a complete different can of worms to discuss. And it actually puts the RIPE NCC in the path of legal action, instead of excluding it as a party.
>
> Currently if you do a transfer resources between LIR's of the same member organisation, you are only requested to upload a chamber of commerce document via the website and no other forms are needed anymore.

This is consolidation that is not defined in any policy as a transfer.

>
> With a M&A, there are notary documents required ... which typically specifies that the number resources are also changing from organisation A to org. B.
> Those are explained in detail on the RIPE NCC website : https://www.ripe.net/manage-ips-and-asns/resource-transfers-and-mergers/required-documents-for-registry-updates
> And you can see that also the transfer agreement is requested .. even if this is officially NOT a transfer .. but somehow it has been impossible for the RIPE NCC to create a specific template for M&A's ...
> The only reason for this that I can think of is .. the same legal indemnification that I mentioned earlier .. making the RIPE NCC also here a third party beneficiary to an agreement that it doesn't sign itself. ( looks weird to me .. )
>
> So if you Merge a shell company with 20 LIR's to a company .. with let's say .. 3 LIR's .. you need to select the target LIR ..
> However .. as the LIR holdership is restricted via the 24 month transfer restriction due to the earlier decision by the board, this isn't executed .. and all LIR's will end up in the target company if the resource wasn't allocated longer than 24 months ago.  ( Again .. that isn't how the policy was designed or written .. as M&A's should be possible by transfer policy.  ( https://www.ripe.net/participate/policies/proposals/2015-04/?version=4#transferrestrictions )

This is another can of worms. The policy is so vague here that almost
anything is allowed. The policy makes no clear distinction between
transfer of a resource or transfer or an LIR holding a resource.
Applying this policy literally, with a merger, you can transfer the
'resources' (not LIRs holding resources) to (an LIR within) the
receiving company. So consolidation (which is not defined by any
policy) can occur as part of a merger, regardless of any transfer
restrictions. This may not be the intent, but it is what this policy
says (or doesn't say). So if the policies are the 'law' consolidate as
you like with mergers.


> And with this long read .. I come to a close of the statement by itself ..
> I don't think that the transfer policy by itself is incorrect .. ( but I could be biased ..) ...
> That the RIPE NCC operates the transfers slightly to its own interpretation I can understand .. and even with the above mentioned topics, I think they do this very good...
> There is always room for improvement .. and we pick our battles.

I would disagree here. I think the policy is a very long way away from
the intent.

cheers
denis
co-chair DB-WG

> Regards,
> Erik Bais
>
>
>
> On 22/12/2021, 16:01, "address-policy-wg on behalf of denis walker" <address-policy-wg-bounces _at_ ripe _dot_ net on behalf of ripedenis _at_ gmail _dot_ 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://lists.ripe.net/mailman/listinfo/address-policy-wg
>
>