[members-discuss] GM topic

Hi,


RIPE-639 specifically mentions in its scope that rights to hold, use or transfer (and remember transfers do not need to be free) "are not addressed or restricted" by it. It also mentions that any existing or future policies do not apply to legacy holders unless it is explicitly included in the other policy.

RIPE-822 mentions that assignments are valid as long as the original criteria the assignment was based on is valid and the assignment is registered in the database. It also mentions something about fairness.

In practice, whether you want it or not, holder equals owner and holding equals ownership. One cannot sell or rent something that one do not own or have the rights to. Doing so would constitute some kind of fraud. People sell and buy and rent these daily.

As for the apples. 1. in three or 4 parts depending on whether you're willing to sacrifice yourself in favor of your progeny, 2. you should look into buying futures to lock in the price of apples as you are producing a lot daily (not financial advice), 3. you buy apples from someone else.



Kaj

________________________________
From: ivaylo <ivaylo at bglans.net>
Sent: Monday, April 29, 2024 15:18
To: members-discuss at ripe.net <members-discuss at ripe.net>
Cc: Kaj Niemi <kajtzu at basen.net>
Subject: Re: [members-discuss] GM topic


> I think it?s great we are being creative with the ideation of the models but?
>
> Fair is a very vague yet complicated concept. Here I agree with Nick ;)
>
> Distribution in the past has been needs based (based on existing or
> projected need). It's done.
>

I dont see how the word "fair" can be vague. When you dont have shortage
of the resource it purely means "depend on your needs" (current situation
with IPV6, ASN). But when you run on the limit it means equal (IPV4).

Let me ask you 3 questions:

1. If you have 3 own hungry childrens and just one apple how will you
distribute the apple to them ?
2. If you have 3 own hungry childrens and 1000 apples, but tomorow your
apple tree can give you another 1000 apples ?
3. If you have 3 own hungry childrens 1000 apples, but you old apple tree
is dead and that food is all you have for undefined period of time until
your new not seeded yet apple tree grow and start giving you apples ?

When you answer me of these 3 questions you will see and what _MUST_ mean
of the word -->fair<-- is for RIPE. And when you find the common point of
your answers you will know what RIPE NCC must do.

Kaj, you talk so much about lawsuits, but can you give a citate, or point
to RIPE policy or agreement, where it is said that allocated from RIPE
*INR to the LIRs are not subject of change, not subject of their quantity
change, and they are distributed for undefined period of time ?

If there are still people or companies which mistake the word "hold" with
the word "own" is entirely their problem. Nor RIR, LIR or end user can
"own" *INR. They just can hold and operate with given INR for defined
period of time (look at the RIPE documents and contracts, then tell me
where is used the word "own"). The funny part is that the only way
personal or company to be identified as authority of the given resource is
the register itself. If the register stop functioning no one will know
which *INR you can operate with. So if you screw (lawsuits) the register
you are screwing and your own interests.

*INR - Internet Number Resources. Any Internet identifiers such as IP
addresses (IPv4, IPv6) and Autonomous System Numbers.
(Citate from RIPE documents)

One _OBLIGATION_ of RIPE NCC is to care for *fair* distribution of the
resources across the LIRs in the region. And am not saying it is subject
of member's wish or vote how the INR have been / are / will be
distributed, I am saying it _MUST_ be fundamental rule that RIPE NCC must
apply to guarantee its future, and it must not depend on any contractor
or requestor wish.

----
About RIPE-639

The policy:
https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ripe.net%2Fpublications%2Fdocs%2Fripe-639%2F&data=05%7C02%7C%7C950ec21ba0cf47dde90508dc68468008%7Cd0b71c570f9b4acc923b81d0b26b55b3%7C0%7C0%7C638499899231222420%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C4000%7C%7C%7C&sdata=JCmn5DPzSrZT1ga3MLbcPv45%2FdsB2ceC%2FgOxoxn6ZXs%3D&reserved=0<https://www.ripe.net/publications/docs/ripe-639/>

