This archive is retained to ensure existing URLs remain functional. It will not contain any emails sent to this mailing list after July 1, 2024. For all messages, including those sent before and after this date, please visit the new location of the archive at https://mailman.ripe.net/archives/list/address-policy-wg@ripe.net/
[address-policy-wg] Transfer Requirements for IPv4 Allocations
- Previous message (by thread): [address-policy-wg] Transfer Requirements for IPv4 Allocations
- Next message (by thread): [address-policy-wg] Transfer Requirements for IPv4 Allocations
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Vladimir Andreev
vladimir at quick-soft.net
Thu Apr 23 18:26:38 CEST 2015
One correction: Not > Total count of allocated blocks can be calculated (approximately) as A * B where A and B are octets in allocation address 185.A.B.0/22. > Octet A can be named "series" and B / 4 is possible block count in each "series". > > B is always 64 and A (for now) is 97. Thus totally allocated T2 = 97 * 64 = 6208 blocks from last /8. But > Total count of allocated blocks can be calculated (approximately) as A * B / 4 where A and B are octets in allocation address 185.A.B.0/22. > Octet A can be named "series" and B / 4 is possible block count in each "series". > > B is always 128 and A (for now) is 97. Thus totally allocated T2 = 97 * 128 / 4 = 6208 blocks from last /8. Final digits are the same. 23.04.2015, 14:20, "Vladimir Andreev" <vladimir at quick-soft.net>: > Hi, All! > > I decided to express my opinion regarding this proposal. > > As appears from the proposal summary it pursues the following goals: > > 1. prevent opening LIR, receiving /22 and selling it > 2. prevent making a financial profit from st. 1 > 3. save IPv4 space from exhaustion > > Looking at listed items I can suppose either Elvis is angry at people earning money or really /22 reselling is bad for RIPE and its community. > At half part of my letter I prove that /22 reselling has negligible impact on community. > > As a way to achieve the goals the proposal offer to substitute st. 5.5 from ripe-623 for: > > "LIRs that receive an allocation from the RIPE NCC or a re-allocation from another LIR cannot re-allocate complete or partial blocks of the same address space to another LIR within 24 months of receiving the re-allocation." > > If pointed change to st. 5.5 is accepted we will face with the following: > > - Black market of /22 transfers will grow rapidly. Companies wishing to acquire IPv4 space can compose fake papers with sellers regarding merging/acquisition and send it to RIPE NCC (like IPv4 PI space as it was till recently). Also it should be noted that RIPE NCC can't forbid transfers which are under merging/acquisition since such transfers only reflect internal company(is) structure. > - Companies wishing to sell /22 can just wait for 24 months (if they have enough patience of course). > - The policy doesn't prevent opening multiple LIR's, merging LIR's together and then using received /22's for own company needs. > > In other words the policy doesn't introduce sufficient arrangements to achieve set goals. I.e. in current view the policy is inoperative. > > --------------------------------------------------------------------------------------------- > > Let's calculate what ratio of transferred /22's from last /8 (T1) to total count of allocated /22's (T2) is. > > At https://www.ripe.net/manage-ips-and-asns/resource-transfers-and-mergers/ipv4-transfers/table-of-transfers page type into filter "185.0". > After that go to web browser console and type: $('#transfers-table-allocations tr').length > > For 23 April 2015 we have T1 = 237. > > Total count of allocated blocks can be calculated (approximately) as A * B where A and B are octets in allocation address 185.A.B.0/22. > Octet A can be named "series" and B is possible block count in each "series". > > B is always 64 and A (for now) is 97. Thus totally allocated T2 = 97 * 64 = 6208 blocks from last /8. > > Ratio of transferred blocks is 237 / 6208 * 100 ~ 3.81% > > From my point of view it's NOT SIGNIFICANT number at all. > > --------------------------------------------------------------------------------------------- > > Let's also calculate how /22 reselling impact on IPv4 exhaustion. > > RIPE NCC allocate approximately 10-15 /22's per day of 40-60 /22's per week (S). Averaging will receive S = 50. > > Sold /22's have sped up IPV4 exhaustion only for T1 / S = 237 / 50 = 4.74 weeks. > > I.e. /22 reselling impact is just 1 MONTH of exhaustion! > > --------------------------------------------------------------------------------------------- > > Summarizing I would like to say that the proposal has questionable reasons of its introduction, also questionable goals and offer inoperative changes to RIPE NCC policy. > > Also I believe that listed arguments will help WG to make Impact Analysis. > > 23.04.2015, 13:29, "Infinity Telecom SRL" <ip at infinitytelecom.ro>: >> Hello, >> >> If this proposal will be accepted: https://www.ripe.net/participate/policies/proposals/2015-01 >> >> The price per IP found at "IPv4 Transfer Listing Service" will be double or even worst. >> >> Little companies will be out of business.. and we will be one of them. >> >> To pay double or even more for some spammed IP.. its not a good choice.. only because smart guys with no real internet business hold very large blocks >> >> This proposal should have more time, its not like any other proposal, this can affect activity for a lot of small companies. >> >> Thank you. >> >> -- >> Cu stima, >> Gabriel Voitis | Sales Manager >> voitis at infinitytelecom.ro >> >> INFINITY TELECOM SRL | Bd-ul Iuliu Maniu nr 7, Corp A, Scara 2 >> Mobil: +40 0725 677 477 | Tel: +40 021 7808805 | Fax: +40 021 7808806 >> contact at infinitytelecom.ro > > -- > With best regards, Vladimir Andreev > General director, QuickSoft LLC > Tel: +7 903 1750503 -- With best regards, Vladimir Andreev General director, QuickSoft LLC Tel: +7 903 1750503
- Previous message (by thread): [address-policy-wg] Transfer Requirements for IPv4 Allocations
- Next message (by thread): [address-policy-wg] Transfer Requirements for IPv4 Allocations
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]