<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40"><head><meta http-equiv=Content-Type content="text/html; charset=koi8-r"><meta name=Generator content="Microsoft Word 15 (filtered medium)"><style></style></head><body lang=RU link="#0563C1" vlink="#954F72"><div class=WordSection1><o:p> </o:p>First of all, I think we all should agree that current debates are all about abusing LIR creation procedure to get extra IPs. Why some percent of members was trying to explain here their reasons why they can’t use IPv6. <o:p></o:p><o:p> </o:p>Relatively to the main discussion in short: I believe we can do nothing to prevent different types of abusing for a ‘long distance’. <o:p></o:p><o:p> </o:p>They’ve asked whether the activity of members opening additional LIR accounts is a problem that must be prevented? Sure it is, RIPE can block requests from existing LIRs, or add some extra payments for such procedure. The second option actually is nothing but a small delay to the times until the prices for IPv4 will be higher than LIR charges. <o:p></o:p>As mentioned earlier, if we just block an ability to create LIR for an existing member, it’s definitely not a problem to register new companies. It is not even necessary to create a new company, almost everyone can open paint application and create all needed documents. RIPE has no ability to validate somehow whether the documents are juridical correct or not, including merging/sell documents. The principles of honesty, responsibility and reasonableness are fading when money comes to play. IPv4 address space is already monetized and we can’t fight with or deny this fact.<o:p></o:p>Besides, I don’t agree that any types of audit can help here. This procedure requires huge effort not only from RIPE employees but from LIR engineers too, in large LIRs it may be prolonged for indeterminable time. Estimating effectiveness of every particular LIR address space and attempts to retrieve some IPv4, could lead RIPE to become a regulator not a coordinator. <o:p></o:p><o:p> </o:p><o:p> </o:p>It’s a good idea to check ARIN policies applied to their last block, and may be adopt some paragraphs. Some basic principles that are emphasized:<o:p></o:p><![if !supportLists]>- <![endif]>Documentation, network schemes and so on are strongly required for any allocation. In contrast with ARIN, RIPE just give /22 to any new member.<o:p></o:p><![if !supportLists]>- <![endif]>Necessity to provide data demonstrating utilization of this space (immediately and after one year)<o:p></o:p><o:p> </o:p>Summarizing all above, I think RIPE should prevent any IPv4 address allocations (including new LIR members) without complete plans, schemes and demonstrations of necessity and effectiveness. May be RIPE can afford one dedicated engineer being responsible for analyze such plans. Still it must be clear that complete IPv4 exhaustion is just the question of time, no matter how hard RIPE put the screws on allocation procedure.<o:p></o:p><o:p> </o:p><o:p> </o:p><o:p> </o:p>Alex Klimenko<o:p></o:p>Digital Network <o:p></o:p><o:p> </o:p></div></body></html>