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/[email protected]/
[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 ]
Jetten Raymond
raymond.jetten at elisa.fi
Tue Apr 28 09:09:45 CEST 2015
Hello All, This discussion is not solving its self or going anywhere. It's time to stop. The only thing it does at the moment is showing and explaining people publically how to cheat / mislead / misuse resources. Is anyone else interested in how to break which rule "because we can" Breaking laws or rules is perhaps considered a cool thing to do in some people's minds? The majority has a different opinion. My point or question? What will the RIPE NCC do with cases that can be proven to be abusive? Rgds, Ray. -----Original Message----- From: address-policy-wg [mailto:address-policy-wg-bounces at ripe.net] On Behalf Of Vladimir Andreev Sent: 28. huhtikuuta 2015 9:51 To: Carlos Friacas Cc: address-policy-wg at ripe.net Subject: Re: [address-policy-wg] Transfer Requirements for IPv4 Allocations I already expressed my opinion about multiple LIR's in details in previous letters. "Allocate you" means "you" as contact person. You are not required to have only one organisation. You can open some amount of legal person and then open LIR's for each. After that request /22's for your LIR's as mentioned earlier. 28.04.2015, 09:42, "Carlos Friacas" <cfriacas at fccn.pt>: > On Tue, 28 Apr 2015, Vladimir Andreev wrote: >> Hello! > Greetings, >> Petr means opening multiple LIR's and requesting /22's for all these LIR's at once. > "Opening multiple LIR's" == workaround, as in "a way to cheat the system". >> if you are lucky RIPE NCC will process you requests one after another and allocate you adjacent range of IP's. > It shouldn't be a matter of luck... > > As you say "allocate you", that implies ONE organization. > And ONE organization should only get ONE /22... ;-) > > Regards, > Carlos >> 28.04.2015, 09:24, "Carlos Friacas" <cfriacas at fccn.pt>: >>> Hello, >>> >>> Noone (in the RIPE/NCC service region) is able to get more than a /22, >>> according to current policies, or did i miss something? >>> >>> If someone is asking (and actually getting) more than a /22, those >>> allocations need to be revoked -- i honestly thought current policy >>> already included that... >>> >>> Regards, >>> Carlos >>> >>> On Sat, 25 Apr 2015, Petr Umelov wrote: >>>> Hi everybody. >>>> >>>> Let me tell some words about current proposal. >>>> >>>> Many providers (among them is our company) need to get (e.g.) /20 subnet (not 4 x /22). If we ask the RIPE NCC to allocate 4 x /22, we can get next variants: >>>> 1. /20 >>>> 2. 2 x /21 from different subnets >>>> 3. /22, /21, /22 >>>> >>>> There is only one chance to get /20 100% - make request for 7 x /22 (if the tickets will be processed together). But in this case we will have unwanted 3 x /22 which we can transfer to other LIRs to minimize our expenses. >>>> And also we can get different separate 4 x /22 (the worst case) and we have to transfer such blocks and make new request. >>>> >>>> If this proposal will be agreed, many providers (new and old) will have material losses. So I can't support this proposal. >>>> >>>> -- >>>> Kind regards, >>>> Techincal Director FastTelecom >>>> Petr Umelov >> -- >> 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 ]