<html><head><style>body{font-family:Helvetica,Arial;font-size:13px}</style></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><div id="bloop_customfont" style="font-family:Helvetica,Arial;font-size:13px; color: rgba(0,0,0,1.0); margin: 0px; line-height: auto;">Dear Remco,</div><div id="bloop_customfont" style="font-family:Helvetica,Arial;font-size:13px; color: rgba(0,0,0,1.0); margin: 0px; line-height: auto;"><br></div><div id="bloop_customfont" style="font-family:Helvetica,Arial;font-size:13px; color: rgba(0,0,0,1.0); margin: 0px; line-height: auto;">For a few months now, we have been talking on how to give some supplementary IP’s to LIR’s and now you are proposing a policy to retrieve back some already allocated IP space?</div><div id="bloop_customfont" style="font-family:Helvetica,Arial;font-size:13px; color: rgba(0,0,0,1.0); margin: 0px; line-height: auto;"><br></div><div id="bloop_customfont" style="font-family:Helvetica,Arial;font-size:13px; color: rgba(0,0,0,1.0); margin: 0px; line-height: auto;">Even if we are in the afterlife of IPv4, you cannot force the return of /22’s from the last /8 after a merger or acquisition.</div><div id="bloop_customfont" style="font-family:Helvetica,Arial;font-size:13px; color: rgba(0,0,0,1.0); margin: 0px; line-height: auto;"><br></div><div id="bloop_customfont" style="font-family:Helvetica,Arial;font-size:13px; color: rgba(0,0,0,1.0); margin: 0px; line-height: auto;">How do will RIPE plan to deal with the already transferred /22’s from the /8, or the already sub allocated IP spaces?</div><div id="bloop_customfont" style="font-family:Helvetica,Arial;font-size:13px; color: rgba(0,0,0,1.0); margin: 0px; line-height: auto;">There are many LIR’s that announce more than 1 /22’s from the /8, we should try to focus on the abuse and not dramatically change a policy that almost works.</div><div id="bloop_customfont" style="font-family:Helvetica,Arial;font-size:13px; color: rgba(0,0,0,1.0); margin: 0px; line-height: auto;"><br></div><div id="bloop_customfont" style="font-family:Helvetica,Arial;font-size:13px; color: rgba(0,0,0,1.0); margin: 0px; line-height: auto;">At this moment I have no idea how but maybe we should implement an anti-abuse policy with full powered department that can deal with ‘creative interpretations’?</div><div id="bloop_customfont" style="font-family:Helvetica,Arial;font-size:13px; color: rgba(0,0,0,1.0); margin: 0px; line-height: auto;"><br></div><div id="bloop_customfont" style="font-family:Helvetica,Arial;font-size:13px; color: rgba(0,0,0,1.0); margin: 0px; line-height: auto;">I really do understand your good intention here but instead of fixing the ‘creative interpretations’ it will cause more and more issues.</div><div id="bloop_customfont" style="font-family:Helvetica,Arial;font-size:13px; color: rgba(0,0,0,1.0); margin: 0px; line-height: auto;"><br></div><div id="bloop_customfont" style="margin: 0px;">I am against this proposal as it is unfair, and some or maybe of us do not agree with <font face="Helvetica Neue"><span style="font-size: 14px;">retroactively policies, we already know how the work from our governments :)</span></font></div><div id="bloop_customfont" style="margin: 0px;"><font face="Helvetica Neue"><span style="font-size: 14px;"><br></span></font></div><div id="bloop_customfont" style="margin: 0px;"><font face="Helvetica Neue"><span style="font-size: 14px;">Thanks,</span></font></div><div id="bloop_customfont" style="margin: 0px;"><br></div><div id="bloop_customfont" style="margin: 0px;"><font face="Helvetica Neue"><span style="font-size: 14px;"><br></span></font></div> <div id="bloop_sign_1463489742332918016" class="bloop_sign"><div style="font-family:helvetica,arial;font-size:13px">-- <br>Bogdan-Stefan Rotariu<br>Sent with Airmail</div></div> <br><p class="airmail_on">On 17 May 2016 at 15:09:14, Remco van Mook (<a href="mailto:remco.vanmook@gmail.com">remco.vanmook@gmail.com</a>) wrote:</p> <blockquote type="cite" class="clean_bq"><span><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div></div><div> <title></title> <div class=""><br class=""></div> <div class=""> <div style="font-family:'Helvetica Neue';font-size:14px;" class=""> Thank you Marco. </div> <div style="font-family:'Helvetica Neue';font-size:14px;" class=""> <br class=""></div> <div style="font-family:'Helvetica Neue';font-size:14px;" class=""> Dear colleagues,</div> <div style="font-family:'Helvetica Neue';font-size:14px;" class=""> <br class=""></div> <div style="font-family:'Helvetica Neue';font-size:14px;" class=""> Yes, this is another policy proposal about IPv4. It's even about the current allocation policy (confusingly known as 'last /8'). I'm sorry it's come to this.</div> <div style="font-family:'Helvetica Neue';font-size:14px;" class=""> <br class=""></div> <div style="font-family:'Helvetica Neue';font-size:14px;" class=""> The proposal doesn't aim to change a lot about the *intended* goals of the last /8 policy - instead, it tries to clarify the current policy and lock it down against creative interpretations.</div> <div style="font-family:'Helvetica Neue';font-size:14px;" class=""> <br class=""></div> <div style="font-family:'Helvetica Neue';font-size:14px;" class=""> We're in the IPv4 afterlife, and have been for about 3.5 years. The last scrap of IPv4 space that any LIR can get is meant for a specific purpose - to facilitate migration to IPv6. The age of the 32 bit integers is over. The other purpose of the 'last /8' policy is to be able to hand out IPv4 space to new entrants for as long as feasible. These specific purposes are currently not reflected anywhere once a block has been allocated, and this proposal means to change that. To summarise the proposed changes:</div> <div style="font-family:'Helvetica Neue';font-size:14px;" class=""> <br class=""></div> <div style="font-family:'Helvetica Neue';font-size:14px;" class=""> - All allocations handed out under the 'last /8 policy' will be (re-)registered as 'ALLOCATED FINAL';</div> <div style="font-family:'Helvetica Neue';font-size:14px;" class=""> - Allocations marked as 'ALLOCATED FINAL' can not be transferred or sub-allocated;</div> <div style="font-family:'Helvetica Neue';font-size:14px;" class=""> - Any LIR can hold up to a /22 of 'ALLOCATED FINAL' address space, regardless of how they got it;</div> <div style="font-family:'Helvetica Neue';font-size:14px;" class=""> - Any excess space will have to be returned to the RIEP NCC within 180 days (however I don't intend that this is applied retroactively); </div> <div style="font-family:'Helvetica Neue';font-size:14px;" class=""> - DNS reverse delegation will be limited to the LIR itself, and is limited to a total of a /22 in space.</div> <div style="font-family:'Helvetica Neue';font-size:14px;" class=""> <br class=""></div> <div style="font-family:'Helvetica Neue';font-size:14px;" class=""> And, outside of policy but enforceable as business rules following from this policy proposal:</div> <div style="font-family:'Helvetica Neue';font-size:14px;" class=""> - No RPKI for any 'ALLOCATED FINAL' blocks over a single /22</div> <div style="font-family:'Helvetica Neue';font-size:14px;" class=""> - No routing registry entries for any 'ALLOCATED FINAL' blocks over a single /22</div> <div style="font-family:'Helvetica Neue';font-size:14px;" class=""> <br class=""></div> <div style="font-family:'Helvetica Neue';font-size:14px;" class=""> Basically, every LIR gets 1 allocation, and if you no longer need it or you end up having more, you have to return the excess. All the extra limitations should be workable if you're using the space the way it was intended, but make it unattractive to collect allocations for other purposes.</div> <div style="font-family:'Helvetica Neue';font-size:14px;" class=""> <br class=""></div> <div style="font-family:'Helvetica Neue';font-size:14px;" class=""> Let's hear your thoughts. I'll be at the RIPE meeting next week where I'll be talking about this proposal during the first APWG session.</div> <div style="font-family:'Helvetica Neue';font-size:14px;" class=""> <br class=""></div> <div style="font-family:'Helvetica Neue';font-size:14px;" class=""> Kind regards,</div> <div style="font-family:'Helvetica Neue';font-size:14px;" class=""> <br class=""></div> <div style="font-family:'Helvetica Neue';font-size:14px;" class=""> Remco van Mook</div> <div style="font-family:'Helvetica Neue';font-size:14px;" class=""> (no hats)</div> </div> <div class=""><br class=""></div> <br class=""> <div> <blockquote type="cite" class=""> <div class="">On 17 May 2016, at 14:05 , Marco Schmidt <<a href="mailto:mschmidt@ripe.net" class="">mschmidt@ripe.net</a>> wrote:</div> <br class="Apple-interchange-newline"> <div class=""> <div class="">Dear colleagues,<br class=""> <br class=""> A new RIPE Policy proposal 2016-03, "Locking Down the Final /8 Policy"<br class=""> is now available for discussion.<br class=""> <br class=""> The goal of this proposal is to limit IPv4 from the remaining address pool<br class=""> to one /22 per LIR (regardless of how it was received).<br class=""> These “final /22” allocations will receive a separate status with several restrictions:<br class=""> <br class=""> - These allocation are not transferrable<br class=""> - LIRs may only retain one final /22 following a merger or acquisition<br class=""> - Sub-allocations are not possible<br class=""> - Reverse delegation authority can not delegated to another party<br class=""> <br class=""> You can find the full proposal at:<br class=""> <br class=""> <a href="https://www.ripe.net/participate/policies/proposals/2016-03" class="">https://www.ripe.net/participate/policies/proposals/2016-03</a><br class=""> <br class=""> We encourage you to review this proposal and send your comments to<br class=""> <<a href="mailto:address-policy-wg@ripe.net" class="">address-policy-wg@ripe.net</a>> before 15 June 2016.<br class=""> <br class=""> Regards<br class=""> <br class=""> Marco Schmidt<br class=""> Policy Development Officer<br class=""> RIPE NCC<br class=""> <br class=""></div> </div> </blockquote> </div> <br class=""> <hr></div></div></span></blockquote></body></html>