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

Address Policy Working Group

Threaded
Collapse

[address-policy-wg] IPv4 waiting list policy

User Image

Marco Schmidt

2021-12-07 10:22:59 CET

RIPE NCC staff member

Dear colleagues,

In the Address Policy Working Group sessions at RIPE 83, I shared our 
observations regarding the IPv4 waiting list policy. [1]

The intent of this policy was to provide newcomers with a minimal amount 
of IPv4 space for as long as possible. However, about half of these 
allocations went to members that received several /24 allocations via 
multiple LIR accounts.

As there was interest in reviewing the policy at the RIPE Meeting, I 
would like to provide more detail on the provision of IPv4 allocations 
over the last two years and the current situation with the waiting list.

In the last 24 months, we provided 4,178 LIRs with a /24 allocation:
-    2,019 allocations (48%) went to members with a single LIR account
-    452 allocations (11%) went to members with 2-4 LIR accounts
-    298 allocations (7%) went to members with 5-9 LIR accounts and
-    1,409 allocations (34%) went to members with 10 or more LIR 
accounts (up to 33 /24 allocations to a single member)

This trend towards allocations to multiple LIR accounts has accelerated 
in the past six months. Between June and November 2021, only 24% of 
allocations went to members with a single LIR account, while 54% went to 
members with 10 or more accounts.

We see the same trend with the current waiting list. At the time of 
writing, we can see 327 requests for a /24 allocation:
-    83 (25%) are from members with a single LIR account
-    42 (13%) are from members with 2-4 LIRs accounts
-    45 (14%) are from members with 5-9 LIR accounts
-    157 (48%) are from members with 10 or more LIR accounts

Consequently, there is a significantly longer wait time for members with 
a single LIR account.

Looking at the current market prices for IPv4 in comparison to our 
membership fees, even a wait time of several months is acceptable for 
organisations that plan to transfer their allocation after the end of 
the holding period. Conversely, the long wait time will create 
uncertainty for real newcomers, especially if they can’t rely on 
IPv6-only networks.

I hope the WG finds this information useful for further discussion. If 
there is consensus to change the current situation, there are several 
approaches available – including a review of the waiting list policy and 
changing ‘per LIR’ to something else. Other approaches, such as a 
different charging scheme or changing the concept of multiple LIRs would 
need to be approved by the RIPE NCC membership.

Kind regards,
Marco Schmidt
Assistant Manager Registry Services
RIPE NCC

[1] https://ripe83.ripe.net/archives/video/642/


User Image

thomas brenac

2021-12-07 10:54:46 CET

Hello Indeed this surge in the waiting list is a show stopper for new comers that really rely on this allocation to initiate their business and have a timed business plan. I would suggest that allocation priority is given to new single LIR (upper priority) down to lower priority for those with more than 10 LIR. My 2 cents Thomas BRENAC http://www.brenac.eu +33686263575 CEO IPv4 Broker registered with RIPE NCC, ARIN, APNIC and LACNIC Member of AFRINIC Marco Schmidt <mschmidt _at_ ripe _dot_ net (mailto:mschmidt _at_ ripe _dot_ net)> 7 déc. 2021 à 10:23:35 wrote: > > Dear colleagues, In the Address Policy Working Group sessions at RIPE 83, I shared our observations regarding the IPv4 waiting list policy. [1] The intent of this policy was to provide newcomers with a minimal amount of IPv4 space for as long as possible. However, about half of these allocations went to members that received several /24 allocations via multiple LIR accounts. As there was interest in reviewing the policy at the RIPE Meeting, I would like to provide more detail on the provision of IPv4 allocations over the last two years and the current situation with the waiting list. In the last 24 months, we provided 4,178 LIRs with a /24 allocation: - 2,019 allocations (48%) went to members with a single LIR account - 452 allocations (11%) went to members with 2-4 LIR accounts - 298 allocations (7%) went to members with 5-9 LIR accounts and - 1,409 allocations (34%) went to members with 10 or more LIR accounts (up to 33 /24 allocations to a single member) This trend towards allocations to multiple LIR accounts has accelerated in the past six months. Between June and November 2021, only 24% of allocations went to members with a single LIR account, while 54% went to members with 10 or more accounts. We see the same trend with the current waiting list. At the time of writing, we can see 327 requests for a /24 allocation: - 83 (25%) are from members with a single LIR account - 42 (13%) are from members with 2-4 LIRs accounts - 45 (14%) are from members with 5-9 LIR accounts - 157 (48%) are from members with 10 or more LIR accounts Consequently, there is a significantly longer wait time for members with a single LIR account. Looking at the current market prices for IPv4 in comparison to our membership fees, even a wait time of several months is acceptable for organisations that plan to transfer their allocation after the end of the holding period. Conversely, the long wait time will create uncertainty for real newcomers, especially if they can’t rely on IPv6-only networks. I hope the WG finds this information useful for further discussion. If there is consensus to change the current situation, there are several approaches available – including a review of the waiting list policy and changing ‘per LIR’ to something else. Other approaches, such as a different charging scheme or changing the concept of multiple LIRs would need to be approved by the RIPE NCC membership. Kind regards, Marco Schmidt Assistant Manager Registry Services RIPE NCC [1] https://ripe83.ripe.net/archives/video/642/ -- 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-07 15:29:15 CET

Hi Marco,  

Thank you for the detailed information of the dispersion about the current and past of the waitinglist.  

To the WG:  

The current workings of the IPv4 Waitinglist is specified in the IPv4 Address Allocation and Assignment Policies for the RIPE NCC Service Region

https://www.ripe.net/publications/docs/ripe-733#5 

Currently there is a First Come First Serve procedure for the waitinglist .. and there are no limitation to allocating v4 space to members that have been already allocated v4 space since the waitinglist started. 

I think that I speak for the WG, that the intent for the final /8 policy and the waitinglist policy, is to provide IPv4 (at least a small bit) to newcomers .. meaning that how it currently works and how it was intended .. that this might not align with what the WG initially wanted.  

If a change would be desired by the WG, it should go through the PDP, meaning that a policy change would be required.  

As WG chairs we would like to see the position of the WG on the topic and what could be seen as a possible solution.  

Regards,
Erik Bais
On behalf of the AP-WG Co-Chair collective.  



On 07/12/2021, 10:23, "address-policy-wg on behalf of Marco Schmidt" <address-policy-wg-bounces _at_ ripe _dot_ net on behalf of mschmidt _at_ ripe _dot_ net> wrote:

    Dear colleagues,
    
    In the Address Policy Working Group sessions at RIPE 83, I shared our 
    observations regarding the IPv4 waiting list policy. [1]
    
    The intent of this policy was to provide newcomers with a minimal amount 
    of IPv4 space for as long as possible. However, about half of these 
    allocations went to members that received several /24 allocations via 
    multiple LIR accounts.
    
    As there was interest in reviewing the policy at the RIPE Meeting, I 
    would like to provide more detail on the provision of IPv4 allocations 
    over the last two years and the current situation with the waiting list.
    
    In the last 24 months, we provided 4,178 LIRs with a /24 allocation:
    -    2,019 allocations (48%) went to members with a single LIR account
    -    452 allocations (11%) went to members with 2-4 LIR accounts
    -    298 allocations (7%) went to members with 5-9 LIR accounts and
    -    1,409 allocations (34%) went to members with 10 or more LIR 
    accounts (up to 33 /24 allocations to a single member)
    
    This trend towards allocations to multiple LIR accounts has accelerated 
    in the past six months. Between June and November 2021, only 24% of 
    allocations went to members with a single LIR account, while 54% went to 
    members with 10 or more accounts.
    
    We see the same trend with the current waiting list. At the time of 
    writing, we can see 327 requests for a /24 allocation:
    -    83 (25%) are from members with a single LIR account
    -    42 (13%) are from members with 2-4 LIRs accounts
    -    45 (14%) are from members with 5-9 LIR accounts
    -    157 (48%) are from members with 10 or more LIR accounts
    
    Consequently, there is a significantly longer wait time for members with 
    a single LIR account.
    
    Looking at the current market prices for IPv4 in comparison to our 
    membership fees, even a wait time of several months is acceptable for 
    organisations that plan to transfer their allocation after the end of 
    the holding period. Conversely, the long wait time will create 
    uncertainty for real newcomers, especially if they can’t rely on 
    IPv6-only networks.
    
    I hope the WG finds this information useful for further discussion. If 
    there is consensus to change the current situation, there are several 
    approaches available – including a review of the waiting list policy and 
    changing ‘per LIR’ to something else. Other approaches, such as a 
    different charging scheme or changing the concept of multiple LIRs would 
    need to be approved by the RIPE NCC membership.
    
    Kind regards,
    Marco Schmidt
    Assistant Manager Registry Services
    RIPE NCC
    
    [1] https://ripe83.ripe.net/archives/video/642/
    
    
    -- 
    
    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

Gert Doering

2021-12-07 15:56:14 CET

Hi,

On Tue, Dec 07, 2021 at 02:29:15PM +0000, Erik Bais wrote:
> As WG chairs we would like to see the position of the WG on the topic and what could be seen as a possible solution.  

As a member of the WG, I do share the sentiment that the intent of the
"IPv4 runout" policies have been "ensure that late comers to the game
can have a bit of IPv4 space, to number their IPv6 translators", and
not "grab some space for free, and sell it for more money elsewhere".

I do not think this can be fixed on the AGM level ("one legal entity
can only have one LIR account") - we've been there, in the rush to /22s,
and all it does it "make people hide behind shell companies", so in
the end, the address space goes out anyway, but registry quality suffers.

Trying to make the NCC require even more paperwork isn't going to stop
those that want to game the system, but will impact everyone else by
making the NCC more annoying to deal with.


My suggestion would be along the lines what was proposed on the APWG
meeting already - earmark these /24s as non-transferrable, ever.


Consequences:

 - there is no more financial incentive to "get one cheap, sell it expensive"

 - if you need space to run your business, this is exactly what it is
   there for - you can still sell your business (with the /24), you
   just need to keep the LIR account.  But that's as with other 
   business assets.

 - if you want to merge multiple LIR accounts, all having their own
   /24 - then you need to keep around these accounts, or return some
   of the /24s.
    - corrolary: if you use these /24s to number your IPv6 translators,
      then renumbering this translator into "your other /24" is actually
      not very hard.  
    - corrolary2: If you use the /24s to directly number your customers,
      you missed the boat already (wearing my RIPE unicorn t-shirt today).

Gert Doering
        -- NetMaster
-- 
have you enabled IPv6 on something today...?

SpaceNet AG                      Vorstand: Sebastian v. Bomhard, Michael Emmer
Joseph-Dollinger-Bogen 14        Aufsichtsratsvors.: A. Grundner-Culemann
D-80807 Muenchen                 HRB: 136055 (AG Muenchen)
Tel: +49 (0)89/32356-444         USt-IdNr.: DE813185279

Jim Reid

2021-12-07 16:01:49 CET

> On 7 Dec 2021, at 14:56, Gert Doering <gert _at_ space _dot_ net> wrote:
> 
> My suggestion would be along the lines what was proposed on the APWG
> meeting already - earmark these /24s as non-transferrable, ever.

+1 WFM

User Image

Sander Steffann

2021-12-07 16:41:02 CET

Hi,

>> On 7 Dec 2021, at 14:56, Gert Doering <gert _at_ space _dot_ net> wrote:
>> 
>> My suggestion would be along the lines what was proposed on the APWG
>> meeting already - earmark these /24s as non-transferrable, ever.
> 
> +1 WFM

+1 from me as well. This would have very little (if any) impact on the newcomers for whom this policy was created.

Transfers that have already happened should not be affected of course, but we can make a policy that stops new transfers being made in the future. I would prefer to disallow any new transfers, independent of when the assignment was made, to avoid a rush on the NCC for new memberships.

Cheers,
Sander


denis walker

2021-12-07 18:25:21 CET

Hi guys

Many years ago I questioned why we ever invented a market for address
space 'that no one owns' when we had a perfectly good system of
allocating address space based on need and when no longer needed was
returned to the RIR to be re-allocated...for free. I was told 'don't
be silly, people will still sell the address space but not record the
transfers in the RIPE Database'. So the quality of the registry
diminishes. What is going to stop people selling these 'never to be
transferred' allocations and not recording the transfer in the RIPE
Database? I am sure some back door dealings can be arranged to keep
the LIRs active that have the allocations registered and obfuscate the
fee payments to confuse the RIPE NCC. Have companies developed some
sense of morality in recent years?

cheers
denis
co-chair DB-WG

On Tue, 7 Dec 2021 at 16:41, Sander Steffann <sander _at_ steffann _dot_ nl> wrote:
>
> Hi,
>
> >> On 7 Dec 2021, at 14:56, Gert Doering <gert _at_ space _dot_ net> wrote:
> >>
> >> My suggestion would be along the lines what was proposed on the APWG
> >> meeting already - earmark these /24s as non-transferrable, ever.
> >
> > +1 WFM
>
> +1 from me as well. This would have very little (if any) impact on the newcomers for whom this policy was created.
>
> Transfers that have already happened should not be affected of course, but we can make a policy that stops new transfers being made in the future. I would prefer to disallow any new transfers, independent of when the assignment was made, to avoid a rush on the NCC for new memberships.
>
> Cheers,
> Sander
>
>
> --
>
> 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

Gert Doering

2021-12-07 18:26:39 CET

Hi,

On Tue, Dec 07, 2021 at 04:41:02PM +0100, Sander Steffann wrote:
> >> My suggestion would be along the lines what was proposed on the APWG
> >> meeting already - earmark these /24s as non-transferrable, ever.
[..]
> Transfers that have already happened should not be affected of
> course, but we can make a policy that stops new transfers being
> made in the future. I would prefer to disallow any new transfers,
> independent of when the assignment was made, to avoid a rush on the
> NCC for new memberships.

+1 :-)

(Now we're entering shedpainting land - "all /24s?  all /24s allocated
from the wait queue in 2021?  all /24s and all previously allocated /22s?"
- I'd go for "/24s allocated after Jan 1st 2021", as anything more harsh
will be hard to get consensus on)

gert
-- 
have you enabled IPv6 on something today...?

SpaceNet AG                      Vorstand: Sebastian v. Bomhard, Michael Emmer
Joseph-Dollinger-Bogen 14        Aufsichtsratsvors.: A. Grundner-Culemann
D-80807 Muenchen                 HRB: 136055 (AG Muenchen)
Tel: +49 (0)89/32356-444         USt-IdNr.: DE813185279
User Image

Randy Bush

2021-12-07 18:28:22 CET

> I think that I speak for the WG, that the intent for the final /8
> policy and the waitinglist policy, is to provide IPv4 (at least a
> small bit) to newcomers

as a co-author of that polocy, my memory is indeed the intent was to
allow newcomers to get a small bit of space for as long as possible.

> If a change would be desired by the WG, it should go through the PDP,
> meaning that a policy change would be required.
>
>     -    42 (13%) are from members with 2-4 LIRs accounts
>     -    45 (14%) are from members with 5-9 LIR accounts
>     -    157 (48%) are from members with 10 or more LIR accounts

this inclines me to offer to work with others on an update to the
policy.  gert's suggestion is interesting.

randy

User Image

Gert Doering

2021-12-07 18:31:13 CET

Hi,

On Tue, Dec 07, 2021 at 06:25:21PM +0100, denis walker wrote:
> Many years ago I questioned why we ever invented a market for address
> space 'that no one owns' when we had a perfectly good system of
> allocating address space based on need and when no longer needed was
> returned to the RIR to be re-allocated...for free. I was told 'don't
> be silly, people will still sell the address space but not record the
> transfers in the RIPE Database'. So the quality of the registry
> diminishes. What is going to stop people selling these 'never to be
> transferred' allocations and not recording the transfer in the RIPE
> Database? I am sure some back door dealings can be arranged to keep
> the LIRs active that have the allocations registered and obfuscate the
> fee payments to confuse the RIPE NCC. Have companies developed some
> sense of morality in recent years?

If the LIR fee is still to be paid, this is commercially not very
attractive - and as such, should stop the business model "open a LIR,
get a /24 for  EUR, sell it for <5*x>" nicely.

Note that we always acknowledged the need for a block of addresses
to "change hands", by mergers & acquisition.  Having a formal transfer
policy was basically just accepting that people would hide this in
a company sale otherwise.

My proposal is actually to disallow transfers *including* disallowing
M&A transfers on these.  It MUST stay in the LIR it was requested by,
and if the LIR closes, it MUST be returned.

Buying a "company with the LIR" would still be possible, of course
(and I do not see a way to disallow this, it's like MS trying to 
disallow selling used windows licenses), but "... and then transferring, 
and closing the LIR" would not.

Gert Doering
        -- NetMaster
-- 
have you enabled IPv6 on something today...?

SpaceNet AG                      Vorstand: Sebastian v. Bomhard, Michael Emmer
Joseph-Dollinger-Bogen 14        Aufsichtsratsvors.: A. Grundner-Culemann
D-80807 Muenchen                 HRB: 136055 (AG Muenchen)
Tel: +49 (0)89/32356-444         USt-IdNr.: DE813185279
User Image

Aleksey Bulgakov

2021-12-07 18:40:30 CET

Hi,And what is Gert's role in RIPE NCC now?-- Regards, Alex19:31, 7 декабря 2021 г., Gert Doering <gert _at_ space _dot_ net>:

Hi,On Tue, Dec 07, 2021 at 06:25:21PM +0100, denis walker wrote:

 Many years ago I questioned why we ever invented a market for address space 'that no one owns' when we had a perfectly good system of allocating address space based on need and when no longer needed was returned to the RIR to be re-allocated...for free. I was told 'don't be silly, people will still sell the address space but not record the transfers in the RIPE Database'. So the quality of the registry diminishes. What is going to stop people selling these 'never to be transferred' allocations and not recording the transfer in the RIPE Database? I am sure some back door dealings can be arranged to keep the LIRs active that have the allocations registered and obfuscate the fee payments to confuse the RIPE NCC. Have companies developed some sense of morality in recent years?

If the LIR fee is still to be paid, this is commercially not veryattractive - and as such, should stop the business model "open a LIR,get a /24 for EUR, sell it for <5*x>" nicely.Note that we always acknowledged the need for a block of addressesto "change hands", by mergers & acquisition. Having a formal transferpolicy was basically just accepting that people would hide this ina company sale otherwise.My proposal is actually to disallow transfers *including* disallowingM&A transfers on these. It MUST stay in the LIR it was requested by,and if the LIR closes, it MUST be returned.Buying a "company with the LIR" would still be possible, of course(and I do not see a way to disallow this, it's like MS trying to disallow selling used windows licenses), but "... and then transferring, and closing the LIR" would not.Gert Doering        -- NetMaster

-- have you enabled IPv6 on something today...?SpaceNet AG Vorstand: Sebastian v. Bomhard, Michael EmmerJoseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-CulemannD-80807 Muenchen HRB: 136055 (AG Muenchen)Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279-- 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

Jim Reid

2021-12-07 18:43:52 CET

> On 7 Dec 2021, at 17:25, denis walker <ripedenis _at_ gmail _dot_ com> wrote:
> 
> I am sure some back door dealings can be arranged to keep
> the LIRs active that have the allocations registered and obfuscate the
> fee payments to confuse the RIPE NCC. Have companies developed some
> sense of morality in recent years?

Unlikely. Especially for pretendy new LIRs that are hoping for a quick buck.

However, we have to face facts. No v4 allocation scheme will ever be perfect. Some gaming and scams are inevitable. They always were. There will always be bad actors trying to find a loophole or two. In our post v4 world, we just have to suck it up.

IMO here are the questions to consider:

how much effort should this WG spend (waste?) tweaking policies for the last few drops of v4?

how much time and money should the NCC spend on its address police?

are those costs worth the benefit(s)?

is any of this a productive and worthwhile thing to do?

The least-worst option IMO would be to stop transfers of the final /24s from some date in the very near future. [We can’t impose that retroactively.] And have some agreed course of action for these blocks whenever it turns out they later change hands. 

Sebastian-Wilhelm Graf

2021-12-07 18:44:28 CET

Hello!

Any good solution should be start taking effect in the future rather 
than retroactively, it should be fair and transparent,...

So I would like to propose two solutions to this dilemma:

a) All ipv4 resources received from the the waiting list requests 
submitted after 2022-01-01 are non-transferable and bound to the LIR 
that has requested the resource.

b) All ipv4 resources received from the the waiting list requests 
submitted after 2022-01-01 are non-transferable for the next 60 months.


Suggestion (b) would bring us more in line with how ARIN handles 
requests. Whereas #1 would favor small LIR's. Both solutions create 
almost 0 additional strain on the current processes.


kind regards

Sebastian Graf



This has the advantage of being "fair"

On 12/7/21 18:31, Gert Doering wrote:
> Hi,
>
> On Tue, Dec 07, 2021 at 06:25:21PM +0100, denis walker wrote:
>> Many years ago I questioned why we ever invented a market for address
>> space 'that no one owns' when we had a perfectly good system of
>> allocating address space based on need and when no longer needed was
>> returned to the RIR to be re-allocated...for free. I was told 'don't
>> be silly, people will still sell the address space but not record the
>> transfers in the RIPE Database'. So the quality of the registry
>> diminishes. What is going to stop people selling these 'never to be
>> transferred' allocations and not recording the transfer in the RIPE
>> Database? I am sure some back door dealings can be arranged to keep
>> the LIRs active that have the allocations registered and obfuscate the
>> fee payments to confuse the RIPE NCC. Have companies developed some
>> sense of morality in recent years?
> If the LIR fee is still to be paid, this is commercially not very
> attractive - and as such, should stop the business model "open a LIR,
> get a /24 for  EUR, sell it for <5*x>" nicely.
>
> Note that we always acknowledged the need for a block of addresses
> to "change hands", by mergers & acquisition.  Having a formal transfer
> policy was basically just accepting that people would hide this in
> a company sale otherwise.
>
> My proposal is actually to disallow transfers *including* disallowing
> M&A transfers on these.  It MUST stay in the LIR it was requested by,
> and if the LIR closes, it MUST be returned.
>
> Buying a "company with the LIR" would still be possible, of course
> (and I do not see a way to disallow this, it's like MS trying to
> disallow selling used windows licenses), but "... and then transferring,
> and closing the LIR" would not.
>
> Gert Doering
>          -- NetMaster
>

User Image

Gert Doering

2021-12-07 19:35:20 CET

Hi,

On Tue, Dec 07, 2021 at 08:40:30PM +0300, Alexey Bulgakov wrote:
> Hi,And what is Gert's role in RIPE NCC now?-- Regards, Alex19:31, 7 ?????????????? 2021 ??., Gert Doering <gert _at_ space _dot_ net>:

Hi,On Tue, Dec Somewhat hard to make out your question in this mess of top-quoted HTML ugliness. I never had a role in the NCC, and since I passed on the chairing hat, I no longer have a formal role in any of the working groups of RIPE. I continue to be a user of address resources, operator of routers that do care about routing table size, and advocate of letting IPv4 die and using IPv6 instead of bickering around deck chairs. But people seem to prefer the expensive before the unknown... Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard, Michael Emmer Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279

denis walker

2021-12-07 20:53:52 CET