Mr. Xavier Le Bris report from 12.01.2024
(Big thanks for his work and efforts):
https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flabs.ripe.net%2Fauthor%2Fxavier%2F10-years-of-legacy-policy%2F&data=05%7C02%7C%7C950ec21ba0cf47dde90508dc68468008%7Cd0b71c570f9b4acc923b81d0b26b55b3%7C0%7C0%7C638499899231232278%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C4000%7C%7C%7C&sdata=xDx%2BIJ%2BEs5p86oeimpX8CF5GinmTQEJDasxAeiR9Tq0%3D&reserved=0<https://labs.ripe.net/author/xavier/10-years-of-legacy-policy/>

I dont see anywhere the RIPE register is _obligated_ to keep legacy
resources records for undefined time. I only read the RIPE register is
_authoritive_ for these INR. With other words the data for legacy
resources are holded in the register by good will. And there is no any
obstacle to _NOT_ have deadline to keep doing this (in point 2.6). Also
from the report 9% of 12 x /8 IPV4 blocks (nearly full /8 IPV4 block)
is with undefined status. Another legacy holders which holds nearly 30%
of the INR are out of any contracts or touch. So where is the benefit to
keep holding such records ? Will the register be more acurate - NO ! Will
the memebers will benefit of unusing nearly /8 - NO ! Are these legacy
holders contribute something to the RIPE NCC - NO ! Correct me if I am
wrong please.

------
About the claim "Last year base of the members rejected category based
charging scheme, we will not offer it again". As I remember offered
model B for 2024 also was not supported (rejected) , why it is offer for
2025 again ? When we take a decision what to offer and what not is rely on
principle or on personal subjective opinion ?

For 2024:
https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ripe.net%2Fmedia%2Fdocuments%2FOption_B_-_Price_Increase_10_-_RIPE_NCC_Charging_Scheme_2024.pdf&data=05%7C02%7C%7C950ec21ba0cf47dde90508dc68468008%7Cd0b71c570f9b4acc923b81d0b26b55b3%7C0%7C0%7C638499899231238356%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C4000%7C%7C%7C&sdata=Kskagg4F0z2z7slQVPZlBdWEdrkgut527Ct7OlU3DiE%3D&reserved=0<https://www.ripe.net/media/documents/Option_B_-_Price_Increase_10_-_RIPE_NCC_Charging_Scheme_2024.pdf>

For 2025:
https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ripe.net%2Fmedia%2Fdocuments%2FOption_B_RIPE_NCC_Charging_Scheme_2025.pdf&data=05%7C02%7C%7C950ec21ba0cf47dde90508dc68468008%7Cd0b71c570f9b4acc923b81d0b26b55b3%7C0%7C0%7C638499899231242924%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C4000%7C%7C%7C&sdata=x%2FwA9u%2BK3yycy4RFlgViG%2BbKIHVaaRbG6WF9%2B6Uve2s%3D&reserved=0<https://www.ripe.net/media/documents/Option_B_RIPE_NCC_Charging_Scheme_2025.pdf>

To note that I and organisations I present are against category based
charging schemes which will put the main load over the small to medium
resource holders (LIRs), and will favoritize the biggest (what was offered
in the last year).



Ivaylo Josifov
VarnaIX / Varteh LTD
+359 52 969393
Varna, Bulgaria


On Fri, 26 Apr 2024, Kaj Niemi wrote:

