Hi Jerome,
> On 17 May 2016, at 16:26 , Jérôme Nicolle <[email protected]> wrote: > > Hello, > > I firmly oppose this policy proposal for the following reasons : I will try to address your objections below: > > * Interference with routing > > I always understood RIPE NCC must not consider routing issues as > legitimate (when justificating address space requests was a thing), the > counterpart could be implicit. > > De-agregating a /22 is legitimate in many cases, especially when it's > your only available block. Restricting route objects or RPKI will lead > to *weaken routing's security* and *reduce the registry's quality*. > > It would also make it impossible to mitigate BGP hijacking if a > legitimate announce cannot counter a more specific illegitimate one. > It does not interfere with routing. It specifically states 'up to a total of a /22 of IPv4 space'. It doesn't say it's supposed to be a single block. How you want to carve up that /22 is up to you. > * Not concise enough > > The proposal actually means "Every /8 PA is now a PI". Such policy > should be written in its simpliest form, which in this case is an 8 > words sentence. No, it doesn't mean "every /8 PA is now a PI". There are some broad similarities with the old PI policy. The concept of "PI" no longer exists in current IPv4 allocation policy except for transfers; an attempt to revive IPv4 PI failed. > > * Not adressing the multi-LIR issue > > If such proposal AND the re-authorization of multiple LIR account per > member both gets to pass, it would almost feel legitimate to create > multiple LIRs in order to be allowed to secure our networks by > de-agregating some critical prefixes off it. > > Encouraging the waste of address space seems incompatible with the > community's best interests. I don't see how this wastes address space any more than current policy. I also don't see how you'd need multiple LIRs to 'de-aggregate some critical prefixes'. On top of that, conservation went out the window with the acceptance of 2013-03. > > * Unclear non-transferability > > There are two kinds of possible transfers : > > - The legitimate one is Mergure and Acquisition, which reflects real > network and business events. > - The crook's one is the listing service, used to get profits off > privatizing the public domain. > > Only the second one should be banned, or mergure and acquisitions won't > be properly reflected into the registry. I explicitly didn't want to express any opinions on what kind of transfers ought to be allowed. If regular transfers get banned, going through the M&A process - especially with empty shell companies - is trivial; which is why I'm proposing that it doesn't matter how you ended up with those extra blocks; you can't have more than 1. Right now, it doesn't matter how big or how small your organisation is, or how many address space you need, you get a /22. Once. However, the exception crept in that if you acquire or merge with other companies, this limitation does not currently apply. However practical, this exception needs to be contained if you want to effectively limit the marketability of these blocks. > > * Unfairness to new entrants > > The issue regarding new entrants with legitimate needs for more than a > /22 beeing unable to compete against incubents, who never had to justify > their dispendious tendancies regarding ERXs and over /16 PAs, could be > considered as unlawfull to some market authorities. > Legitimate need or not, setting up new LIRs or shell companies to become LIRs in order to gain extra address space to me is pretty obvious exploitation of a loophole in policy. It's like tax avoidance - it's not illegal but did you really open up a business in Panama for legitimate reasons? If you think this is unfair, every bit of needs based allocation policy (RFC 2050 and onwards) in the last 20 years has been unfair, and the fact that it's now down to just /22s is more or less irrelevant. No market authorities I'm aware of have objected to allocation policy during the past 2 decades. It's actually the other way around. Right now, we're all aware of creative interpretation of the current IPv4 allocation policy. If we don't try to address this behaviour, it would be very easy to assume that the community is approving of it. And that is a stick that new entrants a couple of years from now will use against us. Kind regards, Remco
signature.asc
Description: Message signed with OpenPGP using GPGMail