On Tue, 7 Dec 2021 at 18:44, Sebastian-Wilhelm Graf
<ripe-lists _at_ sebastian-graf _dot_ at> wrote:
>
> Hello!
>
>
> This has the advantage of being "fair"
>
This depends on your definition of fairness. Let's be brutally honest
here. Anyone who has set up 10, 20, 30 LIRs in the last couple of
years and has received multiple /24s is intentionally circumventing
the goal of the policy for financial gain. They are playing games for
profit. Let's get the legal advice we need and stop these games. These
are policies, not national/international laws. Policies are a set of
rules for the RIPE NCC membership. Members have signed contracts
agreeing to all policies and agreed changes to those policies. Nothing
says a policy change cannot be retroactive. As Gert said, let's apply
a policy change back to 1/1/21. If someone wants to challenge it in
court...let them name and shame themselves. As a community/membership
we should be willing to stand by our principles of fairness and let
the RIPE NCC go to court to defend these principles. While IPv4 is
still in use and essential for genuine new startup businesses, let's
stand up to those who are playing these games for profit...for the
good of the internet.

I don't know who any of these people are with multiple LIRs. But I am
sure they are all subscribed to this mailing list and will do what
they can to prevent policy changes that stop them from making profits.
To re quote Daniel's famous phrase at the Database BoF, "Let's stop
tinkering around the edges" of these policies, jump in at the deep end
and fix the problem...to stop the blatant profiteering.

I am going to go one step further than Gert's proposal. Let's suspend
the current policy pending a review. In other words, freeze the
allocation of /24s. I am sure there is nothing in the PDP or anywhere
else that allows for this. But there probably is nothing that
disallows it either. Again let's have a legal review and take bold
action.

I am probably going to get hammered for saying all this, but sometimes
we need to make bold moves and set new precedences...

cheers
denis
co-chair DB-WG

User Image

Adrian Bolster

2021-12-07 21:27:07 CET

Whilst I agree with the vast majority of your email it is absurd to retrospectively apply a newly adopted policy. I believe this would be a very unhealthy precedent to set.

Regards,
Adrian. 

Sent from my iPhone

> On 7 Dec 2021, at 19:54, denis walker <ripedenis _at_ gmail _dot_ com> wrote:
> 
> On Tue, 7 Dec 2021 at 18:44, Sebastian-Wilhelm Graf
> <ripe-lists _at_ sebastian-graf _dot_ at> wrote:
>> 
>> Hello!
>> 
>> 
>> This has the advantage of being "fair"
>> 
> This depends on your definition of fairness. Let's be brutally honest
> here. Anyone who has set up 10, 20, 30 LIRs in the last couple of
> years and has received multiple /24s is intentionally circumventing
> the goal of the policy for financial gain. They are playing games for
> profit. Let's get the legal advice we need and stop these games. These
> are policies, not national/international laws. Policies are a set of
> rules for the RIPE NCC membership. Members have signed contracts
> agreeing to all policies and agreed changes to those policies. Nothing
> says a policy change cannot be retroactive. As Gert said, let's apply
> a policy change back to 1/1/21. If someone wants to challenge it in
> court...let them name and shame themselves. As a community/membership
> we should be willing to stand by our principles of fairness and let
> the RIPE NCC go to court to defend these principles. While IPv4 is
> still in use and essential for genuine new startup businesses, let's
> stand up to those who are playing these games for profit...for the
> good of the internet.
> 
> I don't know who any of these people are with multiple LIRs. But I am
> sure they are all subscribed to this mailing list and will do what
> they can to prevent policy changes that stop them from making profits.
> To re quote Daniel's famous phrase at the Database BoF, "Let's stop
> tinkering around the edges" of these policies, jump in at the deep end
> and fix the problem...to stop the blatant profiteering.
> 
> I am going to go one step further than Gert's proposal. Let's suspend
> the current policy pending a review. In other words, freeze the
> allocation of /24s. I am sure there is nothing in the PDP or anywhere
> else that allows for this. But there probably is nothing that
> disallows it either. Again let's have a legal review and take bold
> action.
> 
> I am probably going to get hammered for saying all this, but sometimes
> we need to make bold moves and set new precedences...
> 
> 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

Gert Doering

2021-12-07 22:03:41 CET

Hi,

On Tue, Dec 07, 2021 at 08:27:07PM +0000, Adrian Bolster wrote:
> Whilst I agree with the vast majority of your email it is absurd
> to retrospectively apply a newly adopted policy. I believe this
> would be a very unhealthy precedent to set.

Strictly speaking, all transfer policies have been applied retroactively
(at some point, transfers were made possible for all resources that had
been allocated or assigned before that point).  Also, we have done this
when increasing the holding period for the /22s to 24 months - which,
of course, people that made money of doing fast-LIRs did not like.

So this has been done and can be done again.

What we cannot do is retroactively disallow a transfer that has already 
been *done*, but deciding new policies for existing allocations and 
assignment is fully covered by the RIPE general service agreement.

Gert Doering
        -- NetMaster
-- 
have you enabled IPv6 on something today...?

SpaceNet AG                      Vorstand: Sebastian v. Bomhard, Michael Emmer
Joseph-Dollinger-Bogen 14        Aufsichtsratsvors.: A. Grundner-Culemann
D-80807 Muenchen                 HRB: 136055 (AG Muenchen)
Tel: +49 (0)89/32356-444         USt-IdNr.: DE813185279
User Image

Chris Woodfield

2021-12-07 22:25:04 CET

> On Dec 7, 2021, at 11:53 AM, denis walker <ripedenis _at_ gmail _dot_ com> wrote:
> 
> I am going to go one step further than Gert's proposal. Let's suspend
> the current policy pending a review. In other words, freeze the
> allocation of /24s. I am sure there is nothing in the PDP or anywhere
> else that allows for this. But there probably is nothing that
> disallows it either. Again let's have a legal review and take bold
> action.
> 


I’m not going to speculate on whether or not this is warranted in this particular case - I won’t claim to have the deep understanding necessary - I will note that there is precedent for this; this course of action is functionally identical to the emergency policy that the ARIN Board Of Trustees put into place in February 2019 that suspended waiting list allocations in the region, as a direct result of the waiting list abuse discovered which seems very similar to the abuse being alleged in this thread. https://www.arin.net/vault/announcements/2019/20190207_waitlist.html 

That said, the current RIPE waiting list policy seems very similar to the policy that ARIN put into place when reverting the suspension, except for a shorter transfer suspension window (24 months as opposed to ARIN’s 5 year restriction on waiting list resources). So it’s not clear if further policy restrictions would solve this problem, as opposed to active investigation of request patterns that appear suspicious when held up to scrutiny. 

> I am probably going to get hammered for saying all this, but sometimes
> we need to make bold moves and set new precedences...
> 

Ideally, sufficient scrutinization of waiting list requests could result in the exposure of abusive patterns and bad actors, similar to the scrutiny that led to the discovery of the Micfo fraud. But that’s like saying that that we should have zero crime in a city because we have a police department.

> cheers
> denis
> co-chair DB-WG
> 

Thanks,

-Chris

> -- 
> 
> 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-07 22:28:38 CET

On Tue, 7 Dec 2021 at 22:03, Gert Doering <gert _at_ space _dot_ net> wrote:
>
> Hi,
>
> On Tue, Dec 07, 2021 at 08:27:07PM +0000, Adrian Bolster wrote:
> > Whilst I agree with the vast majority of your email it is absurd
> > to retrospectively apply a newly adopted policy. I believe this
> > would be a very unhealthy precedent to set.

Despite the fact this precedence has already been set, as Gert
explained, why do you think it is absurd? These people are bending the
rules for profit against the interests of the industry. Let's bend the
rules back and stop them making a profit and maybe even lose money
from the fees they have already paid trying to profiteer. We should
use any available option that is not explicitly 'disallowed' to close
these loopholes.

cheers
denis
co-chair DB-WG

>
> Strictly speaking, all transfer policies have been applied retroactively
> (at some point, transfers were made possible for all resources that had
> been allocated or assigned before that point).  Also, we have done this
> when increasing the holding period for the /22s to 24 months - which,
> of course, people that made money of doing fast-LIRs did not like.
>
> So this has been done and can be done again.
>
> What we cannot do is retroactively disallow a transfer that has already
> been *done*, but deciding new policies for existing allocations and
> assignment is fully covered by the RIPE general service agreement.
>
> Gert Doering
>         -- NetMaster
> --
> have you enabled IPv6 on something today...?
>
> SpaceNet AG                      Vorstand: Sebastian v. Bomhard, Michael Emmer
> Joseph-Dollinger-Bogen 14        Aufsichtsratsvors.: A. Grundner-Culemann
> D-80807 Muenchen                 HRB: 136055 (AG Muenchen)
> Tel: +49 (0)89/32356-444         USt-IdNr.: DE813185279

User Image

Daniel Suchy

2021-12-07 22:38:42 CET

Hello,
it seems to be a good idea to earmark new /24 IPv4 allocations as 
non-transferrable. It's simple from administrative point of view and 
clear policy for newcommers.

- Daniel


On 12/7/21 15:56, Gert Doering wrote:
> Hi,
> 
> On Tue, Dec 07, 2021 at 02:29:15PM +0000, Erik Bais wrote:
>> As WG chairs we would like to see the position of the WG on the topic and what could be seen as a possible solution.
> 
> As a member of the WG, I do share the sentiment that the intent of the
> "IPv4 runout" policies have been "ensure that late comers to the game
> can have a bit of IPv4 space, to number their IPv6 translators", and
> not "grab some space for free, and sell it for more money elsewhere".
> 
> I do not think this can be fixed on the AGM level ("one legal entity
> can only have one LIR account") - we've been there, in the rush to /22s,
> and all it does it "make people hide behind shell companies", so in
> the end, the address space goes out anyway, but registry quality suffers.
> 
> Trying to make the NCC require even more paperwork isn't going to stop
> those that want to game the system, but will impact everyone else by
> making the NCC more annoying to deal with.
> 
> 
> My suggestion would be along the lines what was proposed on the APWG
> meeting already - earmark these /24s as non-transferrable, ever.
> 
> 
> Consequences:
> 
>   - there is no more financial incentive to "get one cheap, sell it expensive"
> 
>   - if you need space to run your business, this is exactly what it is
>     there for - you can still sell your business (with the /24), you
>     just need to keep the LIR account.  But that's as with other
>     business assets.
> 
>   - if you want to merge multiple LIR accounts, all having their own
>     /24 - then you need to keep around these accounts, or return some
>     of the /24s.
>      - corrolary: if you use these /24s to number your IPv6 translators,
>        then renumbering this translator into "your other /24" is actually
>        not very hard.
>      - corrolary2: If you use the /24s to directly number your customers,
>        you missed the boat already (wearing my RIPE unicorn t-shirt today).
> 
> Gert Doering
>          -- NetMaster
> 
> 

User Image

Adrian Bolster

2021-12-07 22:52:50 CET

Was the holding time of 24 months applied retrospectively to a LIR opened prior to the policy adoption?

There will be no objection to applying a retrospective rule that makes no difference or only affects individuals in a positive way. However to impose post contractual limitations after contracts have been agreed and then apply them retrospectively is in my opinion very questionable.

Perhaps a better use of time and efforts is to let IPv4 die it’s inevitable death; that will force other’s hands adopting IPv6 sooner rather than later.

Adrian.

Sent from my iPhone

On 7 Dec 2021, at 21:04, Gert Doering <gert _at_ space _dot_ net> wrote:

Hi,

On Tue, Dec 07, 2021 at 08:27:07PM +0000, Adrian Bolster wrote:
Whilst I agree with the vast majority of your email it is absurd
to retrospectively apply a newly adopted policy. I believe this
would be a very unhealthy precedent to set.

Strictly speaking, all transfer policies have been applied retroactively
(at some point, transfers were made possible for all resources that had
been allocated or assigned before that point).  Also, we have done this
when increasing the holding period for the /22s to 24 months - which,
of course, people that made money of doing fast-LIRs did not like.

So this has been done and can be done again.

What we cannot do is retroactively disallow a transfer that has already
been *done*, but deciding new policies for existing allocations and
assignment is fully covered by the RIPE general service agreement.

Gert Doering
       -- NetMaster
--
have you enabled IPv6 on something today...?

SpaceNet AG                      Vorstand: Sebastian v. Bomhard, Michael Emmer
Joseph-Dollinger-Bogen 14        Aufsichtsratsvors.: A. Grundner-Culemann
D-80807 Muenchen                 HRB: 136055 (AG Muenchen)
Tel: +49 (0)89/32356-444         USt-IdNr.: DE813185279
User Image

Sander Steffann

2021-12-07 23:41:56 CET

Hi Denis,

> What is going to stop people selling these 'never to be
> transferred' allocations and not recording the transfer in the RIPE
> Database?

The fact that the LIR can’t be closed. Having to remain a member and pay the membership fee for as long as you want to use the allocation is business as usual for people who actually want to run a network, but not for people who want to sell the space and then close the LIR.

Cheers,
Sander



Rick Bakker

2021-12-08 00:49:28 CET

Dear colleagues,

While it is really interesting to see that the waiting list is primarily
used as a means of extension for existing LIRs, it would be rather
more interesting to look at the current size of the respective LIRs. It
makes a lot of sense for a small LIR holding a single /24 to open a second
and request a secondary /24. Effectively, holding a /23 worth of IPv4 space
is still negligible in comparison to some of our fellow LIRs holding a
trifold of that.

It seems a countermeasure to restrict every single new /24 allocation in
terms of a transfer. It will only prevent new colleagues in order for them
to grow and excel in their various new concepts. I would personally
strongly advocate restrictions, but only for those who already ‘hold a
lot’. It is simply unfair to limit new entrepreneurs in their ventures by
throwing monetary bars that hold them back in potential growth. This will
only really benefit the bigger colleagues among us, as the new small ‘fish’
are unable to compete because they lack resources to deliver a proper
alternative.

As such, I would rather propose a maximum amount of /24s (through new
memberships) to be requested through the current waiting list policy by a
single entity in a given time frame. It is not unrealistic to limit this at
a single /24 per e.g. six months. This would result throwing the
real ‘hoarders’ under the bus, by not facilitating their hunger for
obtaining IPv4 ‘at the cheap’, while still allowing ‘legitimate’ new
members to grow by allocating them the resources they need.

Also, let’s not forget that while the IPv4 waiting list hands out IPv4 from
the RIPE NCC ‘free’ pool, the amount of IPv4 that is recovered is
very limited and will probably be even more limited in the foreseeable
future. It would make a lot more sense to push at recovering more space,
that can than be handed to new colleagues in a more fair, somewhat more
restrictive way. Just by looking at some public looking glasses, I can
find examples of hobbyist / amateur associations that hold a /16, while it
seems not nearly a quarter of that is in active use.

While it has been rejected a lot of times before, and another shot at it
likely won’t make a difference, the real way to recover IPv4 space, seems
to be by putting monetary sanctions on free space. Think of this in terms
of changing the way the RIPE NCC does their billing. At current,
every single LIR, no matter its size, pays the same contribution towards
our association. This policy does NOT push fellow members into
returning space they no longer need, or won’t need in the foreseeable
future, as holding it does not cost anything. When replacing the current
billing scheme into a more flexible billing scheme where each individual
IPv4 held can and will be billed, the organisations that do not need the
space will return the free space. After all: why pay for resources that you
do not need, and won’t need?

Of course, for smaller LIRs, this impact won’t be significant. But picture
a LIR holding several /16s, of which only a couple of /24 prefixes are
in active use? At a small fee of say 10 euro cents per IPv4 address,
returning half of a /16, would mean an annual reduction of costs by 6K.
Such amount is not that significant, but big enough to push smaller LIRs
that hold such an amount of unused space, to return the unused parts. Such
a policy could free up a lot of unused space that can then be redistributed
to our new colleagues through a more restrictive waiting list mechanism.

In this current discussion, some of our fellow colleagues have a tendency
to ignore identifying a problem, because they believe IPv4 will ‘die’ on
a short term. Let’s face it: at current, a proper hosting service cannot be
delivered without IPv4. Of course, there is a steady growth to be
identified in global IPv6 usage, this does not mean we can simply have new
colleagues ‘wait’ another ten years or so before their IPv6-only services
can be seen as mature enough for production use.

To wrap up my argument: the sole way of resolving this matter is by having
the older LIRs be lenient enough to help recover space by returning it, and
redistributing it in a fair manner. It is often said that. The current
‘guild’ of network engineers like to see the next generation grow up,
and show interest in their very interesting field. I, myself, at the young
age of 21, identify myself as such. But without any leniency from their end
to help give everyone a fair chance at starting their own online ventures,
by means of allocating at least the most essential resources for them to
get going, this will only get harder and harder in the years to come.

Yes, my stance will generate a lot of resistance, I am sure, by exactly the
group I mentioned that will in this matter show a lack of lenience.
But please, all, let’s take a stance that is serious and will help us all
along in times of the ‘real-real-real’ scarce of IPv4 in our service
region.

Regards,
Rick Bakker
User Image

Hank Nussbacher

2021-12-08 07:11:17 CET

On 07/12/2021 16:56, Gert Doering wrote:
> Hi,
> 
> Trying to make the NCC require even more paperwork isn't going to stop
> those that want to game the system, but will impact everyone else by
> making the NCC more annoying to deal with.
> 
> My suggestion would be along the lines what was proposed on the APWG
> meeting already - earmark these /24s as non-transferrable, ever.

+1

-Hank


User Image

Arash Naderpour

2021-12-08 07:51:45 CET

Hi,

>I think that I speak for the WG, that the intent for the final /8 policy
and the waitinglist policy, is to provide IPv4 (at least a small bit) to
newcomers .. meaning that how it currently works and how it was >intended
.. that this might not align with what the WG initially wanted.

A newcomer can still apply to get an /24 with the current policy, being in
a waiting list means you need to wait (it aligns with the current policy).
there was no intention to have a fast track or a definite waiting period to
get the /24.
If a newcomer needs IPv4 urgently they can request an existing member to
transfer IP address to them, looking at transfer statistics we can see that
there are many v4 transfers happening every month.


Maybe better to find a way to push old members to return their free IPv4
blocks to have more free IP in the pool? This can be done by a change to
the current billing method but that needs to be decided by NCC members, not
the WG.

Regards,

Arash






On Wed, Dec 8, 2021 at 1:29 AM Erik Bais <erik _at_ bais _dot_ name> wrote:

> Hi Marco,
>
> Thank you for the detailed information of the dispersion about the current
> and past of the waitinglist.
>
> To the WG:
>
> The current workings of the IPv4 Waitinglist is specified in the IPv4
> Address Allocation and Assignment Policies for the RIPE NCC Service Region
>
> https://www.ripe.net/publications/docs/ripe-733#5
>
> Currently there is a First Come First Serve procedure for the waitinglist
> .. and there are no limitation to allocating v4 space to members that have
> been already allocated v4 space since the waitinglist started.
>
> I think that I speak for the WG, that the intent for the final /8 policy
> and the waitinglist policy, is to provide IPv4 (at least a small bit) to
> newcomers .. meaning that how it currently works and how it was intended ..
> that this might not align with what the WG initially wanted.
>
> If a change would be desired by the WG, it should go through the PDP,
> meaning that a policy change would be required.
>
> As WG chairs we would like to see the position of the WG on the topic and
> what could be seen as a possible solution.
>
> Regards,
> Erik Bais
> On behalf of the AP-WG Co-Chair collective.
>
>
>
> On 07/12/2021, 10:23, "address-policy-wg on behalf of Marco Schmidt" <
> address-policy-wg-bounces _at_ ripe _dot_ net on behalf of mschmidt _at_ ripe _dot_ net> wrote:
>
>     Dear colleagues,
>
>     In the Address Policy Working Group sessions at RIPE 83, I shared our
>     observations regarding the IPv4 waiting list policy. [1]
>
>     The intent of this policy was to provide newcomers with a minimal
> amount
>     of IPv4 space for as long as possible. However, about half of these
>     allocations went to members that received several /24 allocations via
>     multiple LIR accounts.
>
>     As there was interest in reviewing the policy at the RIPE Meeting, I
>     would like to provide more detail on the provision of IPv4 allocations
>     over the last two years and the current situation with the waiting
> list.
>
>     In the last 24 months, we provided 4,178 LIRs with a /24 allocation:
>     -    2,019 allocations (48%) went to members with a single LIR account
>     -    452 allocations (11%) went to members with 2-4 LIR accounts
>     -    298 allocations (7%) went to members with 5-9 LIR accounts and
>     -    1,409 allocations (34%) went to members with 10 or more LIR
>     accounts (up to 33 /24 allocations to a single member)
>
>     This trend towards allocations to multiple LIR accounts has
> accelerated
>     in the past six months. Between June and November 2021, only 24% of
>     allocations went to members with a single LIR account, while 54% went
> to
>     members with 10 or more accounts.
>
>     We see the same trend with the current waiting list. At the time of
>     writing, we can see 327 requests for a /24 allocation:
>     -    83 (25%) are from members with a single LIR account
>     -    42 (13%) are from members with 2-4 LIRs accounts
>     -    45 (14%) are from members with 5-9 LIR accounts
>     -    157 (48%) are from members with 10 or more LIR accounts
>
>     Consequently, there is a significantly longer wait time for members
> with
>     a single LIR account.
>
>     Looking at the current market prices for IPv4 in comparison to our
>     membership fees, even a wait time of several months is acceptable for
>     organisations that plan to transfer their allocation after the end of
>     the holding period. Conversely, the long wait time will create
>     uncertainty for real newcomers, especially if they can’t rely on
>     IPv6-only networks.
>
>     I hope the WG finds this information useful for further discussion. If
>     there is consensus to change the current situation, there are several
>     approaches available – including a review of the waiting list policy
> and
>     changing ‘per LIR’ to something else. Other approaches, such as a
>     different charging scheme or changing the concept of multiple LIRs
> would
>     need to be approved by the RIPE NCC membership.
>
>     Kind regards,
>     Marco Schmidt
>     Assistant Manager Registry Services
>     RIPE NCC
>
>     [1] https://ripe83.ripe.net/archives/video/642/
>
>
>     --
>
>     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
>
User Image

Arash Naderpour

2021-12-08 08:03:53 CET

>My suggestion would be along the lines what was proposed on the APWG
>meeting already - earmark these /24s as non-transferrable, ever.

I don't think it is a good idea to split the IPv4 addresses into different
types, transferable and non-transferrable. it puts those newcomers in a
disadvantageous position compared to the older members, it is not fair and
doesn't fix anything in long term.

Regards,

Arash




On Wed, Dec 8, 2021 at 1:56 AM Gert Doering <gert _at_ space _dot_ net> wrote:

> Hi,
>
> On Tue, Dec 07, 2021 at 02:29:15PM +0000, Erik Bais wrote:
> > As WG chairs we would like to see the position of the WG on the topic
> and what could be seen as a possible solution.
>
> As a member of the WG, I do share the sentiment that the intent of the
> "IPv4 runout" policies have been "ensure that late comers to the game
> can have a bit of IPv4 space, to number their IPv6 translators", and
> not "grab some space for free, and sell it for more money elsewhere".
>
> I do not think this can be fixed on the AGM level ("one legal entity
> can only have one LIR account") - we've been there, in the rush to /22s,
> and all it does it "make people hide behind shell companies", so in
> the end, the address space goes out anyway, but registry quality suffers.
>
> Trying to make the NCC require even more paperwork isn't going to stop
> those that want to game the system, but will impact everyone else by
> making the NCC more annoying to deal with.
>
>
> My suggestion would be along the lines what was proposed on the APWG
> meeting already - earmark these /24s as non-transferrable, ever.
>
>
> Consequences:
>
>  - there is no more financial incentive to "get one cheap, sell it
> expensive"
>
>  - if you need space to run your business, this is exactly what it is
>    there for - you can still sell your business (with the /24), you
>    just need to keep the LIR account.  But that's as with other
>    business assets.
>
>  - if you want to merge multiple LIR accounts, all having their own
>    /24 - then you need to keep around these accounts, or return some
>    of the /24s.
>     - corrolary: if you use these /24s to number your IPv6 translators,
>       then renumbering this translator into "your other /24" is actually
>       not very hard.
>     - corrolary2: If you use the /24s to directly number your customers,
>       you missed the boat already (wearing my RIPE unicorn t-shirt today).
>
> Gert Doering
>         -- NetMaster
> --
> have you enabled IPv6 on something today...?
>
> SpaceNet AG                      Vorstand: Sebastian v. Bomhard, Michael
> Emmer
> Joseph-Dollinger-Bogen 14        Aufsichtsratsvors.: A. Grundner-Culemann
> D-80807 Muenchen                 HRB: 136055 (AG Muenchen)
> Tel: +49 (0)89/32356-444         USt-IdNr.: DE813185279
> --
>
> 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

David Ponzone

2021-12-08 08:33:38 CET

Personally, I would suggest to increase the 2-years-period if the resulting merged LIR contains prefixes from 2 merged LIRs or more
Example:
A (has a /24) and B (has one historical /22 and another /22 from a previous merger) wants to merge: they would need to wait 3 years.
Next time, It would be 4 years, etc…

Also, if several mergers with the same LIR are requested, I honestly don’t recall if this is allowed, but it should not: one merge per LIR per year.

That should block serial-mergers, but not regular small LIRs with a real network activity.

There are probably loop-holes in my idea, or it’s perhaps too complex to implement.

David Ponzone  Direction Technique
email: david.ponzone _at_ ipeva _dot_ fr david.ponzone _at_ ipeva _dot_ fr>
tel:      01 74 03 18 97
gsm:   06 66 98 76 34

Service Client IPeva
tel:      0811 46 26 26
www.ipeva.fr   -   www.ipeva-studio.com 

Ce message et toutes les pièces jointes sont confidentiels et établis à l'intention exclusive de ses destinataires. Toute utilisation ou diffusion non autorisée est interdite. Tout message électronique est susceptible d'altération. IPeva décline toute responsabilité au titre de ce message s'il a été altéré, déformé ou falsifié. Si vous n'êtes pas destinataire de ce message, merci de le détruire immédiatement et d'avertir l'expéditeur.

> Le 8 déc. 2021 à 08:03, Arash Naderpour <arash_mpc _at_ parsun _dot_ com> a écrit :
> 
> >My suggestion would be along the lines what was proposed on the APWG
> >meeting already - earmark these /24s as non-transferrable, ever.
> 
> I don't think it is a good idea to split the IPv4 addresses into different types, transferable and non-transferrable. it puts those newcomers in a disadvantageous position compared to the older members, it is not fair and doesn't fix anything in long term.
> 
> Regards,
> 
> Arash 
> 
> 
> 
> 
> On Wed, Dec 8, 2021 at 1:56 AM Gert Doering <gert _at_ space _dot_ net gert _at_ space _dot_ net>> wrote:
> Hi,
> 
> On Tue, Dec 07, 2021 at 02:29:15PM +0000, Erik Bais wrote:
> > As WG chairs we would like to see the position of the WG on the topic and what could be seen as a possible solution.  
> 
> As a member of the WG, I do share the sentiment that the intent of the
> "IPv4 runout" policies have been "ensure that late comers to the game
> can have a bit of IPv4 space, to number their IPv6 translators", and
> not "grab some space for free, and sell it for more money elsewhere".
> 
> I do not think this can be fixed on the AGM level ("one legal entity
> can only have one LIR account") - we've been there, in the rush to /22s,
> and all it does it "make people hide behind shell companies", so in
> the end, the address space goes out anyway, but registry quality suffers.
> 
> Trying to make the NCC require even more paperwork isn't going to stop
> those that want to game the system, but will impact everyone else by
> making the NCC more annoying to deal with.
> 
> 
> My suggestion would be along the lines what was proposed on the APWG
> meeting already - earmark these /24s as non-transferrable, ever.
> 
> 
> Consequences:
> 
>  - there is no more financial incentive to "get one cheap, sell it expensive"
> 
>  - if you need space to run your business, this is exactly what it is
>    there for - you can still sell your business (with the /24), you
>    just need to keep the LIR account.  But that's as with other 
>    business assets.
> 
>  - if you want to merge multiple LIR accounts, all having their own
>    /24 - then you need to keep around these accounts, or return some
>    of the /24s.
>     - corrolary: if you use these /24s to number your IPv6 translators,
>       then renumbering this translator into "your other /24" is actually
>       not very hard.  
>     - corrolary2: If you use the /24s to directly number your customers,
>       you missed the boat already (wearing my RIPE unicorn t-shirt today).
> 
> Gert Doering
>         -- NetMaster
> -- 
> have you enabled IPv6 on something today...?
> 
> SpaceNet AG                      Vorstand: Sebastian v. Bomhard, Michael Emmer
> Joseph-Dollinger-Bogen 14        Aufsichtsratsvors.: A. Grundner-Culemann
> D-80807 Muenchen                 HRB: 136055 (AG Muenchen)
> Tel: +49 (0)89/32356-444         USt-IdNr.: DE813185279
> -- 
> 
> 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

User Image

Gert Doering

2021-12-08 08:39:51 CET

Hi,

On Tue, Dec 07, 2021 at 09:52:50PM +0000, Adrian Bolster wrote:
> Was the holding time of 24 months applied retrospectively to a LIR opened prior to the policy adoption?

All policy changes are applied uniformly to all resource holders and
to all resources held.

So, yes.

Transfer policy changes apply to all future *transfers* only, of course,
but not only to resources allocated/assigned after this point in time.

(This is no different from a country changing its VAT on second hand car 
sales - that will apply to all car sales from that point on, no matter 
when the car to be sold has been bought)

Gert Doering
        -- NetMaster
-- 
have you enabled IPv6 on something today...?

SpaceNet AG                      Vorstand: Sebastian v. Bomhard, Michael Emmer
Joseph-Dollinger-Bogen 14        Aufsichtsratsvors.: A. Grundner-Culemann
D-80807 Muenchen                 HRB: 136055 (AG Muenchen)
Tel: +49 (0)89/32356-444         USt-IdNr.: DE813185279
User Image

Gert Doering

2021-12-08 08:41:45 CET

Hi,

On Wed, Dec 08, 2021 at 06:03:53PM +1100, Arash Naderpour wrote:
> >My suggestion would be along the lines what was proposed on the APWG
> >meeting already - earmark these /24s as non-transferrable, ever.
> 
> I don't think it is a good idea to split the IPv4 addresses into different
> types, transferable and non-transferrable. it puts those newcomers in a
> disadvantageous position compared to the older members, it is not fair and
> doesn't fix anything in long term.

Actually, the point is to have something to offer to the newcomers.

If we do not stop the hoarding *now*, there won't be any IPv4 left - would
that be "more fair" to the newcomers?


I wouldn't mind a policy that says "The RIPE NCC does no longer deal in
IPv4 resources at all.  Everything coming back into the RIPE NCC free
pool is returned to IANA." - that would be maximally *fair* (the same
amount of nothing for everybody), but I assume you wouldn't like that
either.

Gert Doering
        -- NetMaster
-- 
have you enabled IPv6 on something today...?

SpaceNet AG                      Vorstand: Sebastian v. Bomhard, Michael Emmer
Joseph-Dollinger-Bogen 14        Aufsichtsratsvors.: A. Grundner-Culemann
D-80807 Muenchen                 HRB: 136055 (AG Muenchen)
Tel: +49 (0)89/32356-444         USt-IdNr.: DE813185279

Jan Ingvoldstad

2021-12-08 09:02:31 CET

This is a good discussion, and a good discussion to have.

On Tue, Dec 7, 2021 at 8:54 PM denis walker <ripedenis _at_ gmail _dot_ com> wrote:

> As Gert said, let's apply
> a policy change back to 1/1/21. If someone wants to challenge it in
> court...let them name and shame themselves. As a community/membership
> we should be willing to stand by our principles of fairness and let
> the RIPE NCC go to court to defend these principles. While IPv4 is
> still in use and essential for genuine new startup businesses, let's
> stand up to those who are playing these games for profit...for the
> good of the internet.
>
>
>
...

I am going to go one step further than Gert's proposal. Let's suspend
> the current policy pending a review. In other words, freeze the
> allocation of /24s. I am sure there is nothing in the PDP or anywhere
> else that allows for this. But there probably is nothing that
> disallows it either. Again let's have a legal review and take bold
> action.
>

These suggestions seem to combine nicely with a 60-month block on transfers
(including M&A) or permanent block of transfers (including M&A).

I'm a bit hesitant regarding blocking M&A, but a 60-month block of M&A
handover would probably suffice.

So, to sum up what I think sounds reasonable (the list is not an "or"-list,
it's an "and"-list):

A) IPv4 address space allocated this year, and for the future, will be
non-transferable.
B) IPv4 address space allocated this year, and for the future, will not be
transferable via M&A for 60 months after allocation.
C) IPv4 waiting list priority follows the size of existing allocations for
the LIR. The lower amount of allocations, starting with zero, the higher
the priority. The next priorty level can gain resources if an only if noone
of higher priority is waiting for resources.
D) When considering existing allocations for prioritizing the waiting list,
also consider other LIRs within the same corporate structure as the same
LIR.