> I think it?s great we are being creative with the ideation of the models but?
>
> Fair is a very vague yet complicated concept. Here I agree with Nick ;)
>
> Distribution in the past has been needs based (based on existing or
> projected need). It's done.
>
> Any real implementation of forcing a "fair re-redistribution" of RIR
> assigned resources, as you suggest, will lead in lawsuits. Whether it would
> be 1, 10 or 1000 doesn't matter. The association will not have the financial
> resources and time to handle those. Probably not the best use of LIR fees,
> either. I doubt anyone in legal would ever ACK this.
>
> Any of the companies holding address space that RIPE-639 refers to might not
> have an interest, or even be aware of the "benefits" of being a RIPE LIR
> themselves. Yes, they don't know about RPKI either, usually. Legacy reverse
> DNS might be enough. Many of these are multinationals in non-tech sectors
> who have gotten addresses before the RIR system existed. Some of these got
> addresses around the time classless routing came along from their vendors
> who themselves had gotten the addresses from IANA just by asking. Some of
> these do not route the addresses on the internet, some others do, etc. etc.
> Again, ruining someone's day by "reclaiming" - let's call it what it really
> is, hijacking - address space that hasn't been RIR assigned will certainly
> lead to costly lawsuits and claims of damages as above.
>
> Don't think a "Pigouvian tax" would work either as the alternative is always
> for the holder to sell or rent the addresses. I think it'll lead to more
> consolidation of addresses to the cloud providers. Probably again not what
> was intended originally. Any added cost would eventually be shifted to the
> customers one way or another. Apropos that, Cogent is raising a 200M note
> secured by a bunch of IPv4 addresses and rental cash flows. Addresses have a
> significant value as collateral just as stable cash flows do.
>
>
> :)
>
>
>
> Kaj
>
> Sent from my iPad
>
> ____________________________________________________________________________
> From: members-discuss <members-discuss-bounces at ripe.net> on behalf of ivaylo
> <ivaylo at bglans.net>
> Sent: Friday, April 26, 2024 9:26 PM
> To: Massimiliano Stucchi <max at stucchi.ch>
> Cc: members-discuss at ripe.net <members-discuss at ripe.net>
> Subject: Re: [members-discuss] GM topic
>
> Thank you for this example Massimiliano !
>
> It is very good example how bad the resources can be used, and how bad is
> to have flat fee for all members ! That's why RIPE fee _MUST_ include per
> resource component.
>
> I am currious about technical aspects in the logic, Even if you go
> with EUI-64 standart for your network infrastructure (nobody do this,
> because the addresses unprediction) a /29 IPV6 will let you have 34 358
> 689 800 ( > 34 Bilions segments). With the maximum ttl value of 255
> (limited by the one byte in the header, current around the internet is
> used just 64), You can have 134 739 960 (> 134 millions) router
> interfaces. With the modern switching asics, you will need and around
> 144 000 000 000 000 (> 144 trillions) ethernet switches where you can
> connect up to 18446744073709551616 end hosts per segment. Let me also
> remind that IPV6 protocol allow to use a single (just one) adress per a
> system/ruter/host (not per interface as IPV4) implemented in almost all
> vendors equipment and OS.
>
> Yes in theory it is posible to need huge address space, but in theory
> every one of us (LIRs) have to drawn all ipv6 + ipv4 + ASN from IANA (not
> from RIPE only) to cover all very unlikely future needs.
>
> -----
>
> The problems RIPE NCC and we members have, is not the charging scheme is
> fair or unfair, the root of the problem is _UNFAIR RESROURCES
> DISTRIBUTION_ during the years. As everything in the real world internet
> resources are also finite numbers. So how to spread finite resources to
> group of members which by presumptions are equal (First and most
> important RIPE obligation - threat all members equally) ? Logically -
> equal. If we were 5 members maybe we can handshake each other and have an
> agreement (not sure ether when we talk about concurent companies /
> personals), but we are 21k that's why we need clear, transparent and
> strong rules equal to all. We currently have a strong discrimination based
> on very vague foundations and rules.
>
> I will be very happy somebody from RIPE to explain us, why one member can
> hold /8 just for fun (or testing or whatever), in the same time other
> member to have single /24 (or to be in a waiting queues) extreamly
> dificult to operate its bussiness because lack of resources and both of
> them to be forced to pay same fee. Which rule in the RIPE founding
> agreement exactly says this is fair and equal ? Also how many from the
> RIPE NCC staff and you LIRs, with hand on heart will tell the current
> situation is moral, normal and fair to all ?
>
> In all cases after the posible delegated resources to RIPE have limits we
> also need limits for the resource each of us can hold and operate with.
> thing more fair can be than to take all resources in each category
> (IPV4/IPV6/ASN) which are delegated to RIPENCC and divide by the LIR
> members number.
>
>
> Solution one:
> Redistribute resources equaly to all. Not imposible as I already wrote,
> but will that lead to tremors in the work of operators - very likely. But
> what is that is equal fees, equal rights, equal resources.
>
> Solution two:
> Start to "penalise" the the LIRs which holds and operate resources over
> the fair share limits. That will not make disruption of the internet work
> in the region. And will give time to those who want to optimise the
> resource usage to do it and save expenses. How to do it ? - With money
> ofcourse. To prevent adding too much initial stress to all, we have to
> start with small steps and calibrate the "penalisation" fee with time.
>
> As I wrote in my previous mail the current fair shair resources for each
> LIR member based on what I checked (by IANA documents and 21500 LIRs) are:
>
> 1 x /18 IPV4 block
> 1 x /28 IPV6 block
> 16 x ASN
>
> Everything above these numbers should be "penalise" with a small fee per
> each resource over the limit. Ofcourse these limits must be shifted if
> we become 40k members or down to 10k, but it is an easy part. Also
> "penalty" fee by 10 euro per year for /24, /32, ASN looks prety resonable
> in the light of current free market prices - 15k "buy" / 100 euro month
> rent.
>
> It is not a category based charging scheme !
> It is fair share charging scheme !
> Can be looked at like extension of the scheme C, but guarantee much more
> RIPE NCC sustainable future and covers all LIR resources (not only PI).
> Current offered option C is inanity, because one LIR can hold /8 PA and
> none PI space, the other can hold single /24 PA and 10 x /24 PI, and will
> pay much more than the first one with /8 PA (fair ?) !
>
>
> Another important theme is RIPE-639. 10 Years after the adoption we still
> have nearly 34% undiscovered resources. How much more time it needs ? If
> for 10 years you cant find legacy holders what will be the chance to do
> it in the next 10 or 100 years ? We need a straight deadline to point
> 2.6. I think RIPE NCC can safely suspend (not delete) all records for
> these 34% resources. It is good to put dummy records to point to call or
> email to RIPE support staff, and these resource to be gobaly announce. If
> nobody call in few (3) mounths, can be consider free and can be drawn into
> the pool.
>
>
>
> Ivaylo Josifov
> VarnaIX / Varteh LTD
> +359 52 969393
> Varna, Bulgaria
>
>
> On Fri, 26 Apr 2024, Massimiliano Stucchi wrote:
>
> >
> > Hi,
> >
> > On 26.04.2024 16:40, Thibaud Perret wrote:
> >
> >> I have a question for Massimiliano, if he sees it:
> >> Do you really need that many IPv6 addresses? Couldn't you just go with a
> >> single
> >> /40 allocation instead? That would still make a couple of /48 to be
> >> announced
> >> separately for you to keep your "lab allocation". If the answer is "yes"
> to
> >> that
> >> question, you could then pay well less in most if not all other RIR
> >> regions.
> >
> > I could do with a much smaller allocation. At present, I'm announcing both
> > /29s, with the first one being where my infrastructure is (and an address
> I'm
> > writing this e-mail from), and the second /29 has been used for some
> research
> > such as the one you can find here
> >(https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flabs.rip%2F&data=05%7C02%7C%7C950ec21ba0cf47dde90508dc68468008%7Cd0b71c570f9b4acc923b81d0b26b55b3%7C0%7C0%7C638499899231246984%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C4000%7C%7C%7C&sdata=a7TJ86ya0vcvV6%2Bk0nI84V%2Fy6N5oqgnZNTo3rwDtj%2Fo%3D&reserved=0
> e.net%2Fauthor%2Fstucchimax%2Fa-bgp-side-effect-of-rpki%2F&data=05%7C02%7C
> %7C0b84b59374a24b82c60308dc661e588c%7Cd0b71c570f9b4acc923b81d0b26b55b3%7C0
> %7C0%7C638497527736209710%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQ
> IjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C4000%7C%7C%7C&sdata=y2T5QV8Ea
> 7AuXD4WBPSVxPxiuOcA80pYk7PGy8LHnyQ%3D&reserved=0).
> >
> > The point of the article was to compare what a "normal" LIR would pay in
> the
> > different RIRs. If I were to compare having a /48 (which would be PI at
> that
> > point) I would be comparing two different things.
> > Additionally, I wanted to showcase how some decision could be hindering
> > Internet development, such as the one from LACNIC to charge so much for
> IPv6
> > compared to all the other RIRs, and the similar situation at APNIC,
> although
> > to a lesser extent.
> >
> > To wrap this, could I do with a smaller allocation? Definitely. But I
> > received a /29 as part of my membership and I can make some use of it. I
> > could also live without a second /29, but that does not increase my
> > membership fees. I would return it if the charging scheme were to be like
> > APNIC or LACNIC.
> >
> > Ciao!
> >
> > --
> > Massimiliano Stucchi
> > MS16801-RIPE
> >https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fstucchi.c%2F&data=05%7C02%7C%7C950ec21ba0cf47dde90508dc68468008%7Cd0b71c570f9b4acc923b81d0b26b55b3%7C0%7C0%7C638499899231250933%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C4000%7C%7C%7C&sdata=aSKa3hJRvfdc5SJ6BvErwshNUvaidwEDgBDcEYyeI7k%3D&reserved=0<https://stucchi.c/>
> h%2F&data=05%7C02%7C%7C0b84b59374a24b82c60308dc661e588c%7Cd0b71c570f9b4acc
> 923b81d0b26b55b3%7C0%7C0%7C638497527736218822%7CUnknown%7CTWFpbGZsb3d8eyJW
> IjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C4000%7C%7
> C%7C&sdata=CCE0El%2F5B41Uiky2BkscGB%2Fb%2FnkIWS2tKh4KGwPNA%2F4%3D&reserved
> =0
> >
>
> _______________________________________________
> members-discuss mailing list
> members-discuss at ripe.net
> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.rip%2F&data=05%7C02%7C%7C950ec21ba0cf47dde90508dc68468008%7Cd0b71c570f9b4acc923b81d0b26b55b3%7C0%7C0%7C638499899231254695%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C4000%7C%7C%7C&sdata=RV8fxe0aEPnm%2BR2pG87fttskB%2BUgn1pOSVLmzsG3XPo%3D&reserved=0<https://lists.rip/>
> e.net%2Fmailman%2Flistinfo%2Fmembers-discuss&data=05%7C02%7C%7C0b84b59374a
> 24b82c60308dc661e588c%7Cd0b71c570f9b4acc923b81d0b26b55b3%7C0%7C0%7C6384975
> 27736224712%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLC
> JBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C4000%7C%7C%7C&sdata=AKpL%2FBU%2BGivvG9mSvj2
> oFyeYeLXVit3cGEBi0iHep9Y%3D&reserved=0
> Unsubscribe:https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.rip%2F&data=05%7C02%7C%7C950ec21ba0cf47dde90508dc68468008%7Cd0b71c570f9b4acc923b81d0b26b55b3%7C0%7C0%7C638499899231258309%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C4000%7C%7C%7C&sdata=j0oa3UCNy%2Br56X2FC1b07MwF1ZyhVtKXTajyFfXoV6Q%3D&reserved=0
> e.net%2Fmailman%2Foptions%2Fmembers-discuss%2Fkajtzu%2540basen.net&data=05
> %7C02%7C%7C0b84b59374a24b82c60308dc661e588c%7Cd0b71c570f9b4acc923b81d0b26b
> 55b3%7C0%7C0%7C638497527736228202%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAw
> MDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C4000%7C%7C%7C&sdata=w
> Gy%2BZKcmJxuRIwj9%2BTXb5a6zDlImgJ%2BgmCg51B4zlw8%3D&reserved=0
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://www.ripe.net/ripe/mail/archives/members-discuss/attachments/20240429/9a9da923/attachment-0001.html>