Process steps:

1) Freeze the allocation of IPv4 address space as soon as possible.
2) Prepare new policies for allocations, transfers, and M&A.
3) Unfreeze allocation when the new policies are in place.

-- 
Jan

Rick Bakker

2021-12-08 09:17:36 CET

+1

Let’s try and stop the elite formed by said old members…

Also: how objective can it be said this working group is, when a prominent
member himself, is part of companies that do exactly what is said to try
and prevent here? Cough cough cough…

Looking back at 2019, forming shell companies to obtain /22s, to merge the
companies and the LIRs, only to “broker” (hint) this exact space… This
smells like actively trying to put competition into disadvantage.

If you wish to fight these companies, make it hard for everyone. E.g. delay
every single transfer, of any prefix. Or prevent every single transfer, no
matter when the prefix was first allocated. Fair it wouldn’t be, but with
an elite thinking they know best, will it ever be?

Op wo 8 dec. 2021 om 08:03 schreef Arash Naderpour <arash_mpc _at_ parsun _dot_ com>

> >My suggestion would be along the lines what was proposed on the APWG
> >meeting already - earmark these /24s as non-transferrable, ever.
>
> I don't think it is a good idea to split the IPv4 addresses into different
> types, transferable and non-transferrable. it puts those newcomers in a
> disadvantageous position compared to the older members, it is not fair and
> doesn't fix anything in long term.
>
> Regards,
>
> Arash
>
>
>
>
> On Wed, Dec 8, 2021 at 1:56 AM Gert Doering <gert _at_ space _dot_ net> wrote:
>
>> Hi,
>>
>> On Tue, Dec 07, 2021 at 02:29:15PM +0000, Erik Bais wrote:
>> > As WG chairs we would like to see the position of the WG on the topic
>> and what could be seen as a possible solution.
>>
>> As a member of the WG, I do share the sentiment that the intent of the
>> "IPv4 runout" policies have been "ensure that late comers to the game
>> can have a bit of IPv4 space, to number their IPv6 translators", and
>> not "grab some space for free, and sell it for more money elsewhere".
>>
>> I do not think this can be fixed on the AGM level ("one legal entity
>> can only have one LIR account") - we've been there, in the rush to /22s,
>> and all it does it "make people hide behind shell companies", so in
>> the end, the address space goes out anyway, but registry quality suffers.
>>
>> Trying to make the NCC require even more paperwork isn't going to stop
>> those that want to game the system, but will impact everyone else by
>> making the NCC more annoying to deal with.
>>
>>
>> My suggestion would be along the lines what was proposed on the APWG
>> meeting already - earmark these /24s as non-transferrable, ever.
>>
>>
>> Consequences:
>>
>>  - there is no more financial incentive to "get one cheap, sell it
>> expensive"
>>
>>  - if you need space to run your business, this is exactly what it is
>>    there for - you can still sell your business (with the /24), you
>>    just need to keep the LIR account.  But that's as with other
>>    business assets.
>>
>>  - if you want to merge multiple LIR accounts, all having their own
>>    /24 - then you need to keep around these accounts, or return some
>>    of the /24s.
>>     - corrolary: if you use these /24s to number your IPv6 translators,
>>       then renumbering this translator into "your other /24" is actually
>>       not very hard.
>>     - corrolary2: If you use the /24s to directly number your customers,
>>       you missed the boat already (wearing my RIPE unicorn t-shirt today).
>>
>> Gert Doering
>>         -- NetMaster
>
>
>> --
>> have you enabled IPv6 on something today...?
>>
>> SpaceNet AG                      Vorstand: Sebastian v. Bomhard, Michael
>> Emmer
>> Joseph-Dollinger-Bogen 14
>> 
>>       Aufsichtsratsvors.: A. Grundner-Culemann
>> D-80807 Muenchen                 HRB: 136055 (AG Muenchen)
>> Tel: +49 (0)89/32356-444         USt-IdNr.: DE813185279
>> --
>>
>> 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
>
-- 
Kind Regards,
Rick Bakker
Director

Bakker IT
Dutch Chamber of Commerce number: 71593721
VAT registration ID: NL002414398B43
User Image

Arash Naderpour

2021-12-08 09:40:14 CET

>>Actually, the point is to have something to offer to the newcomers.

We can update the transfer policy and transfer hold time to 60months or
even more to make it less attractive,
Also make a change to the policy to make no /24 allocation to multi LIR
accounts.

Regards,

Arash


On Wed, Dec 8, 2021 at 6:41 PM Gert Doering <gert _at_ space _dot_ net> wrote:

> Hi,
>
> On Wed, Dec 08, 2021 at 06:03:53PM +1100, Arash Naderpour wrote:
> > >My suggestion would be along the lines what was proposed on the APWG
> > >meeting already - earmark these /24s as non-transferrable, ever.
> >
> > I don't think it is a good idea to split the IPv4 addresses into
> different
> > types, transferable and non-transferrable. it puts those newcomers in a
> > disadvantageous position compared to the older members, it is not fair
> and
> > doesn't fix anything in long term.
>
> Actually, the point is to have something to offer to the newcomers.
>
> If we do not stop the hoarding *now*, there won't be any IPv4 left - would
> that be "more fair" to the newcomers?
>
>
> I wouldn't mind a policy that says "The RIPE NCC does no longer deal in
> IPv4 resources at all.  Everything coming back into the RIPE NCC free
> pool is returned to IANA." - that would be maximally *fair* (the same
> amount of nothing for everybody), but I assume you wouldn't like that
> either.
>
> Gert Doering
>         -- NetMaster
> --
> have you enabled IPv6 on something today...?
>
> SpaceNet AG                      Vorstand: Sebastian v. Bomhard, Michael
> Emmer
> Joseph-Dollinger-Bogen 14        Aufsichtsratsvors.: A. Grundner-Culemann
> D-80807 Muenchen                 HRB: 136055 (AG Muenchen)
> Tel: +49 (0)89/32356-444         USt-IdNr.: DE813185279
>
User Image

Arash Naderpour

2021-12-08 09:42:40 CET

>>If you wish to fight these companies, make it hard for everyone. E.g.
delay every single transfer, of any prefix. Or prevent every single
transfer, no matter when the prefix was first allocated. Fair it wouldn’t
be, but with an elite thinking they know best, will it ever be?

I think as long as it is for every single transfer and applied to all
members, it is fair.

Regards,

Arash



On Wed, Dec 8, 2021 at 7:17 PM Rick Bakker <rick _at_ bakker-it _dot_ eu> wrote:

> +1
>
> Let’s try and stop the elite formed by said old members…
>
> Also: how objective can it be said this working group is, when a prominent
> member himself, is part of companies that do exactly what is said to try
> and prevent here? Cough cough cough…
>
> Looking back at 2019, forming shell companies to obtain /22s, to merge the
> companies and the LIRs, only to “broker” (hint) this exact space… This
> smells like actively trying to put competition into disadvantage.
>
> If you wish to fight these companies, make it hard for everyone. E.g.
> delay every single transfer, of any prefix. Or prevent every single
> transfer, no matter when the prefix was first allocated. Fair it wouldn’t
> be, but with an elite thinking they know best, will it ever be?
>
> Op wo 8 dec. 2021 om 08:03 schreef Arash Naderpour <arash_mpc _at_ parsun _dot_ com>
>
>> >My suggestion would be along the lines what was proposed on the APWG
>> >meeting already - earmark these /24s as non-transferrable, ever.
>>
>> I don't think it is a good idea to split the IPv4 addresses into
>> different types, transferable and non-transferrable. it puts those
>> newcomers in a disadvantageous position compared to the older members, it
>> is not fair and doesn't fix anything in long term.
>>
>> Regards,
>>
>> Arash
>>
>>
>>
>>
>> On Wed, Dec 8, 2021 at 1:56 AM Gert Doering <gert _at_ space _dot_ net> wrote:
>>
>>> Hi,
>>>
>>> On Tue, Dec 07, 2021 at 02:29:15PM +0000, Erik Bais wrote:
>>> > As WG chairs we would like to see the position of the WG on the topic
>>> and what could be seen as a possible solution.
>>>
>>> As a member of the WG, I do share the sentiment that the intent of the
>>> "IPv4 runout" policies have been "ensure that late comers to the game
>>> can have a bit of IPv4 space, to number their IPv6 translators", and
>>> not "grab some space for free, and sell it for more money elsewhere".
>>>
>>> I do not think this can be fixed on the AGM level ("one legal entity
>>> can only have one LIR account") - we've been there, in the rush to /22s,
>>> and all it does it "make people hide behind shell companies", so in
>>> the end, the address space goes out anyway, but registry quality suffers.
>>>
>>> Trying to make the NCC require even more paperwork isn't going to stop
>>> those that want to game the system, but will impact everyone else by
>>> making the NCC more annoying to deal with.
>>>
>>>
>>> My suggestion would be along the lines what was proposed on the APWG
>>> meeting already - earmark these /24s as non-transferrable, ever.
>>>
>>>
>>> Consequences:
>>>
>>>  - there is no more financial incentive to "get one cheap, sell it
>>> expensive"
>>>
>>>  - if you need space to run your business, this is exactly what it is
>>>    there for - you can still sell your business (with the /24), you
>>>    just need to keep the LIR account.  But that's as with other
>>>    business assets.
>>>
>>>  - if you want to merge multiple LIR accounts, all having their own
>>>    /24 - then you need to keep around these accounts, or return some
>>>    of the /24s.
>>>     - corrolary: if you use these /24s to number your IPv6 translators,
>>>       then renumbering this translator into "your other /24" is actually
>>>       not very hard.
>>>     - corrolary2: If you use the /24s to directly number your customers,
>>>       you missed the boat already (wearing my RIPE unicorn t-shirt
>>> today).
>>>
>>> Gert Doering
>>>         -- NetMaster
>>
>>
>>> --
>>> have you enabled IPv6 on something today...?
>>>
>>> SpaceNet AG                      Vorstand: Sebastian v. Bomhard, Michael
>>> Emmer
>>> Joseph-Dollinger-Bogen 14
>>> 
>>>       Aufsichtsratsvors.: A. Grundner-Culemann
>>> D-80807 Muenchen                 HRB: 136055 (AG Muenchen)
>>> Tel: +49 (0)89/32356-444         USt-IdNr.: DE813185279
>>> --
>>>
>>> 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
>>
> --
> Kind Regards,
> Rick Bakker
> Director
>
> Bakker IT
> Dutch Chamber of Commerce number: 71593721
> VAT registration ID: NL002414398B43
>
User Image

Diederik de Zee

2021-12-08 10:23:16 CET

  
  
  
    
    	
    	Dear members,I agree with the post of R. Bakker @ Dec 8 00:49:28 CET 2021 under this mailing list.New members should not be pushed as hard as, say, a large company with multiple huge ranges with a lot of unused IPv4 space. Incentives should be placed on the use of much IPv4, the perfect way to regulate this is to ask a monthly or yearly fee per allocated IPv4 address. as a example, average large DC or hosting company seems to currently hold 20 to 50% of its IPv4 space unused and keeps reserving ipv4. You will retrieve a lot of ranges if all out of a sudden it costs them thousands of euro’s each period, because that is a huge write off for them and something they can generally not afford.That change would cause a lot of IPv4 to be free’d up, and make more room for startups and other business that actually have good reasoning for using that ipv4 space.Kind regards,Diederik de Zee
    
  



User Image

Diederik de Zee

2021-12-08 10:23:16 CET

  
  
  
    
    	
    	Dear members,I agree with the post of R. Bakker @ Dec 8 00:49:28 CET 2021 under this mailing list.New members should not be pushed as hard as, say, a large company with multiple huge ranges with a lot of unused IPv4 space. Incentives should be placed on the use of much IPv4, the perfect way to regulate this is to ask a monthly or yearly fee per allocated IPv4 address. as a example, average large DC or hosting company seems to currently hold 20 to 50% of its IPv4 space unused and keeps reserving ipv4. You will retrieve a lot of ranges if all out of a sudden it costs them thousands of euro’s each period, because that is a huge write off for them and something they can generally not afford.That change would cause a lot of IPv4 to be free’d up, and make more room for startups and other business that actually have good reasoning for using that ipv4 space.Kind regards,Diederik de Zee
    
  



User Image

Randy Bush

2021-12-08 12:26:10 CET

> C) IPv4 waiting list priority follows the size of existing allocations for
> the LIR. The lower amount of allocations, starting with zero, the higher
> the priority.

if the purpose of new allocations is to allow entry, why would an LIR
with any existing allocation be given more?

randy

User Image

Arash Naderpour

2021-12-08 12:39:06 CET

Hi Marco,

Could you please let me know how many organizations have 10 or more LIR
accounts?

Thanks,

Arash Naderpour

On Tue, Dec 7, 2021 at 8:22 PM Marco Schmidt <mschmidt _at_ ripe _dot_ net> wrote:

> Dear colleagues,
>
> In the Address Policy Working Group sessions at RIPE 83, I shared our
> observations regarding the IPv4 waiting list policy. [1]
>
> The intent of this policy was to provide newcomers with a minimal amount
> of IPv4 space for as long as possible. However, about half of these
> allocations went to members that received several /24 allocations via
> multiple LIR accounts.
>
> As there was interest in reviewing the policy at the RIPE Meeting, I
> would like to provide more detail on the provision of IPv4 allocations
> over the last two years and the current situation with the waiting list.
>
> In the last 24 months, we provided 4,178 LIRs with a /24 allocation:
> -    2,019 allocations (48%) went to members with a single LIR account
> -    452 allocations (11%) went to members with 2-4 LIR accounts
> -    298 allocations (7%) went to members with 5-9 LIR accounts and
> -    1,409 allocations (34%) went to members with 10 or more LIR
> accounts (up to 33 /24 allocations to a single member)
>
> This trend towards allocations to multiple LIR accounts has accelerated
> in the past six months. Between June and November 2021, only 24% of
> allocations went to members with a single LIR account, while 54% went to
> members with 10 or more accounts.
>
> We see the same trend with the current waiting list. At the time of
> writing, we can see 327 requests for a /24 allocation:
> -    83 (25%) are from members with a single LIR account
> -    42 (13%) are from members with 2-4 LIRs accounts
> -    45 (14%) are from members with 5-9 LIR accounts
> -    157 (48%) are from members with 10 or more LIR accounts
>
> Consequently, there is a significantly longer wait time for members with
> a single LIR account.
>
> Looking at the current market prices for IPv4 in comparison to our
> membership fees, even a wait time of several months is acceptable for
> organisations that plan to transfer their allocation after the end of
> the holding period. Conversely, the long wait time will create
> uncertainty for real newcomers, especially if they can’t rely on
> IPv6-only networks.
>
> I hope the WG finds this information useful for further discussion. If
> there is consensus to change the current situation, there are several
> approaches available – including a review of the waiting list policy and
> changing ‘per LIR’ to something else. Other approaches, such as a
> different charging scheme or changing the concept of multiple LIRs would
> need to be approved by the RIPE NCC membership.
>
> Kind regards,
> Marco Schmidt
> Assistant Manager Registry Services
> RIPE NCC
>
> [1] https://ripe83.ripe.net/archives/video/642/
>
>
> --
>
> 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

Taras Heichenko

2021-12-08 14:31:45 CET

Hi all,

I read here long enough but usually, I do not write. Let me say just a few words. My letter is not an answer to any particular letter.
It is the impression from the whole thread.

I think we need to be honest with ourselves. We try to give cheaply the expensive resource. We don't have enough control to check
that resource is not transferred to another recipient for money. Did you ever see that everybody follows the rules in such cases? We
say that we want to give resources to newcomers almost for free but we also don't do this because of limited resources. Can you
imagine a startup that just seats on the chair and wait a half of a year for the /24? (And during all this time it pays for membership
without defined perspectives.) I can't.

So I think there are two ways. First is selling IP addresses for their market price. I heard many times all reasons why we cannot do this.
Ok. I do not try to persuade anybody to do it. I just try to be honest. The second is just to accept the [black] market of IPv4 addresses
and at least try to make rules that will not cause disturbance of information in the RIPE DB (if you restrict IP transfer you just will not
see this transfer in the RIPE DB but IPs will be used by another owner).

BTW when we try to give IPv4 to all we slow down the IPv6 deployment.

Please, do not explain to me evident things. Just be honest to yourselves.

--
Taras Heichenko
tasic _at_ academ.kiev _dot_ ua






Jan Ingvoldstad

2021-12-08 14:47:19 CET

On Wed, Dec 8, 2021 at 12:26 PM Randy Bush <randy _at_ psg _dot_ com> wrote:

> > C) IPv4 waiting list priority follows the size of existing allocations
> for
> > the LIR. The lower amount of allocations, starting with zero, the higher
> > the priority.
>
> if the purpose of new allocations is to allow entry, why would an LIR
> with any existing allocation be given more?
>

That would only happen if there are zero new entrants, as an LIR with any
existing allocation would have a lower priority on the waiting list.

-- 
Jan
User Image

Leo Vegoda

2021-12-08 15:09:13 CET

Hi,

The Address Policy WG cannot set policies that govern the charging
scheme. That is something controlled by the RIPE NCC's membership.

If you represent a RIPE NCC member, you're welcome to make proposals
related to the charging scheme on the Membership Discuss mailing list:

https://www.ripe.net/participate/member-support/membership-mailing-lists/subscribing-to-members-discuss

Kind regards,

Leo Vegoda, for the Address Policy WG co-chairs

On Wed, Dec 8, 2021 at 1:24 AM Diederik de Zee <hallo _at_ ikbendiederik _dot_ nl> wrote:
>
> Dear members,
>
> I agree with the post of R. Bakker @ Dec 8 00:49:28 CET 2021 under this mailing list.
>
> New members should not be pushed as hard as, say, a large company with multiple huge ranges with a lot of unused IPv4 space. Incentives should be placed on the use of much IPv4, the perfect way to regulate this is to ask a monthly or yearly fee per allocated IPv4 address.
>
> as a example, average large DC or hosting company seems to currently hold 20 to 50% of its IPv4 space unused and keeps reserving ipv4. You will retrieve a lot of ranges if all out of a sudden it costs them thousands of euro’s each period, because that is a huge write off for them and something they can generally not afford.
>
> That change would cause a lot of IPv4 to be free’d up, and make more room for startups and other business that actually have good reasoning for using that ipv4 space.
>
> Kind regards,
> Diederik de Zee
> --
>
> 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

Rick Bakker

2021-12-08 15:12:10 CET

> That would only happen if there are zero new entrants, as an LIR with any
existing allocation would have a lower priority on the waiting list.

Such a policy would not fight the initial point of discussion that there
are single entities requesting multiple times, or using individual legal
entities. After all, Rick's IP hoarding business A BV and Rick's IP
hoarding business B BV are separate legal entities, thus in your proposal
being put in front of a single entity that has two requests under the same
legal entity. Such policy, I think, would only push for incorporating
multiple entities for the sole purpose of pushing ahead in the queue. (e.g.
just look at "Network Space Provider  LTD" in the British company
register). All are/were held by a single UBO.

Perhaps it would make sense to record UBOs (ultimate beneficial owners),
and categorize the waiting list based on the amount of IPs a UBO has
already received, plus limit the amount of memberships unique UBOs can open
(albeit: open, with a restriction of being unable to request scarce
resources). This should include pre-2012 allocations, given we're at the
last stretch. and it would be weird to hand someone holding a /21 a 'final
/24' when others are in a more urgent need of holding any IPs.

Of course, any new policy should only be put into effect for newly made
allocations, without any retrospective effects.

Regards,
Rick


On Wed, Dec 8, 2021 at 2:47 PM Jan Ingvoldstad <frettled _at_ gmail _dot_ com> wrote:

>
> On Wed, Dec 8, 2021 at 12:26 PM Randy Bush <randy _at_ psg _dot_ com> wrote:
>
>> > C) IPv4 waiting list priority follows the size of existing allocations
>> for
>> > the LIR. The lower amount of allocations, starting with zero, the higher
>> > the priority.
>>
>> if the purpose of new allocations is to allow entry, why would an LIR
>> with any existing allocation be given more?
>>
>
> That would only happen if there are zero new entrants, as an LIR with any
> existing allocation would have a lower priority on the waiting list.
>
> --
> Jan
> --
>
> 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-08 15:24:11 CET

On Wed, 8 Dec 2021 at 14:47, Jan Ingvoldstad <frettled _at_ gmail _dot_ com> wrote:
>
>
> On Wed, Dec 8, 2021 at 12:26 PM Randy Bush <randy _at_ psg _dot_ com> wrote:
>>
>> > C) IPv4 waiting list priority follows the size of existing allocations for
>> > the LIR. The lower amount of allocations, starting with zero, the higher
>> > the priority.
>>
>> if the purpose of new allocations is to allow entry, why would an LIR
>> with any existing allocation be given more?
>
>
> That would only happen if there are zero new entrants, as an LIR with any existing allocation would have a lower priority on the waiting list.

If there are no new entrants on the waiting list, the RIPE NCC should
just hold on to any address space it has until there is another new
entrant. I agree with Randy. The RIPE NCC should not give freely any
address space to any organisation that already holds address space in
ANY of it's many LIRs. If a company that already holds address space
wants more they can buy it on the open market.

To avoid new startup shell companies cheating the system, maybe we
should go back to the needs based assessment for new startups.

cheers
denis


>
> --
> Jan
> --
>
> 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

Jim Reid

2021-12-08 15:40:24 CET

> On 8 Dec 2021, at 14:12, Rick Bakker <rick _at_ bakker-it _dot_ eu> wrote:
> 
> (e.g. just look at "Network Space Provider  LTD" in the British company register). All are/were held by a single UBO. 

Companies House (the UK register of companies) says all of them were dissolved on Nov 16th - about three weeks ago. This news may have some bearing on whatever address resources were or weren’t obtained by those now dead firms.

BTW if these firms had a single ultimate beneficial owner, it would have been trivial to obscure that fact. Just register each company with different but bogus identities. CH does not check this information. Which by implication would make it hard for the NCC to check.


Rick Bakker

2021-12-08 16:03:43 CET

> Just register each company with different but bogus identities. CH does
not check this information. Which by implication would make it hard for the
NCC to check.

They already identify and take note of the director / authorized
representative who does the application with the RIPE NCC. It wouldn't seem
hard to keep track and put it to measure.

Nothing is bullet-proof. That is something we just have to accept, and I
believe is mentioned already multiple times in this thread alone. That does
not mean trivial options shall simply be disqualified for that sole matter.
That it isn't 100% effective, does not mean that it does not filter out at
least some of the scum. If we can at least filter the most ruthless, that
might just free up enough IPv4 space to keep enough supply to feed new
entrants.

We should not push at trying to make it as hard as possible for new
entrants to join, rather push at enforcing guidelines to make sure it is
not abused (at least not to a certain extent). It is unjustifiable to
refuse a startup to hold 2x /24 if they can justify a use technically, when
more established entities within our association hold more than a trifold
of such an allocation. Please: encourage new entrepreneurship, do not crush
them 'to the ground'.

Also: how to deal with some in the addressing-wg chair being active in
'hoarding' allocations? It seems to me that said (co-)chair would have to
recuse himself from any involvement in this matter, as it indirectly is
influenced by his business in mind? After all, if said (co-)chair can make
it harder for new entrants to obtain IPv4 space, that inherently means his
brokering business can thrive from a lack of supply he can (in)directly
cause?

Regards,
Rick

On Wed, Dec 8, 2021 at 3:40 PM Jim Reid <jim _at_ rfc1035 _dot_ com> wrote:

>
>
> > On 8 Dec 2021, at 14:12, Rick Bakker <rick _at_ bakker-it _dot_ eu> wrote:
> >
> > (e.g. just look at "Network Space Provider  LTD" in the British
> company register). All are/were held by a single UBO.
>
> Companies House (the UK register of companies) says all of them were
> dissolved on Nov 16th - about three weeks ago. This news may have some
> bearing on whatever address resources were or weren’t obtained by those now
> dead firms.
>
> BTW if these firms had a single ultimate beneficial owner, it would have
> been trivial to obscure that fact. Just register each company with
> different but bogus identities. CH does not check this information. Which
> by implication would make it hard for the NCC to check.
>
>
User Image

Martin Stanislav

2021-12-08 16:14:49 CET

On Wed, Dec 08, 2021 at 02:40:24PM +0000, Jim Reid wrote:
> 
> 
> > On 8 Dec 2021, at 14:12, Rick Bakker <rick _at_ bakker-it _dot_ eu> wrote:
> > 
> > (e.g. just look at "Network Space Provider  LTD" in the British company register). All are/were held by a single UBO. 
> 
> BTW if these firms had a single ultimate beneficial owner, it would have been trivial to obscure that fact. Just register each company with different but bogus identities. CH does not check this information. Which by implication would make it hard for the NCC to check.

NCC is already spending resouces on "Know Your Customer" (KYC) efforts
wrt due diligence for the quality of registration data and the sanctions.

I'm by no means trying to say this is an easy or exhilarating endeavour,
or that it's possible to reuse such efforts early enough to save
any v4 resources for the new entrants.

Martin

denis walker

2021-12-08 18:43:16 CET

Colleagues

Can I suggest another approach. Instead of having a multitude of
policies for IPv4 (Allocation and Assignment, Transfer, Waiting List,
etc), why don't we just write a new IPv4 policy? Take the relevant and
necessary bits from all other policies and add in new bits and
constraints. While we do this all allocations of IPv4 from the RIPE
NCC should be immediately suspended. Then we have all the rules about
IPv4 in one place. Lets face it, the NCC is never going to have huge
amounts of IPv4 addresses to freely hand out again. But we also know
IPv6 is not going to become the dominant variant for some time yet. So
let's consolidate our position on IPv4.

I would suggest that the free pool of IPv4 that the RIPE NCC has from
time to time should only be used to allow new startups to enter the
business. Transfers on these new startup blocks should not be allowed,
ever. If the new startup business is merged or acquired by a company
that already hold address space then the new startup block must be
returned to the RIPE NCC. If all their addresses are in use a time
period can be allowed for the merged company to buy more addresses and
renumber before returning the new startup block. If the merging or
acquiring company holds no address space then the new company can be
allowed to keep the new startup block, but the no transfer rules still
apply. This should apply to all blocks allocated in the last 1 (or 2?)
years. Once you are in the business, if you need more addresses you go
to the market (unfortunate but that is the reality of monetising IP
addresses). All efforts should be made to prevent anyone bypassing the
new rules. An amnesty should be declared to allow those who have
cheated the system for profit in the last couple of years to return
those addresses they are currently hoarding.

I am interested in the comment by Chris Woodfield about the Micfo fraud
https://www.wsj.com/articles/executive-pleads-guilty-in-internet-address-fraud-case-11637101781
This raises a number of thoughts in my mind. If there are any lawyers
or LEA representatives following this thread I would love to hear your
views on this.

Firstly, if any of these organisations that have set up multiple LIRs
to obtain IP addresses for profit are based or headquartered in the
USA, can the US Department of Justice bring a similar case against
them as the did against Micfo for defrauding the RIPE NCC in a similar
way Micfo did with ARIN?

Could a similar case be brought against organisations in any part of
the RIPE region by the appropriate legal authorities?

Obtaining IP addresses in this way for profit prevents new companies
starting up in competition with those hoarding the addresses.
Certainly in the EU and the UK there are anti competitive laws. Have
these laws been broken? Can the appropriate legal authorities take
action against these organisations?

Maybe here it would be a test case to set a new legal precedence as
the Micfo case was in the USA.

This is a self regulating industry. That puts constraints on what the
industry can do to protect itself and show itself to regulators that
it operates in a fair and openly competitive way. I am certainly in
favour of pushing boundaries here and taking strong action against
organisations that are behaving in a way that damages the image and
operation of the industry as a whole. People often say that the RIPE
NCC is not the internet police. Maybe we need to call in the real
police if laws have been broken...

cheers
denis
co-chair DB-WG

On Wed, 8 Dec 2021 at 16:14, Martin Stanislav <ms _at_ uakom _dot_ sk> wrote:
>
> On Wed, Dec 08, 2021 at 02:40:24PM +0000, Jim Reid wrote:
> >
> >
> > > On 8 Dec 2021, at 14:12, Rick Bakker <rick _at_ bakker-it _dot_ eu> wrote:
> > >
> > > (e.g. just look at "Network Space Provider  LTD" in the British company register). All are/were held by a single UBO.
> >
> > BTW if these firms had a single ultimate beneficial owner, it would have been trivial to obscure that fact. Just register each company with different but bogus identities. CH does not check this information. Which by implication would make it hard for the NCC to check.
>
> NCC is already spending resouces on "Know Your Customer" (KYC) efforts
> wrt due diligence for the quality of registration data and the sanctions.
>
> I'm by no means trying to say this is an easy or exhilarating endeavour,
> or that it's possible to reuse such efforts early enough to save
> any v4 resources for the new entrants.
>
> Martin
>
> --
>
> 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

Nick Hilliard

2021-12-08 19:30:42 CET

denis walker wrote on 08/12/2021 17:43:
> I would suggest that the free pool of IPv4 that the RIPE NCC has from
> time to time should only be used to allow new startups to enter the
> business. Transfers on these new startup blocks should not be allowed,
> ever.

What your suggestion does is acknowledge that ipv4 address space has 
asset value.  Financial value of an asset is measured either in terms of 
capital value (probably non-depreciable in the case of ipv4), or as an 
operational cost.

If there's no ability to transfer the objects out of the holding 
company, then a block of ipv4 addresses changes from a non-depreciable 
fixture to an operational cost for using an asset for as long as the 
fees are paid, i.e. a rental arrangement.  Selling the holding company 
is straightforward.

In other words, what you're effectively proposing is that the RIPE NCC 
enters the ipv4 address rental market, and competes with existing market 
operators, with no real protection against address transfers.

This may not be what you or other people intend to suggest, or want, but 
it is the practical outcome.

Nick

User Image

Randy Bush

2021-12-08 19:41:37 CET

>>> C) IPv4 waiting list priority follows the size of existing
>>> allocations for the LIR. The lower amount of allocations, starting
>>> with zero, the higher the priority.
>>
>> if the purpose of new allocations is to allow entry, why would an LIR
>> with any existing allocation be given more?
> 
> That would only happen if there are zero new entrants, as an LIR with any
> existing allocation would have a lower priority on the waiting list.

i asked why, not how.  imiho, the list should be for *new* entrants,
period.

randy

denis walker

2021-12-08 20:35:47 CET

You have overlooked a couple of points here Nick.

On Wed, 8 Dec 2021 at 19:30, Nick Hilliard <nick _at_ foobar _dot_ org> wrote:
>
> denis walker wrote on 08/12/2021 17:43:
> > I would suggest that the free pool of IPv4 that the RIPE NCC has from
> > time to time should only be used to allow new startups to enter the
> > business. Transfers on these new startup blocks should not be allowed,
> > ever.
>
> What your suggestion does is acknowledge that ipv4 address space has
> asset value.  Financial value of an asset is measured either in terms of
> capital value (probably non-depreciable in the case of ipv4), or as an
> operational cost.

When IPv6 becomes the dominant variant, the capital value of IPv4
depreciates to zero. Until then, address space you have bought on the
open market, or were allocated prior to runout, does have a capital
asset value. Holding any IPv4 addresses has an operational cost.

>
> If there's no ability to transfer the objects out of the holding
> company, then a block of ipv4 addresses changes from a non-depreciable
> fixture to an operational cost for using an asset for as long as the
> fees are paid, i.e. a rental arrangement.  Selling the holding company
> is straightforward.

This would only apply to these last dregs of address space used to
allow fair competition. It does not 'change' to an operating cost.
Holding any address space has an operating cost no matter how you
received it. It doesn't 'change from' a non depreciable fixture as you
did not pay for it.

>
> In other words, what you're effectively proposing is that the RIPE NCC
> enters the ipv4 address rental market, and competes with existing market
> operators, with no real protection against address transfers.

Since it's formation the RIPE NCC has been in the address rental
market. This is what it always has and continues to do. Before runout,
if you wanted address space the RIPE NCC 'rented', or allocated,
address space to you. The cost of the rental, or general service,
agreement was the LIR fee. If you no longer needed the address space
you returned it to the RIPE NCC, or rental company, and terminated
your rental agreement.

The RIPE NCC will not be competing with existing market operators.
They can buy and sell any address space, except this tiny fragment
used to allow new startups. The RIPE NCC can only rent out this last
tiny fragment.

cheers
denis
co-chair DB-WG

>
> This may not be what you or other people intend to suggest, or want, but
> it is the practical outcome.
>
> Nick

Nick Hilliard

2021-12-09 01:26:35 CET

denis walker wrote on 08/12/2021 19:35:
> Since it's formation the RIPE NCC has been in the address rental
> market. This is what it always has and continues to do.

The LIR fee is an association membership fee, and the RIPE NCC has taken 
pains over the years to emphasise that the membership fee is not linked 
directly to address allocation quantities, because that could be 
construed to be a quid-pro-quo services arrangement.

Prohibiting transfers will cause the RIPE NCC to move towards a model of 
intrinsically linking the registration fee to a specific quantity of 
resources.  This is because there is a fixed annual fee, and the 
quantity of address space is fixed if the end user acquires holdership 
of more than one of these /24s. I.e. if an end user has one of these 
/24s, they can rationalise costs by moving any existing ip address 
allocations into the /24 LIR, but if they have two or more of these 
/24s, then there is no cost advantage to doing this.

If the effective rental fee is higher than market rates, then there's no 
value to startup end users.  If it's lower, then the RIPE NCC is 
competing with existing market operators and potentially distorting the 
market, but with an effective competitive advantage in terms of having a 
monopoly on being able to reclaim unused ip address space from former 
LIRs.  This would be an awkward position for the RIPE NCC to put itself 
into.

I sympathise with what you're trying to achieve here: you want to design 
a policy mechanism which prioritises new entrants who need IPv4 
resources so that legitimate new businesses can operate successfullt. 
Problem is, none of the mechanisms that have been proposed so far on 
apwg are going to work, or else they are likely to have unexpected and 
potentially serious downstream consequences.

Nick

User Image

Gert Doering

2021-12-09 08:56:48 CET

Hi,

On Thu, Dec 09, 2021 at 12:26:35AM +0000, Nick Hilliard wrote:
> I sympathise with what you're trying to achieve here: you want to design 
> a policy mechanism which prioritises new entrants who need IPv4 
> resources so that legitimate new businesses can operate successfullt. 
> Problem is, none of the mechanisms that have been proposed so far on 
> apwg are going to work, or else they are likely to have unexpected and 
> potentially serious downstream consequences.

So, if you were to decide, what would you do?

Gert
-- 
have you enabled IPv6 on something today...?

SpaceNet AG                      Vorstand: Sebastian v. Bomhard, Michael Emmer
Joseph-Dollinger-Bogen 14        Aufsichtsratsvors.: A. Grundner-Culemann
D-80807 Muenchen                 HRB: 136055 (AG Muenchen)
Tel: +49 (0)89/32356-444         USt-IdNr.: DE813185279
User Image

Marco Schmidt

2021-12-09 17:13:07 CET

RIPE NCC staff member

Dear Arash,

Thank you for your question.

At the moment, we see 98 members with 10 or more LIR accounts. These 
members have received a total of 1254 /24s under the current IPv4 
waiting list policy.

I would like to note that these numbers are constantly changing. On the 
one hand, some members continue to open additional LIR accounts, while 
other members consolidate or close many LIR accounts as soon as the 
24-month holding period expires. This also explains the slight 
difference from the previously published numbers. Several members that 
held 10 or more accounts when they received /24s have since reduced 
their number of LIRs.

I hope this answers your question.

Kind regards,
Marco Schmidt
Assistant Manager Registry Services
RIPE NCC

On 08/12/2021 12:39, Arash Naderpour wrote:
> Hi Marco,
>
> Could you please let me know how many organizations have 10 or more 
> LIR accounts?
>
> Thanks,
>
> Arash Naderpour
>
> On Tue, Dec 7, 2021 at 8:22 PM Marco Schmidt <mschmidt _at_ ripe _dot_ net> wrote:
>
>     Dear colleagues,
>
>     In the Address Policy Working Group sessions at RIPE 83, I shared our
>     observations regarding the IPv4 waiting list policy. [1]
>
>     The intent of this policy was to provide newcomers with a minimal
>     amount
>     of IPv4 space for as long as possible. However, about half of these
>     allocations went to members that received several /24 allocations via
>     multiple LIR accounts.
>
>     As there was interest in reviewing the policy at the RIPE Meeting, I
>     would like to provide more detail on the provision of IPv4
>     allocations
>     over the last two years and the current situation with the waiting
>     list.
>
>     In the last 24 months, we provided 4,178 LIRs with a /24 allocation:
>     -    2,019 allocations (48%) went to members with a single LIR account
>     -    452 allocations (11%) went to members with 2-4 LIR accounts
>     -    298 allocations (7%) went to members with 5-9 LIR accounts and
>     -    1,409 allocations (34%) went to members with 10 or more LIR
>     accounts (up to 33 /24 allocations to a single member)
>
>     This trend towards allocations to multiple LIR accounts has
>     accelerated
>     in the past six months. Between June and November 2021, only 24% of
>     allocations went to members with a single LIR account, while 54%
>     went to
>     members with 10 or more accounts.
>
>     We see the same trend with the current waiting list. At the time of
>     writing, we can see 327 requests for a /24 allocation:
>     -    83 (25%) are from members with a single LIR account
>     -    42 (13%) are from members with 2-4 LIRs accounts
>     -    45 (14%) are from members with 5-9 LIR accounts
>     -    157 (48%) are from members with 10 or more LIR accounts
>
>     Consequently, there is a significantly longer wait time for
>     members with
>     a single LIR account.
>
>     Looking at the current market prices for IPv4 in comparison to our
>     membership fees, even a wait time of several months is acceptable for
>     organisations that plan to transfer their allocation after the end of
>     the holding period. Conversely, the long wait time will create
>     uncertainty for real newcomers, especially if they can’t rely on
>     IPv6-only networks.
>
>     I hope the WG finds this information useful for further
>     discussion. If
>     there is consensus to change the current situation, there are several
>     approaches available – including a review of the waiting list
>     policy and
>     changing ‘per LIR’ to something else. Other approaches, such as a
>     different charging scheme or changing the concept of multiple LIRs
>     would
>     need to be approved by the RIPE NCC membership.
>
>     Kind regards,
>     Marco Schmidt
>     Assistant Manager Registry Services
>     RIPE NCC
>
>     [1] https://ripe83.ripe.net/archives/video/642/
>
>
>     -- 
>
>     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-09 19:29:37 CET

Hi Marco

I have a few more questions for you so have a clearer picture of what
is going on here.

-How many of these 98 members have operated the first LIR account for
a number of years and held a significant amount of IPv4 address space
with that account?
(What I am trying to understand is if any of these members were not
operating at all as an LIR before setting up this series of LIR
accounts simply to obtain address space they have no intention of
using but is only to sell.)

-Are any of these 98 organisations transfer brokers?
(I am sure it does not break any confidentiality rules to identify the
type of business a group of unnamed members operate.)

-Are any of these 98 organisations based in the USA?

-Over what time period were their other 9 or more accounts created?

-How many of these 1254 /24s have been assigned or are detectably in use?

-What is the most LIRs any one member holds and how many /24s has that
member obtained?

-How many members have 5-9 LIRs?

-How many /24s have been allocated under the waiting list policy and
transferred within 6 months of the end of the 2 year holding period?

This should keep your analysts busy for a while :)

cheers
denis
co-chair DB-WG


btw your document
https://www.ripe.net/manage-ips-and-asns/ipv4/how-waiting-list-works
references an outdated version of the IPv4 policy

On Thu, 9 Dec 2021 at 17:13, Marco Schmidt <mschmidt _at_ ripe _dot_ net> wrote:
>
> Dear Arash,
>
> Thank you for your question.
>
> At the moment, we see 98 members with 10 or more LIR accounts. These members have received a total of 1254 /24s under the current IPv4 waiting list policy.
>
> I would like to note that these numbers are constantly changing. On the one hand, some members continue to open additional LIR accounts, while other members consolidate or close many LIR accounts as soon as the 24-month holding period expires. This also explains the slight difference from the previously published numbers. Several members that held 10 or more accounts when they received /24s have since reduced their number of LIRs.
>
> I hope this answers your question.
>
> Kind regards,
> Marco Schmidt
> Assistant Manager Registry Services
> RIPE NCC
>
> On 08/12/2021 12:39, Arash Naderpour wrote:
>
> Hi Marco,
>
> Could you please let me know how many organizations have 10 or more LIR accounts?
>
> Thanks,
>
> Arash Naderpour
>
> On Tue, Dec 7, 2021 at 8:22 PM Marco Schmidt <mschmidt _at_ ripe _dot_ net> wrote:
>>
>> Dear colleagues,
>>
>> In the Address Policy Working Group sessions at RIPE 83, I shared our
>> observations regarding the IPv4 waiting list policy. [1]
>>
>> The intent of this policy was to provide newcomers with a minimal amount
>> of IPv4 space for as long as possible. However, about half of these
>> allocations went to members that received several /24 allocations via
>> multiple LIR accounts.
>>
>> As there was interest in reviewing the policy at the RIPE Meeting, I
>> would like to provide more detail on the provision of IPv4 allocations
>> over the last two years and the current situation with the waiting list.
>>
>> In the last 24 months, we provided 4,178 LIRs with a /24 allocation:
>> -    2,019 allocations (48%) went to members with a single LIR account
>> -    452 allocations (11%) went to members with 2-4 LIR accounts
>> -    298 allocations (7%) went to members with 5-9 LIR accounts and
>> -    1,409 allocations (34%) went to members with 10 or more LIR
>> accounts (up to 33 /24 allocations to a single member)
>>
>> This trend towards allocations to multiple LIR accounts has accelerated
>> in the past six months. Between June and November 2021, only 24% of
>> allocations went to members with a single LIR account, while 54% went to
>> members with 10 or more accounts.
>>
>> We see the same trend with the current waiting list. At the time of
>> writing, we can see 327 requests for a /24 allocation:
>> -    83 (25%) are from members with a single LIR account
>> -    42 (13%) are from members with 2-4 LIRs accounts
>> -    45 (14%) are from members with 5-9 LIR accounts
>> -    157 (48%) are from members with 10 or more LIR accounts
>>
>> Consequently, there is a significantly longer wait time for members with
>> a single LIR account.
>>
>> Looking at the current market prices for IPv4 in comparison to our
>> membership fees, even a wait time of several months is acceptable for
>> organisations that plan to transfer their allocation after the end of
>> the holding period. Conversely, the long wait time will create
>> uncertainty for real newcomers, especially if they can’t rely on
>> IPv6-only networks.
>>
>> I hope the WG finds this information useful for further discussion. If
>> there is consensus to change the current situation, there are several
>> approaches available – including a review of the waiting list policy and
>> changing ‘per LIR’ to something else. Other approaches, such as a
>> different charging scheme or changing the concept of multiple LIRs would
>> need to be approved by the RIPE NCC membership.
>>
>> Kind regards,
>> Marco Schmidt
>> Assistant Manager Registry Services
>> RIPE NCC
>>
>> [1] https://ripe83.ripe.net/archives/video/642/
>>
>>
>> --
>>
>> 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

User Image

James Kennedy

2021-12-09 20:36:08 CET

> This should keep your analysts busy for a while :)

A slightly more respectful tone for the hard work performed by the RIPE NCC
analysts to answer not-so-easy questions would be appreciated, Denis.

Regards,
James
co-chair apwg



On Thu, Dec 9, 2021 at 7:30 PM denis walker <ripedenis _at_ gmail _dot_ com> wrote:

> Hi Marco
>
> I have a few more questions for you so have a clearer picture of what
> is going on here.
>
> -How many of these 98 members have operated the first LIR account for
> a number of years and held a significant amount of IPv4 address space
> with that account?
> (What I am trying to understand is if any of these members were not
> operating at all as an LIR before setting up this series of LIR
> accounts simply to obtain address space they have no intention of
> using but is only to sell.)
>
> -Are any of these 98 organisations transfer brokers?
> (I am sure it does not break any confidentiality rules to identify the
> type of business a group of unnamed members operate.)
>
> -Are any of these 98 organisations based in the USA?
>
> -Over what time period were their other 9 or more accounts created?
>
> -How many of these 1254 /24s have been assigned or are detectably in use?
>
> -What is the most LIRs any one member holds and how many /24s has that
> member obtained?
>
> -How many members have 5-9 LIRs?
>
> -How many /24s have been allocated under the waiting list policy and
> transferred within 6 months of the end of the 2 year holding period?
>
> This should keep your analysts busy for a while :)
>
> cheers
> denis
> co-chair DB-WG
>
>
> btw your document
> https://www.ripe.net/manage-ips-and-asns/ipv4/how-waiting-list-works
> references an outdated version of the IPv4 policy
>
> On Thu, 9 Dec 2021 at 17:13, Marco Schmidt <mschmidt _at_ ripe _dot_ net> wrote:
> >
> > Dear Arash,
> >
> > Thank you for your question.
> >
> > At the moment, we see 98 members with 10 or more LIR accounts. These
> members have received a total of 1254 /24s under the current IPv4 waiting
> list policy.
> >
> > I would like to note that these numbers are constantly changing. On the
> one hand, some members continue to open additional LIR accounts, while
> other members consolidate or close many LIR accounts as soon as the
> 24-month holding period expires. This also explains the slight difference
> from the previously published numbers. Several members that held 10 or more
> accounts when they received /24s have since reduced their number of LIRs.
> >
> > I hope this answers your question.
> >
> > Kind regards,
> > Marco Schmidt
> > Assistant Manager Registry Services
> > RIPE NCC
> >
> > On 08/12/2021 12:39, Arash Naderpour wrote:
> >
> > Hi Marco,
> >
> > Could you please let me know how many organizations have 10 or more LIR
> accounts?
> >
> > Thanks,
> >
> > Arash Naderpour
> >
> > On Tue, Dec 7, 2021 at 8:22 PM Marco Schmidt <mschmidt _at_ ripe _dot_ net> wrote:
> >>
> >> Dear colleagues,
> >>
> >> In the Address Policy Working Group sessions at RIPE 83, I shared our
> >> observations regarding the IPv4 waiting list policy. [1]
> >>
> >> The intent of this policy was to provide newcomers with a minimal amount
> >> of IPv4 space for as long as possible. However, about half of these
> >> allocations went to members that received several /24 allocations via
> >> multiple LIR accounts.
> >>
> >> As there was interest in reviewing the policy at the RIPE Meeting, I
> >> would like to provide more detail on the provision of IPv4 allocations
> >> over the last two years and the current situation with the waiting list.
> >>
> >> In the last 24 months, we provided 4,178 LIRs with a /24 allocation:
> >> -    2,019 allocations (48%) went to members with a single LIR account
> >> -    452 allocations (11%) went to members with 2-4 LIR accounts
> >> -    298 allocations (7%) went to members with 5-9 LIR accounts and
> >> -    1,409 allocations (34%) went to members with 10 or more LIR
> >> accounts (up to 33 /24 allocations to a single member)
> >>
> >> This trend towards allocations to multiple LIR accounts has accelerated
> >> in the past six months. Between June and November 2021, only 24% of
> >> allocations went to members with a single LIR account, while 54% went to
> >> members with 10 or more accounts.
> >>
> >> We see the same trend with the current waiting list. At the time of
> >> writing, we can see 327 requests for a /24 allocation:
> >> -    83 (25%) are from members with a single LIR account
> >> -    42 (13%) are from members with 2-4 LIRs accounts
> >> -    45 (14%) are from members with 5-9 LIR accounts
> >> -    157 (48%) are from members with 10 or more LIR accounts
> >>
> >> Consequently, there is a significantly longer wait time for members with
> >> a single LIR account.
> >>
> >> Looking at the current market prices for IPv4 in comparison to our
> >> membership fees, even a wait time of several months is acceptable for
> >> organisations that plan to transfer their allocation after the end of
> >> the holding period. Conversely, the long wait time will create
> >> uncertainty for real newcomers, especially if they can’t rely on
> >> IPv6-only networks.
> >>
> >> I hope the WG finds this information useful for further discussion. If
> >> there is consensus to change the current situation, there are several
> >> approaches available – including a review of the waiting list policy and
> >> changing ‘per LIR’ to something else. Other approaches, such as a
> >> different charging scheme or changing the concept of multiple LIRs would
> >> need to be approved by the RIPE NCC membership.
> >>
> >> Kind regards,
> >> Marco Schmidt
> >> Assistant Manager Registry Services
> >> RIPE NCC
> >>
> >> [1] https://ripe83.ripe.net/archives/video/642/
> >>
> >>
> >> --
> >>
> >> 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
>
> --
>
> 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-09 21:19:09 CET

On Thu, 9 Dec 2021 at 20:36, James Kennedy <jameskennedy001 _at_ gmail _dot_ com> wrote:
>
> > This should keep your analysts busy for a while :)
>
> A slightly more respectful tone for the hard work performed by the RIPE NCC analysts to answer not-so-easy questions would be appreciated, Denis.

As a former RIPE NCC analyst, who has answered many such requests in
the past and is well aware of the amount of work involved, speaking to
other analysts, that was not in any way intended to be disrespectful
James.

cheers
denis
co-chair DB-WG

>
> Regards,
> James
> co-chair apwg
>
>
>
> On Thu, Dec 9, 2021 at 7:30 PM denis walker <ripedenis _at_ gmail _dot_ com> wrote:
>>
>> Hi Marco
>>
>> I have a few more questions for you so have a clearer picture of what
>> is going on here.
>>
>> -How many of these 98 members have operated the first LIR account for
>> a number of years and held a significant amount of IPv4 address space
>> with that account?
>> (What I am trying to understand is if any of these members were not
>> operating at all as an LIR before setting up this series of LIR
>> accounts simply to obtain address space they have no intention of
>> using but is only to sell.)
>>
>> -Are any of these 98 organisations transfer brokers?
>> (I am sure it does not break any confidentiality rules to identify the
>> type of business a group of unnamed members operate.)
>>
>> -Are any of these 98 organisations based in the USA?
>>
>> -Over what time period were their other 9 or more accounts created?
>>
>> -How many of these 1254 /24s have been assigned or are detectably in use?
>>
>> -What is the most LIRs any one member holds and how many /24s has that
>> member obtained?
>>
>> -How many members have 5-9 LIRs?
>>
>> -How many /24s have been allocated under the waiting list policy and
>> transferred within 6 months of the end of the 2 year holding period?
>>
>> This should keep your analysts busy for a while :)
>>
>> cheers
>> denis
>> co-chair DB-WG
>>
>>
>> btw your document
>> https://www.ripe.net/manage-ips-and-asns/ipv4/how-waiting-list-works
>> references an outdated version of the IPv4 policy
>>
>> On Thu, 9 Dec 2021 at 17:13, Marco Schmidt <mschmidt _at_ ripe _dot_ net> wrote:
>> >
>> > Dear Arash,
>> >
>> > Thank you for your question.
>> >
>> > At the moment, we see 98 members with 10 or more LIR accounts. These members have received a total of 1254 /24s under the current IPv4 waiting list policy.
>> >
>> > I would like to note that these numbers are constantly changing. On the one hand, some members continue to open additional LIR accounts, while other members consolidate or close many LIR accounts as soon as the 24-month holding period expires. This also explains the slight difference from the previously published numbers. Several members that held 10 or more accounts when they received /24s have since reduced their number of LIRs.
>> >
>> > I hope this answers your question.
>> >
>> > Kind regards,
>> > Marco Schmidt
>> > Assistant Manager Registry Services
>> > RIPE NCC
>> >
>> > On 08/12/2021 12:39, Arash Naderpour wrote:
>> >
>> > Hi Marco,
>> >
>> > Could you please let me know how many organizations have 10 or more LIR accounts?
>> >
>> > Thanks,
>> >
>> > Arash Naderpour
>> >
>> > On Tue, Dec 7, 2021 at 8:22 PM Marco Schmidt <mschmidt _at_ ripe _dot_ net> wrote:
>> >>
>> >> Dear colleagues,
>> >>
>> >> In the Address Policy Working Group sessions at RIPE 83, I shared our
>> >> observations regarding the IPv4 waiting list policy. [1]
>> >>
>> >> The intent of this policy was to provide newcomers with a minimal amount
>> >> of IPv4 space for as long as possible. However, about half of these
>> >> allocations went to members that received several /24 allocations via
>> >> multiple LIR accounts.
>> >>
>> >> As there was interest in reviewing the policy at the RIPE Meeting, I
>> >> would like to provide more detail on the provision of IPv4 allocations
>> >> over the last two years and the current situation with the waiting list.
>> >>
>> >> In the last 24 months, we provided 4,178 LIRs with a /24 allocation:
>> >> -    2,019 allocations (48%) went to members with a single LIR account
>> >> -    452 allocations (11%) went to members with 2-4 LIR accounts
>> >> -    298 allocations (7%) went to members with 5-9 LIR accounts and
>> >> -    1,409 allocations (34%) went to members with 10 or more LIR
>> >> accounts (up to 33 /24 allocations to a single member)
>> >>
>> >> This trend towards allocations to multiple LIR accounts has accelerated
>> >> in the past six months. Between June and November 2021, only 24% of
>> >> allocations went to members with a single LIR account, while 54% went to
>> >> members with 10 or more accounts.
>> >>
>> >> We see the same trend with the current waiting list. At the time of
>> >> writing, we can see 327 requests for a /24 allocation:
>> >> -    83 (25%) are from members with a single LIR account
>> >> -    42 (13%) are from members with 2-4 LIRs accounts
>> >> -    45 (14%) are from members with 5-9 LIR accounts
>> >> -    157 (48%) are from members with 10 or more LIR accounts
>> >>
>> >> Consequently, there is a significantly longer wait time for members with
>> >> a single LIR account.
>> >>
>> >> Looking at the current market prices for IPv4 in comparison to our
>> >> membership fees, even a wait time of several months is acceptable for
>> >> organisations that plan to transfer their allocation after the end of
>> >> the holding period. Conversely, the long wait time will create
>> >> uncertainty for real newcomers, especially if they can’t rely on
>> >> IPv6-only networks.
>> >>
>> >> I hope the WG finds this information useful for further discussion. If
>> >> there is consensus to change the current situation, there are several
>> >> approaches available – including a review of the waiting list policy and
>> >> changing ‘per LIR’ to something else. Other approaches, such as a
>> >> different charging scheme or changing the concept of multiple LIRs would
>> >> need to be approved by the RIPE NCC membership.
>> >>
>> >> Kind regards,
>> >> Marco Schmidt
>> >> Assistant Manager Registry Services
>> >> RIPE NCC
>> >>
>> >> [1] https://ripe83.ripe.net/archives/video/642/
>> >>
>> >>
>> >> --
>> >>
>> >> 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
>>
>> --
>>
>> 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

Florian Fuessl

2021-12-10 04:59:26 CET

Personally, I think a mixed approach may help to decrease the pressure on the IPv4 waitlist.
Actions should aim to make it unattractive for address brokers to open new LIR accounts to gain capital profit from IPv4 assets.

It should not block reasonable legal actions on mergers, acquisitions, or other changes in the business structure of LIRs.

Therefore instead of locking IPv4 resources from the IPv4 waitlist as non-transferable, it’s probably more effective to set up an inverse fee on these types of changes in the LIR business structure.

For example:
- leave the existing policy blocking these actions within the first 24 months.
- after 24 months a one-time fee like ( 10 {years} - $years-of-membership ) * $current-annual-LIR-service-fee has to be paid to execute mergers and acquisitions including IPv4 resources.

The gain of the policy change should be:
- not to affect long time LIRs and reasonable resource usage
- allow changes in the business structure of LIRs

Having to pay a painful one-time service fee after the lock period makes it a risky deal for address brokers to incorporate new LIR startups to gain cheap IPv4 resources for later sale or mergers.
But it is not going to block reasonable changes in business structure.

Kind regards
Florian Fuessl 

> Am 09.12.2021 um 08:56 schrieb Gert Doering <gert _at_ space _dot_ net>:
> 
> Signierter PGP-Teil
> Hi,
> 
> On Thu, Dec 09, 2021 at 12:26:35AM +0000, Nick Hilliard wrote:
>> I sympathise with what you're trying to achieve here: you want to design 
>> a policy mechanism which prioritises new entrants who need IPv4 
>> resources so that legitimate new businesses can operate successfullt. 
>> Problem is, none of the mechanisms that have been proposed so far on 
>> apwg are going to work, or else they are likely to have unexpected and 
>> potentially serious downstream consequences.
> 
> So, if you were to decide, what would you do?
> 
> Gert
> -- 
> have you enabled IPv6 on something today...?
> 
> SpaceNet AG                      Vorstand: Sebastian v. Bomhard, Michael Emmer
> Joseph-Dollinger-Bogen 14        Aufsichtsratsvors.: A. Grundner-Culemann
> D-80807 Muenchen                 HRB: 136055 (AG Muenchen)
> Tel: +49 (0)89/32356-444         USt-IdNr.: DE813185279
> 
> 


Jan Ingvoldstad

2021-12-10 06:52:05 CET

On Wed, Dec 8, 2021 at 7:41 PM Randy Bush <randy _at_ psg _dot_ com> wrote:

> >>> C) IPv4 waiting list priority follows the size of existing
> >>> allocations for the LIR. The lower amount of allocations, starting
> >>> with zero, the higher the priority.
> >>
> >> if the purpose of new allocations is to allow entry, why would an LIR
> >> with any existing allocation be given more?
> >
> > That would only happen if there are zero new entrants, as an LIR with any
> > existing allocation would have a lower priority on the waiting list.
>
> i asked why, not how.  imiho, the list should be for *new* entrants,
> period.
>

If there are no new entrants, why should any available netblocks be kept
unavailable for entrants who request additional netblocks?

Not that I think it will ever happen ...

-- 
Jan
User Image

Mathias Westerlund

2021-12-10 10:17:52 CET

Hello, I would just like to chime in on this aswell, not as much as a long
standing member with lots of experience of being an LIR or even an RIPE
member, but rather on the complete opposite side of the spectrum.

We are an VERY small ISP/MSP that have been approached by an fairly (the
largest) FTTH provider in the nordics to be bundled as ISP for home
consumers and MSP/ISP for companies they install fiber for during the next
year or two in central sweden.

This means that for us we are now under massive pressure to acquire all the
resources required to start delivering this in january/February from the
new datacenters in two more locations and all the links as well as the IP
ranges we intend to use for CG:nat for our consumer customers.
We have an  /24 from prior to us becoming an member but that is entirely
allocated to our WISP service and our primary hosting datacenter. We
started the process of becoming an member and LIR about a week prior to the
meetings (Unbeknownst to us) at that point there was zero in line for the
/24 allocations and we were feeling confident that "Any day now our
application will go through nd we can get an /24 almost immediatly" that is
almost a month ago now and in the 5 days from that until when we could
actually request an allocation as we finally became an member the queue
became 150-200 ish and has only gone up since with the "Longest waiting"
application going up with one day every days, and as such the queue is
standing still solid.

This is worrying from us because even if we are planning to use IPv6 native
on everything and all clients there is sadly a massive ammount of IPv4
still needed especially as an ISP.

What this means for us is that we are now being forced into becoming one of
the buyers for the ranges that was intended for usecases like us but have
been grabbed by organizations only intending to sell them. Causing us to
pay way more for these IPadresses than we should have to really.

I will be quite frank about this and say that it feel very disheartening to
essentially miss the 0 day queue allocations by 5 days. end up in a one
month long quque that just grows with no more allocations and on top of
that it is VERY obvious that these organisations uses the members list as a
"To be customers" base because about 4 hours after we became members we got
mails and phonecalls from about 5 different companies stating they want to
sell us IP adresses.

It just feels like this is not what RIPE was intended for but obviously is
being used for.

I apologize if i am sounding too salty or if my mail is not according to
well established RIPE etiquette, and dont get me wrong. we are VERY happy
about being a new member with a single LIR and getting our own IPv6 and
insight into the future of the internet, just felt that i should give the
point of view of exactly one of those "Small new one lir members" that many
here reffer to and exactly how our experience with this issue has been..

Regards, Mathias W
CEO / Infrastructure Architect - West Digital Management AB.

On Fri, Dec 10, 2021 at 4:59 AM Florian Fuessl <flo _at_ degnet _dot_ de> wrote:

> Personally, I think a mixed approach may help to decrease the pressure on
> the IPv4 waitlist.
> Actions should aim to make it unattractive for address brokers to open new
> LIR accounts to gain capital profit from IPv4 assets.
>
> It should not block reasonable legal actions on mergers, acquisitions, or
> other changes in the business structure of LIRs.
>
> Therefore instead of locking IPv4 resources from the IPv4 waitlist as
> non-transferable, it’s probably more effective to set up an inverse fee on
> these types of changes in the LIR business structure.
>
> For example:
> - leave the existing policy blocking these actions within the first 24
> months.
> - after 24 months a one-time fee like ( 10 {years} - $years-of-membership
> ) * $current-annual-LIR-service-fee has to be paid to execute mergers and
> acquisitions including IPv4 resources.
>
> The gain of the policy change should be:
> - not to affect long time LIRs and reasonable resource usage
> - allow changes in the business structure of LIRs
>
> Having to pay a painful one-time service fee after the lock period makes
> it a risky deal for address brokers to incorporate new LIR startups to gain
> cheap IPv4 resources for later sale or mergers.
> But it is not going to block reasonable changes in business structure.
>
> Kind regards
> Florian Fuessl
>
> > Am 09.12.2021 um 08:56 schrieb Gert Doering <gert _at_ space _dot_ net>:
> >
> > Signierter PGP-Teil
> > Hi,
> >
> > On Thu, Dec 09, 2021 at 12:26:35AM +0000, Nick Hilliard wrote:
> >> I sympathise with what you're trying to achieve here: you want to
> design
> >> a policy mechanism which prioritises new entrants who need IPv4
> >> resources so that legitimate new businesses can operate successfullt.
> >> Problem is, none of the mechanisms that have been proposed so far on
> >> apwg are going to work, or else they are likely to have unexpected and
> >> potentially serious downstream consequences.
> >
> > So, if you were to decide, what would you do?
> >
> > Gert
> > --
> > have you enabled IPv6 on something today...?
> >
> > SpaceNet AG                      Vorstand: Sebastian v. Bomhard, Michael
> Emmer
> > Joseph-Dollinger-Bogen 14        Aufsichtsratsvors.: A. Grundner-Culemann
> > D-80807 Muenchen                 HRB: 136055 (AG Muenchen)
> > Tel: +49 (0)89/32356-444         USt-IdNr.: DE813185279
> >
> >
>
>
> --
>
> 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

Sander Steffann

2021-12-10 10:58:49 CET

Hi Mathias,

> I will be quite frank about this and say that it feel very disheartening to essentially miss the 0 day queue allocations by 5 days. end up in a one month long quque that just grows with no more allocations and on top of that it is VERY obvious that these organisations uses the members list as a "To be customers" base because about 4 hours after we became members we got mails and phonecalls from about 5 different companies stating they want to sell us IP adresses.
> 
> It just feels like this is not what RIPE was intended for but obviously is being used for.
> 
> I apologize if i am sounding too salty or if my mail is not according to well established RIPE etiquette, and dont get me wrong. we are VERY happy about being a new member with a single LIR and getting our own IPv6 and insight into the future of the internet, just felt that i should give the point of view of exactly one of those "Small new one lir members" that many here reffer to and exactly how our experience with this issue has been..

Don't worry, you talk about your frustration quite politely :)  And it is totally justified. This is why I think something needs to be done now. Yes, it's rearranging deckchairs on the Titanic, but some people are still trying to survive.

As a new member, what do you think about these ideas? Would it be good to make addresses untransferable? Or keep them transferable but ask the NCC to impose a one-time merger&acquisition fee? Or any other way? What would be ok for your real internet business but not for address sellers?

Cheers,
Sander


User Image

James Kennedy

2021-12-10 13:58:51 CET

Hi Mathias,

Your perspective as a new LIR and experience with the IPv4 waiting is
warmly welcome, thank you. Sharing these real-life stories and explaining
actual impacts being felt in the community can only help our policy
building and correct implementation.

Would any other new LIRs like to share their stories? Or perhaps one of the
members involved in merging multiple LIRs that hold /24 PA Allocations?

Regards,
James
co-chair apwg


On Fri, Dec 10, 2021 at 10:18 AM Mathias Westerlund <
mathias.westerlund _at_ wdmab _dot_ se> wrote:

> Hello, I would just like to chime in on this aswell, not as much as a long
> standing member with lots of experience of being an LIR or even an RIPE
> member, but rather on the complete opposite side of the spectrum.
>
> We are an VERY small ISP/MSP that have been approached by an fairly (the
> largest) FTTH provider in the nordics to be bundled as ISP for home
> consumers and MSP/ISP for companies they install fiber for during the next
> year or two in central sweden.
>
> This means that for us we are now under massive pressure to acquire all
> the resources required to start delivering this in january/February from
> the new datacenters in two more locations and all the links as well as the
> IP ranges we intend to use for CG:nat for our consumer customers.
> We have an  /24 from prior to us becoming an member but that is entirely
> allocated to our WISP service and our primary hosting datacenter. We
> started the process of becoming an member and LIR about a week prior to the
> meetings (Unbeknownst to us) at that point there was zero in line for the
> /24 allocations and we were feeling confident that "Any day now our
> application will go through nd we can get an /24 almost immediatly" that is
> almost a month ago now and in the 5 days from that until when we could
> actually request an allocation as we finally became an member the queue
> became 150-200 ish and has only gone up since with the "Longest waiting"
> application going up with one day every days, and as such the queue is
> standing still solid.
>
> This is worrying from us because even if we are planning to use IPv6
> native on everything and all clients there is sadly a massive ammount of
> IPv4 still needed especially as an ISP.
>
> What this means for us is that we are now being forced into becoming one
> of the buyers for the ranges that was intended for usecases like us but
> have been grabbed by organizations only intending to sell them. Causing us
> to pay way more for these IPadresses than we should have to really.
>
> I will be quite frank about this and say that it feel very disheartening
> to essentially miss the 0 day queue allocations by 5 days. end up in a one
> month long quque that just grows with no more allocations and on top of
> that it is VERY obvious that these organisations uses the members list as a
> "To be customers" base because about 4 hours after we became members we got
> mails and phonecalls from about 5 different companies stating they want to
> sell us IP adresses.
>
> It just feels like this is not what RIPE was intended for but obviously is
> being used for.
>
> I apologize if i am sounding too salty or if my mail is not according to
> well established RIPE etiquette, and dont get me wrong. we are VERY happy
> about being a new member with a single LIR and getting our own IPv6 and
> insight into the future of the internet, just felt that i should give the
> point of view of exactly one of those "Small new one lir members" that many
> here reffer to and exactly how our experience with this issue has been..
>
> Regards, Mathias W
> CEO / Infrastructure Architect - West Digital Management AB.
>
> On Fri, Dec 10, 2021 at 4:59 AM Florian Fuessl <flo _at_ degnet _dot_ de> wrote:
>
>> Personally, I think a mixed approach may help to decrease the pressure on
>> the IPv4 waitlist.
>> Actions should aim to make it unattractive for address brokers to open
>> new LIR accounts to gain capital profit from IPv4 assets.
>>
>> It should not block reasonable legal actions on mergers, acquisitions, or
>> other changes in the business structure of LIRs.
>>
>> Therefore instead of locking IPv4 resources from the IPv4 waitlist as
>> non-transferable, it’s probably more effective to set up an inverse fee on
>> these types of changes in the LIR business structure.
>>
>> For example:
>> - leave the existing policy blocking these actions within the first 24
>> months.
>> - after 24 months a one-time fee like ( 10 {years} - $years-of-membership
>> ) * $current-annual-LIR-service-fee has to be paid to execute mergers and
>> acquisitions including IPv4 resources.
>>
>> The gain of the policy change should be:
>> - not to affect long time LIRs and reasonable resource usage
>> - allow changes in the business structure of LIRs
>>
>> Having to pay a painful one-time service fee after the lock period makes
>> it a risky deal for address brokers to incorporate new LIR startups to gain
>> cheap IPv4 resources for later sale or mergers.
>> But it is not going to block reasonable changes in business structure.
>>
>> Kind regards
>> Florian Fuessl
>>
>> > Am 09.12.2021 um 08:56 schrieb Gert Doering <gert _at_ space _dot_ net>:
>> >
>> > Signierter PGP-Teil
>> > Hi,
>> >
>> > On Thu, Dec 09, 2021 at 12:26:35AM +0000, Nick Hilliard wrote:
>> >> I sympathise with what you're trying to achieve here: you want to
>> design
>> >> a policy mechanism which prioritises new entrants who need IPv4
>> >> resources so that legitimate new businesses can operate successfullt.
>> >> Problem is, none of the mechanisms that have been proposed so far on
>> >> apwg are going to work, or else they are likely to have unexpected and
>> >> potentially serious downstream consequences.
>> >
>> > So, if you were to decide, what would you do?
>> >
>> > Gert
>> > --
>> > have you enabled IPv6 on something today...?
>> >
>> > SpaceNet AG                      Vorstand: Sebastian v. Bomhard,
>> Michael Emmer
>> > Joseph-Dollinger-Bogen 14        Aufsichtsratsvors.: A.
>> Grundner-Culemann
>> > D-80807 Muenchen                 HRB: 136055 (AG Muenchen)
>> > Tel: +49 (0)89/32356-444         USt-IdNr.: DE813185279
>> >
>> >
>>
>>
>> --
>>
>> 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
>

Nick Hilliard

2021-12-11 01:46:45 CET

Gert Doering wrote on 09/12/2021 07:56:
> So, if you were to decide, what would you do?

the ipv4 address market is now the largest global supplier of ipv4 
addresses. To put some figures on it, 11433920 addresses were 
transferred via the ripe ncc in 2021 so far 
(ripencc-transfers_latest.json), and 9696896 in 2020.

alloclist.txt shows 2981 /24 allocations so far in 2021, i.e. 763136 
addresses, and 1166 /24 allocations in 2020, i.e. 298496 addresses

I.e. the RIPE NCC allocated only 6.25% of the total address space which 
changed hands in the ripe region in 2021, and ~3% in 2020.

In a market situation like this, there are two ways of making an impact: 
1. by being a large enough market player that decisions you make will 
make a significant difference to the ecosystem and 2. by changing the 
rules - which RIPE / the RIPE NCC has some ability to do.

The RIPE NCC has historically been reluctant to interfere with past 
assignments, and it's unlikely that this will change. It doesn't have 
the market power to change the market substantially, and any rule change 
it makes will only affect new allocations.

In other words, a policy change from APWG, if implemented by the RIPE 
NCC, would only potentially affect a tiny percentage of address 
holdership changes, and would be unlikely to make much of a difference 
in the overall scheme of things.

In addition to this, Marco's email mentioned:

> In the last 24 months, we provided 4,178 LIRs with a /24 allocation:
> -    2,019 allocations (48%) went to members with a single LIR account

Allocations to members with a single LIR account are unlikely to be 
wholesale abusers.  Some of the LIRs with multiple accounts and /24s 
look like genuine ip address users (e.g. telcos / vpn hosting outfits / 
etc).

But a number of them look unusual, e.g. where the first entry on a web 
search for their company name is their RIPE LIR ID.

> So, if you were to decide, what would you do?

So, that.  If I were supreme ruler of the universe, I'd get more 
information about these peculiar-looking allocations, then make a 
decision about whether it was worth either changing policy or 
operational practice to block or restrict allocations of this form, then 
model some potential options in terms of risk / outcome, and then after 
thinking about it for a while, I might make a decision to change policy, 
or executive practice, or not, depending on the overall likely outcome. 
Right now we don't have enough data to work with.

Also, unless a fix actually fixes something, it's just busywork.

Sander was right though: we're talking about rearranging the deck chairs 
on the Titanic, and any discussion needs to be framed in this context.

Nick

User Image

Randy Bush

2021-12-11 03:52:42 CET

> Sander was right though: we're talking about rearranging the deck
> chairs on the Titanic

any betting pool on how many years the titanic will be the only viable
ship of entry for newcomers?  i'll take a decade.

no, we don't like it.  and it goes against the loudest religion.  but
packets gotta move; and users just want their mtv.

oh little snail
climb mt fuji

randy

User Image

Mathias Westerlund

2021-12-12 08:50:40 CET

Hi again and sorry for the delayed reply.

I realize it is not an easy thing to solve.
I also both feel and understand that something needs to be done due to the
situation at hand.

The problem is that many of the solutions i would think of may include
administration overhead, but i guess i will put forward two maybe three
ideas.

The first and easiest but that will not satisfy everyone is the most
obvious one.
Only allow new members to procure from the waiting list and make the
addresses nontransferable.

This would in my opinion be a stop gap for a bigger solution because we
cannot go ahead and block legitimate business needs for larger entities
just because of newcomers like myself.
However that ties into my second more realistic approach of what might be
accepted but also requires some changes on the administration.

How about simply having a split queue system?
New members with single LIR goes to the front of the line and gets an
nontransferable address.
Others will according to their number of existing LIRs or ranges go to the
back of the line according to their current ownership where an legitimate
need for more ranges constitutes an expected revenue across said ranges and
as such the bigger expectancy of acquiring larger ranges via an market
otherwise said ranges are not being utilized properly (i understand the
existence of non profits and edge cases but not everyone can be 100%
satisfied, neither can i with this in the future)
Make an buffer that is not possible to be allocated to multi LIRs/multi
range holders.
I am not an old member enough to have good insight to where a good buffer
would be but for arguments sake i would say 100.

This means that there is supposed to be 100 /24 ranges available (Could be
20 or 30 or anything RIPE agrees on) and as long as there is, the "Multi
holder Queue" would be able to request ranges against motivational uses.

There could even be a third queue at say 250 ranges available where all the
ranges above that goes to open market against the requirement that they
become used within x time and if they are to be resold they have to be
resold/rented out at fair pricing. This could be 25,50 or whatever, i don't
have the insight yet on how often ranges are allocated to give an accurate
number and will not pretend as such either.

This would guarantee that the original spirit of the /24's for newcomers
idea is retained, while adopting to the wishes of the larger members as
well to a degree, I fully understand that there are some really really big
entities out there with big needs for IPv4 still and i don't want to block
them in any way shape or form because i one day hope to be able to make use
of our ranges and services to become on of the really big players, with the
benefit of being such a new player that i can already today build IPv6
native and just use IPv4 for the still required things and then hopefully
phase out IPv4 and return our ranges down the road.

We today have as i mentioned earlier an single IPv4 /24 available for our
older WISP/MSP datacenter, It was acquired from an entity called Resilans
(If mentioning other entities by name is not allowed i apologize) they also
helped us with the process of becoming an LIR and ripe member so we are
VERY grateful to them as even tho they did charge for their time, it was a
fair price and we would not be here today without them.

Entities like them are in my opinion fair and could benefit from the third
queue where they did price fairly against us and didnt try to gouge us like
other entities that have contacted us after we became members (some asked
for outrageous prices for a single /24)
They also provide the ability for non members that cannot become members
for some reason to acquire IPs for their business, such as it was for us
back then. We didn't have any multi-homing ability which we now will with
Datacenter 2 (Which is our fiber ISP location) and our L2 link between
them. So we didn't even qualify until recently and we also didn't feel we
could justify for our then VERY small operations being an LIR and the
administration around that, there are others like us out there and for them
an resell/second hand renting market of IPv4 is very beneficial

We all know IPv4 is a sinking ship and we implement stop gaps such as NAT
and then CGNAT to try and prolong its inevitable doom, but until that day
comes i hope that my understanding of RIPE so far is accurate where you..
Us all try to make the playing field as equal as possible without hindering
each others opportunities.

Sorry for the mile long message but this is in my opinion one of several
potential ways to do this down the road that might help in some way.

I would also like to put out there the idea of presenting the number of
ranges in store on the LIR waiting list graph, it would serve two purposes.

It would allow small entities like us that when there is a 0 waiting line
to have an understanding of how soon there might be a queue again so we can
plan our potential entry as an LIR. I actually held off on us being an LIR
because we had so much else to prepare and get in place for our new
venture, if i would have seen the graph rapidly declining i would have
tried to become one sooner and perhaps been able to grab one prior to the
member days rather than come in 5 days after the waiting list shot up.

The second benefit would also be to drive home the acute situation to
everyone and perhaps open up for more understanding for the smaller
entities out there that have to rely on this service to get IPv4 other than
turning to in some cases heavily overpriced addresses.

One last thing before i end this already too long rant.
Thank you all so far for not only actually listening to a newcomers rant
about our opinion, but also truly showing to us that you really care about
our opinion and input. We cant wait to be able to bring back and contribute
to this community and hopefully prove our self worthy of the time and
consideration shown so far.

Very warm regards, Mathias W
CEO and Infrastructure Architect - West digital Management AB.

On Fri, Dec 10, 2021 at 10:58 AM Sander Steffann <sander _at_ steffann _dot_ nl> wrote:

> Hi Mathias,
>
> > I will be quite frank about this and say that it feel very disheartening
> to essentially miss the 0 day queue allocations by 5 days. end up in a one
> month long quque that just grows with no more allocations and on top of
> that it is VERY obvious that these organisations uses the members list as a
> "To be customers" base because about 4 hours after we became members we got
> mails and phonecalls from about 5 different companies stating they want to
> sell us IP adresses.
> >
> > It just feels like this is not what RIPE was intended for but obviously
> is being used for.
> >
> > I apologize if i am sounding too salty or if my mail is not according to
> well established RIPE etiquette, and dont get me wrong. we are VERY happy
> about being a new member with a single LIR and getting our own IPv6 and
> insight into the future of the internet, just felt that i should give the
> point of view of exactly one of those "Small new one lir members" that many
> here reffer to and exactly how our experience with this issue has been..
>
> Don't worry, you talk about your frustration quite politely :)  And it is
> totally justified. This is why I think something needs to be done now. Yes,
> it's rearranging deckchairs on the Titanic, but some people are still
> trying to survive.
>
> As a new member, what do you think about these ideas? Would it be good to
> make addresses untransferable? Or keep them transferable but ask the NCC to
> impose a one-time merger&acquisition fee? Or any other way? What would be
> ok for your real internet business but not for address sellers?
>
> Cheers,
> Sander
>
>
User Image

Mentor Leniqi

2021-12-12 11:22:22 CET

Hello there,

it is interesting to see that everyone is shooting to newcomers/new LIRs
and nobody is talking about existing one, it is not the issue to prevent
transfer resources, the issue is that almost 70% of members that have
multiple /20, /21, /22, /24, are renting the IPs. They took from RIPE and
renting out at minimal 150 upto 200€/month for a /24 subnet. The same thing
happen to us, as a small company that we cannot get more than a /24 subnet
we are forced to rent IPs from those who have multiple LIR accounts and
alot of IPs for mentioned price.
By implementing the non-transfer resources from newcomers/LIRs you will not
solve anything, or maybe a less precentage, but you will not stop big boys
with alot of resources to rent them with 200€/month (for now, the price
will go up) for a /24 subnet.
I do agree with Rick Bakker posts.

Kind Regards,
Mentor L.

-- 
*Sinqerisht / Sincerely,*
AlbHost [image: Logo] 

Albanian Hosting SH.P.K.
Besim Beka p.n.
50000 Gjakovë, Kosovë.
NIPT/VAT ID: 811442657
T: +386900501502
E: info _at_ albahost _dot_ net

W*: *wWw.AlbaHost.Net  [image: Facebook icon]
   [image: Twitter icon]
   [image: Instagram icon]


[image: 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.

Nick Hilliard

2021-12-13 01:32:30 CET

Mathias Westerlund wrote on 12/12/2021 07:50:
> I realize it is not an easy thing to solve.
> I also both feel and understand that something needs to be done due to 
> the situation at hand.

this situation can't be solved: it can only be managed.  There's a 
unresolvable high demand for number resources, and an unresolvable 
shortage of supply.

The challenge is to work out what categories of problems we can live 
with, and then devise policies to implement that.  This is how the 
current policies came into existence.

In regard to creating new policies or updating current ones:

- the ultimate aim is accurate registration of resources

- there is reluctance on the part of RIRs to deregister previously 
allocated number resources except in cases of contractual default

- due to the high perceived value of ipv4 address resources, reclaiming 
addresses due to contractual default is likely to slow down in future

- the greater the difference between supply and demand, the higher the 
price on the open market, and the more this will hurt organisations who 
need ip addresses, and the more demand there will be to change the rules 
to something else.

- "new entrant" companies can be created simply and quickly (i.e. 
prioritising "new entrants" will create more avenues to abuse the 
registration system).

- increasing the price of registration of addresses solves some problems 
but creates others

- the RIR cannot make a value judgement about whose legitimate need for 
IP addresses is more important

- some people will try hard to cheat the system, and some will succeed

- whatever policy is implemented, it needs to be applied fairly and 
rigorously

- the policies and implementations need to be compliant with local and 
regional laws / regulations

The intersection of these constraints rules out many options for 
creating new policies.

Nick


> The problem is that many of the solutions i would think of may include 
> administration overhead, but i guess i will put forward two maybe three 
> ideas.
> 
> The first and easiest but that will not satisfy everyone is the most 
> obvious one.
> Only allow new members to procure from the waiting list and make the 
> addresses nontransferable.
> 
> This would in my opinion be a stop gap for a bigger solution because we 
> cannot go ahead and block legitimate business needs for larger entities 
> just because of newcomers like myself.
> However that ties into my second more realistic approach of what might 
> be accepted but also requires some changes on the administration.
> 
> How about simply having a split queue system?
> New members with single LIR goes to the front of the line and gets an 
> nontransferable address.
> Others will according to their number of existing LIRs or ranges go to 
> the back of the line according to their current ownership where an 
> legitimate need for more ranges constitutes an expected revenue across 
> said ranges and as such the bigger expectancy of acquiring larger ranges 
> via an market otherwise said ranges are not being utilized properly (i 
> understand the existence of non profits and edge cases but not everyone 
> can be 100% satisfied, neither can i with this in the future)
> Make an buffer that is not possible to be allocated to multi LIRs/multi 
> range holders.
> I am not an old member enough to have good insight to where a good 
> buffer would be but for arguments sake i would say 100.
> 
> This means that there is supposed to be 100 /24 ranges available (Could 
> be 20 or 30 or anything RIPE agrees on) and as long as there is, the 
> "Multi holder Queue" would be able to request ranges against 
> motivational uses.
> 
> There could even be a third queue at say 250 ranges available where all 
> the ranges above that goes to open market against the requirement that 
> they become used within x time and if they are to be resold they have to 
> be resold/rented out at fair pricing. This could be 25,50 or whatever, i 
> don't have the insight yet on how often ranges are allocated to give an 
> accurate number and will not pretend as such either.
> 
> This would guarantee that the original spirit of the /24's for newcomers 
> idea is retained, while adopting to the wishes of the larger members as 
> well to a degree, I fully understand that there are some really really 
> big entities out there with big needs for IPv4 still and i don't want to 
> block them in any way shape or form because i one day hope to be able to 
> make use of our ranges and services to become on of the really big 
> players, with the benefit of being such a new player that i can already 
> today build IPv6 native and just use IPv4 for the still required things 
> and then hopefully phase out IPv4 and return our ranges down the road.
> 
> We today have as i mentioned earlier an single IPv4 /24 available for 
> our older WISP/MSP datacenter, It was acquired from an entity called 
> Resilans (If mentioning other entities by name is not allowed i 
> apologize) they also helped us with the process of becoming an LIR and 
> ripe member so we are VERY grateful to them as even tho they did charge 
> for their time, it was a fair price and we would not be here today 
> without them.
> 
> Entities like them are in my opinion fair and could benefit from the 
> third queue where they did price fairly against us and didnt try to 
> gouge us like other entities that have contacted us after we became 
> members (some asked for outrageous prices for a single /24)
> They also provide the ability for non members that cannot become members 
> for some reason to acquire IPs for their business, such as it was for us 
> back then. We didn't have any multi-homing ability which we now will 
> with Datacenter 2 (Which is our fiber ISP location) and our L2 link 
> between them. So we didn't even qualify until recently and we also 
> didn't feel we could justify for our then VERY small operations being an 
> LIR and the administration around that, there are others like us out 
> there and for them an resell/second hand renting market of IPv4 is very 
> beneficial
> 
> We all know IPv4 is a sinking ship and we implement stop gaps such as 
> NAT and then CGNAT to try and prolong its inevitable doom, but until 
> that day comes i hope that my understanding of RIPE so far is accurate 
> where you.. Us all try to make the playing field as equal as possible 
> without hindering each others opportunities.
> 
> Sorry for the mile long message but this is in my opinion one of several 
> potential ways to do this down the road that might help in some way.
> 
> I would also like to put out there the idea of presenting the number of 
> ranges in store on the LIR waiting list graph, it would serve two purposes.
> 
> It would allow small entities like us that when there is a 0 waiting 
> line to have an understanding of how soon there might be a queue again 
> so we can plan our potential entry as an LIR. I actually held off on us 
> being an LIR because we had so much else to prepare and get in place for 
> our new venture, if i would have seen the graph rapidly declining i 
> would have tried to become one sooner and perhaps been able to grab one 
> prior to the member days rather than come in 5 days after the waiting 
> list shot up.
> 
> The second benefit would also be to drive home the acute situation to 
> everyone and perhaps open up for more understanding for the smaller 
> entities out there that have to rely on this service to get IPv4 other 
> than turning to in some cases heavily overpriced addresses.
> 
> One last thing before i end this already too long rant.
> Thank you all so far for not only actually listening to a newcomers rant 
> about our opinion, but also truly showing to us that you really care 
> about our opinion and input. We cant wait to be able to bring back and 
> contribute to this community and hopefully prove our self worthy of the 
> time and consideration shown so far.
> 
> Very warm regards, Mathias W
> CEO and Infrastructure Architect - West digital Management AB.
> 
> On Fri, Dec 10, 2021 at 10:58 AM Sander Steffann <sander _at_ steffann _dot_ nl 
> sander _at_ steffann _dot_ nl>> wrote:
> 
>     Hi Mathias,
> 
>      > I will be quite frank about this and say that it feel very
>     disheartening to essentially miss the 0 day queue allocations by 5
>     days. end up in a one month long quque that just grows with no more
>     allocations and on top of that it is VERY obvious that these
>     organisations uses the members list as a "To be customers" base
>     because about 4 hours after we became members we got mails and
>     phonecalls from about 5 different companies stating they want to
>     sell us IP adresses.
>      >
>      > It just feels like this is not what RIPE was intended for but
>     obviously is being used for.
>      >
>      > I apologize if i am sounding too salty or if my mail is not
>     according to well established RIPE etiquette, and dont get me wrong.
>     we are VERY happy about being a new member with a single LIR and
>     getting our own IPv6 and insight into the future of the internet,
>     just felt that i should give the point of view of exactly one of
>     those "Small new one lir members" that many here reffer to and
>     exactly how our experience with this issue has been..
> 
>     Don't worry, you talk about your frustration quite politely :)  And
>     it is totally justified. This is why I think something needs to be
>     done now. Yes, it's rearranging deckchairs on the Titanic, but some
>     people are still trying to survive.
> 
>     As a new member, what do you think about these ideas? Would it be
>     good to make addresses untransferable? Or keep them transferable but
>     ask the NCC to impose a one-time merger&acquisition fee? Or any
>     other way? What would be ok for your real internet business but not
>     for address sellers?
> 
>     Cheers,
>     Sander
> 
> 
> 

denis walker

2021-12-13 16:31:26 CET

Hi Guys

I am doing some analysis on recent allocations using a variety of
public data. I have some questions some of you may be able to help me
with.

-What was the policy in 2019 regarding /22 allocations? Was it a free for all?

-When was the waiting list implemented?

-when was the allocation size dropped to /24?

-The companies/LIRs I have been looking at, I see lots of /22
allocations in 2019 and lots of /24 allocations in 2021, but nothing
allocated to them in 2020. What happened last year? Maybe it is a
coincidence that these random companies made no applications last
year. But given the extent to which they were grabbing address space
in 2019 and 2021, it seems odd they did nothing last year.

cheers
denis
co-chair DB-WG

On Mon, 13 Dec 2021 at 01:32, Nick Hilliard <nick _at_ foobar _dot_ org> wrote:
>
> Mathias Westerlund wrote on 12/12/2021 07:50:
> > I realize it is not an easy thing to solve.
> > I also both feel and understand that something needs to be done due to
> > the situation at hand.
>
> this situation can't be solved: it can only be managed.  There's a
> unresolvable high demand for number resources, and an unresolvable
> shortage of supply.
>
> The challenge is to work out what categories of problems we can live
> with, and then devise policies to implement that.  This is how the
> current policies came into existence.
>
> In regard to creating new policies or updating current ones:
>
> - the ultimate aim is accurate registration of resources
>
> - there is reluctance on the part of RIRs to deregister previously
> allocated number resources except in cases of contractual default
>
> - due to the high perceived value of ipv4 address resources, reclaiming
> addresses due to contractual default is likely to slow down in future
>
> - the greater the difference between supply and demand, the higher the
> price on the open market, and the more this will hurt organisations who
> need ip addresses, and the more demand there will be to change the rules
> to something else.
>
> - "new entrant" companies can be created simply and quickly (i.e.
> prioritising "new entrants" will create more avenues to abuse the
> registration system).
>
> - increasing the price of registration of addresses solves some problems
> but creates others
>
> - the RIR cannot make a value judgement about whose legitimate need for
> IP addresses is more important
>
> - some people will try hard to cheat the system, and some will succeed
>
> - whatever policy is implemented, it needs to be applied fairly and
> rigorously
>
> - the policies and implementations need to be compliant with local and
> regional laws / regulations
>
> The intersection of these constraints rules out many options for
> creating new policies.
>
> Nick
>
>
> > The problem is that many of the solutions i would think of may include
> > administration overhead, but i guess i will put forward two maybe three
> > ideas.
> >
> > The first and easiest but that will not satisfy everyone is the most
> > obvious one.
> > Only allow new members to procure from the waiting list and make the
> > addresses nontransferable.
> >
> > This would in my opinion be a stop gap for a bigger solution because we
> > cannot go ahead and block legitimate business needs for larger entities
> > just because of newcomers like myself.
> > However that ties into my second more realistic approach of what might
> > be accepted but also requires some changes on the administration.
> >
> > How about simply having a split queue system?
> > New members with single LIR goes to the front of the line and gets an
> > nontransferable address.
> > Others will according to their number of existing LIRs or ranges go to
> > the back of the line according to their current ownership where an
> > legitimate need for more ranges constitutes an expected revenue across
> > said ranges and as such the bigger expectancy of acquiring larger ranges
> > via an market otherwise said ranges are not being utilized properly (i
> > understand the existence of non profits and edge cases but not everyone
> > can be 100% satisfied, neither can i with this in the future)
> > Make an buffer that is not possible to be allocated to multi LIRs/multi
> > range holders.
> > I am not an old member enough to have good insight to where a good
> > buffer would be but for arguments sake i would say 100.
> >
> > This means that there is supposed to be 100 /24 ranges available (Could
> > be 20 or 30 or anything RIPE agrees on) and as long as there is, the
> > "Multi holder Queue" would be able to request ranges against
> > motivational uses.
> >
> > There could even be a third queue at say 250 ranges available where all
> > the ranges above that goes to open market against the requirement that
> > they become used within x time and if they are to be resold they have to
> > be resold/rented out at fair pricing. This could be 25,50 or whatever, i
> > don't have the insight yet on how often ranges are allocated to give an
> > accurate number and will not pretend as such either.
> >
> > This would guarantee that the original spirit of the /24's for newcomers
> > idea is retained, while adopting to the wishes of the larger members as
> > well to a degree, I fully understand that there are some really really
> > big entities out there with big needs for IPv4 still and i don't want to
> > block them in any way shape or form because i one day hope to be able to
> > make use of our ranges and services to become on of the really big
> > players, with the benefit of being such a new player that i can already
> > today build IPv6 native and just use IPv4 for the still required things
> > and then hopefully phase out IPv4 and return our ranges down the road.
> >
> > We today have as i mentioned earlier an single IPv4 /24 available for
> > our older WISP/MSP datacenter, It was acquired from an entity called
> > Resilans (If mentioning other entities by name is not allowed i
> > apologize) they also helped us with the process of becoming an LIR and
> > ripe member so we are VERY grateful to them as even tho they did charge
> > for their time, it was a fair price and we would not be here today
> > without them.
> >
> > Entities like them are in my opinion fair and could benefit from the
> > third queue where they did price fairly against us and didnt try to
> > gouge us like other entities that have contacted us after we became
> > members (some asked for outrageous prices for a single /24)
> > They also provide the ability for non members that cannot become members
> > for some reason to acquire IPs for their business, such as it was for us
> > back then. We didn't have any multi-homing ability which we now will
> > with Datacenter 2 (Which is our fiber ISP location) and our L2 link
> > between them. So we didn't even qualify until recently and we also
> > didn't feel we could justify for our then VERY small operations being an
> > LIR and the administration around that, there are others like us out
> > there and for them an resell/second hand renting market of IPv4 is very
> > beneficial
> >
> > We all know IPv4 is a sinking ship and we implement stop gaps such as
> > NAT and then CGNAT to try and prolong its inevitable doom, but until
> > that day comes i hope that my understanding of RIPE so far is accurate
> > where you.. Us all try to make the playing field as equal as possible
> > without hindering each others opportunities.
> >
> > Sorry for the mile long message but this is in my opinion one of several
> > potential ways to do this down the road that might help in some way.
> >
> > I would also like to put out there the idea of presenting the number of
> > ranges in store on the LIR waiting list graph, it would serve two purposes.
> >
> > It would allow small entities like us that when there is a 0 waiting
> > line to have an understanding of how soon there might be a queue again
> > so we can plan our potential entry as an LIR. I actually held off on us
> > being an LIR because we had so much else to prepare and get in place for
> > our new venture, if i would have seen the graph rapidly declining i
> > would have tried to become one sooner and perhaps been able to grab one
> > prior to the member days rather than come in 5 days after the waiting
> > list shot up.
> >
> > The second benefit would also be to drive home the acute situation to
> > everyone and perhaps open up for more understanding for the smaller
> > entities out there that have to rely on this service to get IPv4 other
> > than turning to in some cases heavily overpriced addresses.
> >
> > One last thing before i end this already too long rant.
> > Thank you all so far for not only actually listening to a newcomers rant
> > about our opinion, but also truly showing to us that you really care
> > about our opinion and input. We cant wait to be able to bring back and
> > contribute to this community and hopefully prove our self worthy of the
> > time and consideration shown so far.
> >
> > Very warm regards, Mathias W
> > CEO and Infrastructure Architect - West digital Management AB.
> >
> > On Fri, Dec 10, 2021 at 10:58 AM Sander Steffann <sander _at_ steffann _dot_ nl
> > sander _at_ steffann _dot_ nl>> wrote:
> >
> >     Hi Mathias,
> >
> >      > I will be quite frank about this and say that it feel very
> >     disheartening to essentially miss the 0 day queue allocations by 5
> >     days. end up in a one month long quque that just grows with no more
> >     allocations and on top of that it is VERY obvious that these
> >     organisations uses the members list as a "To be customers" base
> >     because about 4 hours after we became members we got mails and
> >     phonecalls from about 5 different companies stating they want to
> >     sell us IP adresses.
> >      >
> >      > It just feels like this is not what RIPE was intended for but
> >     obviously is being used for.
> >      >
> >      > I apologize if i am sounding too salty or if my mail is not
> >     according to well established RIPE etiquette, and dont get me wrong.
> >     we are VERY happy about being a new member with a single LIR and
> >     getting our own IPv6 and insight into the future of the internet,
> >     just felt that i should give the point of view of exactly one of
> >     those "Small new one lir members" that many here reffer to and
> >     exactly how our experience with this issue has been..
> >
> >     Don't worry, you talk about your frustration quite politely :)  And
> >     it is totally justified. This is why I think something needs to be
> >     done now. Yes, it's rearranging deckchairs on the Titanic, but some
> >     people are still trying to survive.
> >
> >     As a new member, what do you think about these ideas? Would it be
> >     good to make addresses untransferable? Or keep them transferable but
> >     ask the NCC to impose a one-time merger&acquisition fee? Or any
> >     other way? What would be ok for your real internet business but not
> >     for address sellers?
> >
> >     Cheers,
> >     Sander
> >
> >
> >
>
> --
>
> 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

Mentor Leniqi

2021-12-13 17:17:02 CET

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 [image: Logo] 

Albanian Hosting SH.P.K.
Besim Beka p.n.
50000 Gjakovë, Kosovë.
NIPT/VAT ID: 811442657
T: +386900501502
E: info _at_ albahost _dot_ net

W*: *wWw.AlbaHost.Net  [image: Facebook icon]
   [image: Twitter icon]
   [image: Instagram icon]


[image: 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.
User Image

Michael Bromwich

2021-12-13 17:39:54 CET

Hi,

 

We’re a start-up – and need a small allocation of IPv4 to connect our platform and to start generating revenue for our business. For us, even the RIPE joining and annual fees are a sizeable cost – and then having to pay around €10K for a /24 is a real problem. Unfortunately, we need to connect to the GRX network – so IPv6 is not an option, and nor is using a suballocation from a third party. We’re on the waiting list – but seemingly not going anywhere fast.

 

I realize that it’s inevitable that a hot market will emerge for such a precious resource – but it is disappointing that those new businesses who genuinely need a small allocation for their originally intended use (connectivity) are hindered by those who just speculate with no intention of actually using the addresses.

 

I am new to the scene and so unfortunately don’t have any useful suggestions to make – but it seems that something has to change since the current dynamic seems abusive.

 

Regards,

 

Mike Bromwich

mike.bromwich _at_ stacuity _dot_ com

User Image

Mathias Westerlund

2021-12-13 18:37:52 CET

Heya, Good (well, not really) to see that we are not the only ones with
this experience, As i have stated above we are very small as well and are
in need of the allocations for our business, for us too the annual fees and
administration regarding them were an absolutely deciding factor in why we
held off for so long.

However, that doesn't mean I am against the fee. quite the opposite due to
what it is used for.
Welcome to the gang I guess?

However, I was informed that we should be seeing allocations hit us no
later than the end of January as things look right now. I
can't guarantee that is the case for you. But hopefully it is.

Regards,
Mathias W.

On Mon, Dec 13, 2021 at 5:40 PM Mike Bromwich <mike.bromwich _at_ stacuity _dot_ com>
wrote:

> Hi,
>
>
>
> We’re a start-up – and need a small allocation of IPv4 to connect our
> platform and to start generating revenue for our business. For us, even the
> RIPE joining and annual fees are a sizeable cost – and then having to pay
> around €10K for a /24 is a real problem. Unfortunately, we need to connect
> to the GRX network – so IPv6 is not an option, and nor is using a
> suballocation from a third party. We’re on the waiting list – but seemingly
> not going anywhere fast.
>
>
>
> I realize that it’s inevitable that a hot market will emerge for such a
> precious resource – but it is disappointing that those new businesses who
> genuinely need a small allocation for their originally intended use
> (connectivity) are hindered by those who just speculate with no intention
> of actually using the addresses.
>
>
>
> I am new to the scene and so unfortunately don’t have any useful
> suggestions to make – but it seems that something has to change since the
> current dynamic seems abusive.
>
>
>
> Regards,
>
>
>
> Mike Bromwich
>
> mike.bromwich _at_ stacuity _dot_ com
> --
>
> 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-14 14:20:04 CET

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 _dot_ 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 [image: Logo] 
>
> Albanian Hosting SH.P.K.
> Besim Beka p.n.
> 50000 Gjakovë, Kosovë.
> NIPT/VAT ID: 811442657
> T: +386900501502
> E: info _at_ albahost _dot_ net
>
> W*: *wWw.AlbaHost.Net  [image: Facebook icon]
>    [image: Twitter icon]
>    [image: Instagram icon]
> 
>
> [image: 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://lists.ripe.net/mailman/listinfo/address-policy-wg
>

Florian Fuessl

2021-12-14 14:34:10 CET

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
> 


User Image

Mentor Leniqi

2021-12-14 15:03:05 CET

Very interesting! Good catch. And thank you for the information provided, i
personally believe that there is no help as because nobody cares at least
not the RIPE NCC itself. I do believe that we all are wasting our time
here, as long as my small company need a /22 allocation and cannot get it,
it's worthless. We are renting them from others in order to survive!

On Tue, Dec 14, 2021 at 2:20 PM denis walker <ripedenis _at_ gmail _dot_ com> 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 _dot_ 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 [image: Logo] 
>>
>> Albanian Hosting SH.P.K.
>> Besim Beka p.n.
>> 50000 Gjakovë, Kosovë.
>> NIPT/VAT ID: 811442657
>> T: +386900501502
>> E: info _at_ albahost _dot_ net
>>
>> W*: *wWw.AlbaHost.Net  [image: Facebook icon]
>>    [image: Twitter icon]
>>    [image: Instagram icon]
>> 
>>
>> [image: 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://lists.ripe.net/mailman/listinfo/address-policy-wg
>>
>

-- 
*Sinqerisht / Sincerely,*
AlbHost [image: Logo] 

Albanian Hosting SH.P.K.
Besim Beka p.n.
50000 Gjakovë, Kosovë.
NIPT/VAT ID: 811442657
T: +386900501502
E: info _at_ albahost _dot_ net

W*: *wWw.AlbaHost.Net  [image: Facebook icon]
   [image: Twitter icon]
   [image: Instagram icon]


[image: 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.
User Image

Angela Dall'Ara

2021-12-14 17:47:36 CET

RIPE NCC staff member

Hi Denis,

I hope the following answers your questions:

Q. What was the policy in 2019 regarding /22 allocations? Was it a free 
for all?

A. From 14 September 2012 to 18 September 2019, the first IPv4 
allocation size was limited to a maximum of a single /22 or the 
equivalent for each LIR, as per ripe-509 which was implemented in 
January 2011:
https://www.ripe.net/publications/docs/ripe-509#----use-of-last----for-pa-allocations

Through this policy, only LIRs without an IPv4 allocation from the RIPE 
NCC could request a /22 and they had to provide their intention of 
making assignments from the allocation.
As a side note, the requirement to hold an IPv6 allocation before 
requesting a /22 IPv4 allocation was removed in March 2015, as per ripe-632:
https://www.ripe.net/publications/docs/ripe-632#51


Q. When was the waiting list implemented?
Q. When was the allocation size dropped to /24?

A. The waiting list was introduced and the IPv4 allocation size reduced 
from a /22 to /24 on 19 September 2019, as per ripe-725:
https://www.ripe.net/publications/docs/ripe-725#51bis

Ripe-725 was activated the moment the RIPE NCC could no longer allocate 
a /22 IPv4 allocation (single range or equivalent) from its IPv4 free pool.
Through this policy, the requirement to make assignments from an 
allocation was removed and only LIRs without an IPv4 allocation could 
request a /24 IPv4 allocation via the waiting list.

Kind regards,
Angela

-- 
Angela Dall'Ara
RIPE NCC Policy Officer



On 13/12/2021 16:31, denis walker wrote:
> Hi Guys
>
> I am doing some analysis on recent allocations using a variety of
> public data. I have some questions some of you may be able to help me
> with.
>
> -What was the policy in 2019 regarding /22 allocations? Was it a free for all?
>
> -When was the waiting list implemented?
>
> -when was the allocation size dropped to /24?
>
> -The companies/LIRs I have been looking at, I see lots of /22
> allocations in 2019 and lots of /24 allocations in 2021, but nothing
> allocated to them in 2020. What happened last year? Maybe it is a
> coincidence that these random companies made no applications last
> year. But given the extent to which they were grabbing address space
> in 2019 and 2021, it seems odd they did nothing last year.
>
> cheers
> denis
> co-chair DB-WG
>
> On Mon, 13 Dec 2021 at 01:32, Nick Hilliard <nick _at_ foobar _dot_ org> wrote:
>> Mathias Westerlund wrote on 12/12/2021 07:50:
>>> I realize it is not an easy thing to solve.
>>> I also both feel and understand that something needs to be done due to
>>> the situation at hand.
>> this situation can't be solved: it can only be managed.  There's a
>> unresolvable high demand for number resources, and an unresolvable
>> shortage of supply.
>>
>> The challenge is to work out what categories of problems we can live
>> with, and then devise policies to implement that.  This is how the
>> current policies came into existence.
>>
>> In regard to creating new policies or updating current ones:
>>
>> - the ultimate aim is accurate registration of resources
>>
>> - there is reluctance on the part of RIRs to deregister previously
>> allocated number resources except in cases of contractual default
>>
>> - due to the high perceived value of ipv4 address resources, reclaiming
>> addresses due to contractual default is likely to slow down in future
>>
>> - the greater the difference between supply and demand, the higher the
>> price on the open market, and the more this will hurt organisations who
>> need ip addresses, and the more demand there will be to change the rules
>> to something else.
>>
>> - "new entrant" companies can be created simply and quickly (i.e.
>> prioritising "new entrants" will create more avenues to abuse the
>> registration system).
>>
>> - increasing the price of registration of addresses solves some problems
>> but creates others
>>
>> - the RIR cannot make a value judgement about whose legitimate need for
>> IP addresses is more important
>>
>> - some people will try hard to cheat the system, and some will succeed
>>
>> - whatever policy is implemented, it needs to be applied fairly and
>> rigorously
>>
>> - the policies and implementations need to be compliant with local and
>> regional laws / regulations
>>
>> The intersection of these constraints rules out many options for
>> creating new policies.
>>
>> Nick
>>
>>
>>> The problem is that many of the solutions i would think of may include
>>> administration overhead, but i guess i will put forward two maybe three
>>> ideas.
>>>
>>> The first and easiest but that will not satisfy everyone is the most
>>> obvious one.
>>> Only allow new members to procure from the waiting list and make the
>>> addresses nontransferable.
>>>
>>> This would in my opinion be a stop gap for a bigger solution because we
>>> cannot go ahead and block legitimate business needs for larger entities
>>> just because of newcomers like myself.
>>> However that ties into my second more realistic approach of what might
>>> be accepted but also requires some changes on the administration.
>>>
>>> How about simply having a split queue system?
>>> New members with single LIR goes to the front of the line and gets an
>>> nontransferable address.
>>> Others will according to their number of existing LIRs or ranges go to
>>> the back of the line according to their current ownership where an
>>> legitimate need for more ranges constitutes an expected revenue across
>>> said ranges and as such the bigger expectancy of acquiring larger ranges
>>> via an market otherwise said ranges are not being utilized properly (i
>>> understand the existence of non profits and edge cases but not everyone
>>> can be 100% satisfied, neither can i with this in the future)
>>> Make an buffer that is not possible to be allocated to multi LIRs/multi
>>> range holders.
>>> I am not an old member enough to have good insight to where a good
>>> buffer would be but for arguments sake i would say 100.
>>>
>>> This means that there is supposed to be 100 /24 ranges available (Could
>>> be 20 or 30 or anything RIPE agrees on) and as long as there is, the
>>> "Multi holder Queue" would be able to request ranges against
>>> motivational uses.
>>>
>>> There could even be a third queue at say 250 ranges available where all
>>> the ranges above that goes to open market against the requirement that
>>> they become used within x time and if they are to be resold they have to
>>> be resold/rented out at fair pricing. This could be 25,50 or whatever, i
>>> don't have the insight yet on how often ranges are allocated to give an
>>> accurate number and will not pretend as such either.
>>>
>>> This would guarantee that the original spirit of the /24's for newcomers
>>> idea is retained, while adopting to the wishes of the larger members as
>>> well to a degree, I fully understand that there are some really really
>>> big entities out there with big needs for IPv4 still and i don't want to
>>> block them in any way shape or form because i one day hope to be able to
>>> make use of our ranges and services to become on of the really big
>>> players, with the benefit of being such a new player that i can already
>>> today build IPv6 native and just use IPv4 for the still required things
>>> and then hopefully phase out IPv4 and return our ranges down the road.
>>>
>>> We today have as i mentioned earlier an single IPv4 /24 available for
>>> our older WISP/MSP datacenter, It was acquired from an entity called
>>> Resilans (If mentioning other entities by name is not allowed i
>>> apologize) they also helped us with the process of becoming an LIR and
>>> ripe member so we are VERY grateful to them as even tho they did charge
>>> for their time, it was a fair price and we would not be here today
>>> without them.
>>>
>>> Entities like them are in my opinion fair and could benefit from the
>>> third queue where they did price fairly against us and didnt try to
>>> gouge us like other entities that have contacted us after we became
>>> members (some asked for outrageous prices for a single /24)
>>> They also provide the ability for non members that cannot become members
>>> for some reason to acquire IPs for their business, such as it was for us
>>> back then. We didn't have any multi-homing ability which we now will
>>> with Datacenter 2 (Which is our fiber ISP location) and our L2 link
>>> between them. So we didn't even qualify until recently and we also
>>> didn't feel we could justify for our then VERY small operations being an
>>> LIR and the administration around that, there are others like us out
>>> there and for them an resell/second hand renting market of IPv4 is very
>>> beneficial
>>>
>>> We all know IPv4 is a sinking ship and we implement stop gaps such as
>>> NAT and then CGNAT to try and prolong its inevitable doom, but until
>>> that day comes i hope that my understanding of RIPE so far is accurate
>>> where you.. Us all try to make the playing field as equal as possible
>>> without hindering each others opportunities.
>>>
>>> Sorry for the mile long message but this is in my opinion one of several
>>> potential ways to do this down the road that might help in some way.
>>>
>>> I would also like to put out there the idea of presenting the number of
>>> ranges in store on the LIR waiting list graph, it would serve two purposes.
>>>
>>> It would allow small entities like us that when there is a 0 waiting
>>> line to have an understanding of how soon there might be a queue again
>>> so we can plan our potential entry as an LIR. I actually held off on us
>>> being an LIR because we had so much else to prepare and get in place for
>>> our new venture, if i would have seen the graph rapidly declining i
>>> would have tried to become one sooner and perhaps been able to grab one
>>> prior to the member days rather than come in 5 days after the waiting
>>> list shot up.
>>>
>>> The second benefit would also be to drive home the acute situation to
>>> everyone and perhaps open up for more understanding for the smaller
>>> entities out there that have to rely on this service to get IPv4 other
>>> than turning to in some cases heavily overpriced addresses.
>>>
>>> One last thing before i end this already too long rant.
>>> Thank you all so far for not only actually listening to a newcomers rant
>>> about our opinion, but also truly showing to us that you really care
>>> about our opinion and input. We cant wait to be able to bring back and
>>> contribute to this community and hopefully prove our self worthy of the
>>> time and consideration shown so far.
>>>
>>> Very warm regards, Mathias W
>>> CEO and Infrastructure Architect - West digital Management AB.
>>>
>>> On Fri, Dec 10, 2021 at 10:58 AM Sander Steffann <sander _at_ steffann _dot_ nl
>>> sander _at_ steffann _dot_ nl>> wrote:
>>>
>>>      Hi Mathias,
>>>
>>>       > I will be quite frank about this and say that it feel very
>>>      disheartening to essentially miss the 0 day queue allocations by 5
>>>      days. end up in a one month long quque that just grows with no more
>>>      allocations and on top of that it is VERY obvious that these
>>>      organisations uses the members list as a "To be customers" base
>>>      because about 4 hours after we became members we got mails and
>>>      phonecalls from about 5 different companies stating they want to
>>>      sell us IP adresses.
>>>       >
>>>       > It just feels like this is not what RIPE was intended for but
>>>      obviously is being used for.
>>>       >
>>>       > I apologize if i am sounding too salty or if my mail is not
>>>      according to well established RIPE etiquette, and dont get me wrong.
>>>      we are VERY happy about being a new member with a single LIR and
>>>      getting our own IPv6 and insight into the future of the internet,
>>>      just felt that i should give the point of view of exactly one of
>>>      those "Small new one lir members" that many here reffer to and
>>>      exactly how our experience with this issue has been..
>>>
>>>      Don't worry, you talk about your frustration quite politely :)  And
>>>      it is totally justified. This is why I think something needs to be
>>>      done now. Yes, it's rearranging deckchairs on the Titanic, but some
>>>      people are still trying to survive.
>>>
>>>      As a new member, what do you think about these ideas? Would it be
>>>      good to make addresses untransferable? Or keep them transferable but
>>>      ask the NCC to impose a one-time merger&acquisition fee? Or any
>>>      other way? What would be ok for your real internet business but not
>>>      for address sellers?
>>>
>>>      Cheers,
>>>      Sander
>>>
>>>
>>>
>> --
>>
>> 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

Angela Dall'Ara

2021-12-15 13:22:21 CET

RIPE NCC staff member

Dear colleagues,

When reading my answer from yesterday I see I could have been more 
precise, please see my clarification inline below.

On 14/12/2021 17:47, Angela Dall'Ara wrote:
> Hi Denis,
>
> I hope the following answers your questions:
>
> Q. What was the policy in 2019 regarding /22 allocations? Was it a 
> free for all?
>
> A. From 14 September 2012 to 18 September 2019, the first IPv4 
> allocation size was limited to a maximum of a single /22 or the 
> equivalent for each LIR, as per ripe-509 which was implemented in 
> January 2011:
> https://www.ripe.net/publications/docs/ripe-509#----use-of-last----for-pa-allocations 
>
>
> Through this policy, only LIRs without an IPv4 allocation from the 
> RIPE NCC could request a /22 and they had to provide their intention 
> of making assignments from the allocation.

Clarification: Through this policy, only LIRs that did not receive an 
IPv4 allocation from the RIPE NCC after 14/09/2012 could request a /22 
and they had to provide their intention of making assignments from the 
allocation.

> As a side note, the requirement to hold an IPv6 allocation before 
> requesting a /22 IPv4 allocation was removed in March 2015, as per 
> ripe-632:
> https://www.ripe.net/publications/docs/ripe-632#51
>
>
> Q. When was the waiting list implemented?
> Q. When was the allocation size dropped to /24?
>
> A. The waiting list was introduced and the IPv4 allocation size 
> reduced from a /22 to /24 on 19 September 2019, as per ripe-725:
> https://www.ripe.net/publications/docs/ripe-725#51bis
>
> Ripe-725 was activated the moment the RIPE NCC could no longer 
> allocate a /22 IPv4 allocation (single range or equivalent) from its 
> IPv4 free pool.
> Through this policy, the requirement to make assignments from an 
> allocation was removed and only LIRs without an IPv4 allocation could 
> request a /24 IPv4 allocation via the waiting list.

Clarification: Through this policy, the LIR's confirmation of the 
intention to make assignments from an allocation was removed and only 
LIRs without an IPv4 allocation could request a /24 IPv4 allocation via 
the waiting list.

>
> Kind regards,
> Angela
>

-- 
Angela Dall'Ara
RIPE NCC Policy Officer


denis walker

2021-12-15 20:00:23 CET

Hi Angela

I have a question about policy ripe-725.

On Wed, 15 Dec 2021 at 13:22, Angela Dall'Ara <adallara _at_ ripe _dot_ net> wrote:
>
> > Q. When was the waiting list implemented?
> > Q. When was the allocation size dropped to /24?
> >
> > A. The waiting list was introduced and the IPv4 allocation size
> > reduced from a /22 to /24 on 19 September 2019, as per ripe-725:
> > https://www.ripe.net/publications/docs/ripe-725#51bis

Are you saying section 5.1bis of ripe-725 became active as section 5.1
on 19 Sept 2019? This textual change in the policy did not take place
in ripe-730, published on  20191010. But waited until ripe-733
published on 20191125.

cheers
denis

User Image

Marco Schmidt

2021-12-16 16:57:14 CET

RIPE NCC staff member

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 _dot_ 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 
>     Albanian Hosting SH.P.K.
>     Besim Beka p.n.
>     50000 Gjakovë, Kosovë.
>     NIPT/VAT ID: 811442657
>     T: +386900501502
>     E: info _at_ albahost _dot_ net
>     W*: *wWw.AlbaHost.Net  	Facebook icon
>      Twitter icon
>      Instagram icon
>     
>     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://lists.ripe.net/mailman/listinfo/address-policy-wg
>
>
User Image

Gert Doering

2021-12-16 19:46:18 CET

Hi,

On Tue, Dec 14, 2021 at 03:03:05PM +0100, Albanian Hosting SH.P.K. via address-policy-wg wrote:
> Very interesting! Good catch. And thank you for the information provided, i
> personally believe that there is no help as because nobody cares at least
> not the RIPE NCC itself. I do believe that we all are wasting our time
> here, as long as my small company need a /22 allocation and cannot get it,
> it's worthless. We are renting them from others in order to survive!

If you have read this thread, you might have noticed that people *do* care.

It's just not very clear what can be done, at this point in time, which
will have a positive effect.

There's lots of things that can be done that have negative effects
(like, etra bureaucracy, which increases costs, which then leads to
complaints about, well, bureaucracy) but have very little effect on
the problem statement: networks getting "more than one /24" for the
same entity.

The problem statement is not as clear cut as it might seem... if a parent 
company opens a new subsidiary in every european country, which has their 
own network, budget, CEO... shouldn't they be entitled to have a LIR 
account and a /24 for each subsidiary?


... and, of course, it's not like we haven't been telling people since
15+ years that IPv4 is going to run out, and they should use IPv6.

Gert Doering
        -- NetMaster
-- 
have you enabled IPv6 on something today...?

SpaceNet AG                      Vorstand: Sebastian v. Bomhard, Michael Emmer
Joseph-Dollinger-Bogen 14        Aufsichtsratsvors.: A. Grundner-Culemann
D-80807 Muenchen                 HRB: 136055 (AG Muenchen)
Tel: +49 (0)89/32356-444         USt-IdNr.: DE813185279
User Image

Denis Fondras

2021-12-16 20:26:46 CET

Le Thu, Dec 16, 2021 at 07:46:18PM +0100, Gert Doering a écrit :
> 
> ... and, of course, it's not like we haven't been telling people since
> 15+ years that IPv4 is going to run out, and they should use IPv6.
> 

I find this sentence unfair for all of us who deploy IPv6 but still need to support
IPv4 because of big players with millions of IPv4 lagging behind.

-- 
Denis Fondras / Liopen

User Image

Mentor Leniqi

2021-12-16 20:30:46 CET

Hello Gert,

appreciate your response, i do believe that you started to care when
something is dead now trying to bring to life! On most replies here are
only shooting on newcomers/lirs in which no new lir is getting more than a
/24, and nobody is talking for those lirs that have multiple resources
/16, /17, /20, /21, /22 etc, in which you can clearly see that there is no
usage of it by theirself but only leasing/renting them out to those who
cannot effort to be LIR and even if they effort it, cannot get more than a
/24 allocation. There must be a policy in which it will stop those
behaviours of LIRs, if you don't need that much of resource, then return it
simple as that, and prevent them from leasing out to people like us. I was
working as an IT in one of University in which it has a /16 allocation, and
only in use less than a /24, all remaining resource is leased out with
monthly fee of course. Of course, if you check every single University in
the world has min /15, /16 allocation what for? There are many countries
like ours in which IPv6 is nowhere implemented yet, and there are many
applications in which is not yet ready for IPv6. So therefore, i hope that
this would be considered.

Cheers.


On Thu, Dec 16, 2021 at 7:46 PM Gert Doering <gert _at_ space _dot_ net> wrote:

> Hi,
>
> On Tue, Dec 14, 2021 at 03:03:05PM +0100, Albanian Hosting SH.P.K. via
> address-policy-wg wrote:
> > Very interesting! Good catch. And thank you for the information
> provided, i
> > personally believe that there is no help as because nobody cares at least
> > not the RIPE NCC itself. I do believe that we all are wasting our time
> > here, as long as my small company need a /22 allocation and cannot get
> it,
> > it's worthless. We are renting them from others in order to survive!
>
> If you have read this thread, you might have noticed that people *do* care.
>
> It's just not very clear what can be done, at this point in time, which
> will have a positive effect.
>
> There's lots of things that can be done that have negative effects
> (like, etra bureaucracy, which increases costs, which then leads to
> complaints about, well, bureaucracy) but have very little effect on
> the problem statement: networks getting "more than one /24" for the
> same entity.
>
> The problem statement is not as clear cut as it might seem... if a parent
> company opens a new subsidiary in every european country, which has their
> own network, budget, CEO... shouldn't they be entitled to have a LIR
> account and a /24 for each subsidiary?
>
>
> ... and, of course, it's not like we haven't been telling people since
> 15+ years that IPv4 is going to run out, and they should use IPv6.
>
> Gert Doering
>         -- NetMaster
> --
> have you enabled IPv6 on something today...?
>
> SpaceNet AG                      Vorstand: Sebastian v. Bomhard, Michael
> Emmer
> Joseph-Dollinger-Bogen 14        Aufsichtsratsvors.: A. Grundner-Culemann
> D-80807 Muenchen                 HRB: 136055 (AG Muenchen)
> Tel: +49 (0)89/32356-444         USt-IdNr.: DE813185279
>


-- 
*Sinqerisht / Sincerely,*
AlbHost [image: Logo] 

Albanian Hosting SH.P.K.
Besim Beka p.n.
50000 Gjakovë, Kosovë.
NIPT/VAT ID: 811442657
T: +386900501502
E: info _at_ albahost _dot_ net

W*: *wWw.AlbaHost.Net  [image: Facebook icon]
   [image: Twitter icon]
   [image: Instagram icon]


[image: 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.




-- 
*Sinqerisht / Sincerely,*
AlbHost [image: Logo] 

Albanian Hosting SH.P.K.
Besim Beka p.n.
50000 Gjakovë, Kosovë.
NIPT/VAT ID: 811442657
T: +386900501502
E: info _at_ albahost _dot_ net

W*: *wWw.AlbaHost.Net  [image: Facebook icon]
   [image: Twitter icon]
   [image: Instagram icon]


[image: 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.
User Image

Gert Doering

2021-12-16 22:00:29 CET

Hi,

On Thu, Dec 16, 2021 at 08:26:46PM +0100, Denis Fondras - Liopen wrote:
> Le Thu, Dec 16, 2021 at 07:46:18PM +0100, Gert Doering a écrit :
> > 
> > ... and, of course, it's not like we haven't been telling people since
> > 15+ years that IPv4 is going to run out, and they should use IPv6.
> > 
> 
> I find this sentence unfair for all of us who deploy IPv6 but still need to support
> IPv4 because of big players with millions of IPv4 lagging behind.

Yes, sorry.  I did not want to come across as "this is all your own fault",
more like "we knew this mess was coming, but failed to handle it in time,
as an Industry".

But whatever it is, even if some people try hard, we can't create the
necessary amount of extra IPv4 space.

Gert Doering
        -- NetMaster
-- 
have you enabled IPv6 on something today...?

SpaceNet AG                      Vorstand: Sebastian v. Bomhard, Michael Emmer
Joseph-Dollinger-Bogen 14        Aufsichtsratsvors.: A. Grundner-Culemann
D-80807 Muenchen                 HRB: 136055 (AG Muenchen)
Tel: +49 (0)89/32356-444         USt-IdNr.: DE813185279

denis walker

2021-12-17 07:05:20 CET

Hi Marco & APWG colleagues

Thanks for the response Marco. Some of my questions below suggest there may
be problems with the Transfer Stats and IPv4 Allocation Policy. These
questions are not really for the RIPE NCC to answer, except where there are
legal implications, but for this WG to consider...

On Thu, 16 Dec 2021 at 16:57, Marco Schmidt <mschmidt _at_ ripe _dot_ net> wrote:

> 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.
>

It was only for background information and isn't likely to change the
discussion very much. So if you are very busy don't worry about those
numbers. My own analysis is likely to be far more explosive. I am still
working on the details...


> 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.
>

So in a merger/acquisition two legal entities, each with one LIR account,
becomes one legal entity with two LIR accounts. A consolidation is when one
legal entity has two LIR accounts and closes one of those LIR accounts,
transfering it's resources to the remaining LIR account. Is that correct?
When a legal entity opens two LIR accounts does the legal entity become two
legally distinct RIPE NCC members?

With a consolidation, is the 'movement' of a resource from the closed LIR
to another LIR operated by the same legal entity considered as a transfer?
According to section 2.0 of the Transfer Policy the movement of an
allocated resource from one RIPE NCC member to another RIPE NCC member is a
transfer. So it looks to me that a consolidation IS a transfer and
therefore SHOULD be documented in the Transfer Stats? But I don't see any
transfers listed as CONSOLIDATION. Why not?

In the IPv4 Allocation Policy (ripe-733), section '3.0 Goals of the
Internet Registry System', point 3 says:
"Fairness: Public IPv4 address space must be fairly distributed to the End
Users operating networks."
Given the controversy over companies setting up multiple LIRs to (un)fairly
acquire the last bits of IPv4 addresses available through the RIPE NCC
being discussed in this thread, in the interests of fairness, as well as
openness and transparency, should consolidation 'transfers' be included in
the Transfer Stats?

With the current /24 allocation policy there is a condition that these
allocations cannot be transferred for at least 24 months. Are there any
conditions/expectations on who can use this address space or who can
administratively and technically control these addresses? Is it acceptable
that within these 24 months, a separate legal entity takes over both
administrative and technical control of this allocated address space and
manages the assignment of it? So the legal entity that received the
allocation is just a 'shell' that exists only to satisfy the 24 month no
transfer condition.

Now I want to ask a very specific legal question. In the Transfer Policy,
section '2.1 Transfer Requirements' says:
"The original resource holder remains responsible for an Internet number
resource until the transfer to the receiving party is completed."
So in the example I gave earlier, Company ABC acquired company XYZ (and
presumably all it's assets including the LIR it operated) on 2 December.
According to the Chamber of Commerce, company XYZ was deregistered on 5
December. So it no longer existed as a legal entity after 5 December. The
Transfer Stats state the transfer of the resources from XYZ to ABC occured
on 23 December. According to the Transfer Policy section '4.0 Transfer
Statistics' says the published date is "The date each resource was
transferred". So who was legally responsible for those IP resources between
5 and 23 December?

cheers
denis
co-chair DB-WG
User Image

AJ Wolski

2021-12-18 18:10:23 CET

On Tue, Dec 7, 2021 at 3:56 PM Gert Doering <gert _at_ space _dot_ net> wrote:
>
> Hi,
>
> On Tue, Dec 07, 2021 at 02:29:15PM +0000, Erik Bais wrote:
> > As WG chairs we would like to see the position of the WG on the topic and what could be seen as a possible solution.
>
> As a member of the WG, I do share the sentiment that the intent of the
> "IPv4 runout" policies have been "ensure that late comers to the game
> can have a bit of IPv4 space, to number their IPv6 translators", and
> not "grab some space for free, and sell it for more money elsewhere".
>
> I do not think this can be fixed on the AGM level ("one legal entity
> can only have one LIR account") - we've been there, in the rush to /22s,
> and all it does it "make people hide behind shell companies", so in
> the end, the address space goes out anyway, but registry quality suffers.
>
> Trying to make the NCC require even more paperwork isn't going to stop
> those that want to game the system, but will impact everyone else by
> making the NCC more annoying to deal with.
>
>
> My suggestion would be along the lines what was proposed on the APWG
> meeting already - earmark these /24s as non-transferrable, ever.

I would definitely support that, but...

> Consequences:
>
>  - there is no more financial incentive to "get one cheap, sell it expensive"
>
>  - if you need space to run your business, this is exactly what it is
>    there for - you can still sell your business (with the /24), you
>    just need to keep the LIR account.  But that's as with other
>    business assets.
>
>  - if you want to merge multiple LIR accounts, all having their own
>    /24 - then you need to keep around these accounts, or return some
>    of the /24s.
>     - corrolary: if you use these /24s to number your IPv6 translators,
>       then renumbering this translator into "your other /24" is actually
>       not very hard.
>     - corrolary2: If you use the /24s to directly number your customers,
>       you missed the boat already (wearing my RIPE unicorn t-shirt today).

If the goal of the WG is to stop some small number of LIRs abusing the
system, make it non-transferrable, but really never, return to the
pool. Any "if" will just change the game for those who abuse the
system. Hardline only works if we make an assumption that being an LIR
is more expensive than "renting" 256 v4 addresses on the market. I
don't know how long this will hold on.

As it was mentioned already at APWG, I think ARIN approach is more
elegant, 5 years is a reasonable number these days. This could be
revised to further extend the hold time if needed, rather than the
membership fee.
Yes, abuse will go on, but less interesting short term and at least
with the prospect of proper registration.

v6 stats are depressing, v4 is not going away, we are just inflating
the prices and further skewing the DB accuracy.

AJ Wolski

User Image

Angela Dall'Ara

2021-12-20 12:17:36 CET

RIPE NCC staff member

Hi Denis,

ripe-725 has been published on 30 July 2019, following up on the 
acceptance of policy proposal 2019-02, "IPv4 Waiting List Implementation”,
https://www.ripe.net/ripe/mail/archives/address-policy-wg/2019-July/012987.html
and it has been implemented on 19 September 2019.
https://www.ripe.net/ripe/mail/archives/address-policy-wg/2019-September/013024.html
This version stated
- in section "5.1 Allocations made by the RIPE NCC to LIRs":
"Once an equivalent of a /22 can no longer be allocated, the RIPE NCC 
will start allocating IPv4 resources based on a first-come-first-serve 
waiting list. At that point in time the contents of section 5.1 of this 
policy document will be automatically replaced with the contents of 
section 5.1bis and section 5.1bis will be deleted from this policy 
document."
- in section "5.2 Unforeseen circumstances":
"A /16 will be held in reserve for some future uses, as yet unforeseen. 
. . . In the event that this /16 remains unused at the time the 
remaining addresses covered by this policy have been distributed, it 
returns to the pool to be distributed as per section 5.1, and this 
section is to be automatically deleted from the policy document."


ripe-730 has been published on 10 October 2019, following up on the 
acceptance of policy proposal 2019-05, "Revised IPv4 assignment policy 
for IXPs".
https://www.ripe.net/ripe/mail/archives/address-policy-wg/2019-October/013068.html


ripe-733 has been published on 25 November 2019, following up on the 
automatic updates stated in ripe-725 (see above), as a result of the 
depletion of the RIPE NCC free IPv4 pool.
https://www.ripe.net/ripe/mail/archives/address-policy-wg/2019-November/013114.html


Kind regards,
Angela

-- 
Angela Dall'Ara
RIPE NCC Policy Officer



On 15/12/2021 20:00, denis walker wrote:
> Hi Angela
>
> I have a question about policy ripe-725.
>
> On Wed, 15 Dec 2021 at 13:22, Angela Dall'Ara <adallara _at_ ripe _dot_ net> wrote:
>>> Q. When was the waiting list implemented?
>>> Q. When was the allocation size dropped to /24?
>>>
>>> A. The waiting list was introduced and the IPv4 allocation size
>>> reduced from a /22 to /24 on 19 September 2019, as per ripe-725:
>>> https://www.ripe.net/publications/docs/ripe-725#51bis
> Are you saying section 5.1bis of ripe-725 became active as section 5.1
> on 19 Sept 2019? This textual change in the policy did not take place
> in ripe-730, published on  20191010. But waited until ripe-733
> published on 20191125.
>
> cheers
> denis