<html><head><meta http-equiv="Content-Type" content="text/html charset=us-ascii"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">Hello,<div><br><div><div>On 26 Jun 2013, at 14:48, Gert Doering <<a href="mailto:gert@space.net">gert@space.net</a>> wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite">Hi Carlos,<br><br>On Wed, Jun 26, 2013 at 08:42:50AM +0100, Carlos Friacas wrote:<br><blockquote type="cite">But shouldn't this go through the regular PDP...?<br>(i.e. who really needs this should write a new policy proposal...)<br></blockquote><br>We're not actually changing policy - we have something here where<br>the policy text isn't specifying anything, so if we can agree how<br>we want the RIPE NCC to handle this, we can do this in a quicker and <br>more light-weight way of "just asking the community for guidance".<br><br>One of the important aspects here is that this will not change the way<br>the RIPE NCC hands out resources.<br></blockquote><div><br></div><div><br></div><div>I mentioned my similar worry on this at the last RIPE meeting in Dublin, but there was not enough time at that session for a proper discussion. </div><div><br></div><div>I will try here again:</div><div><br></div><div>I have a sense this is further than just stamping a best practice for the RIPE NCC and giving them guidance on a corner case.</div><div>First of all that we are already talking about transfer policies and practices here in this thread is a sign that this is not just a simple guidance issue. </div><div><br></div><div>PI assignments were given for a specific reason at the time. The recipient is an LIR or not is irrelevant here. </div><div>The purpose was specific at the time of the assignment and obviously different than what a PA allocation is or was at the time. </div><div>PI assignments are assignments to start with, while allocations are blocks to keep assignments within. </div><div><br></div><div>We may like it or not, but the policy text still has various mentions of this criteria issue:</div><div><br></div><div>---</div><div><p class="NormalWeb1">All assignments are valid as long as the original criteria on which the
assignment was based are still valid and the assignment is properly
registered in the RIPE Database. If an assignment is made for a specific
purpose and that purpose no longer exists, the assignment is no longer
valid.</p><div><br></div><p class="NormalWeb1">End Users requesting PI space should be given this or a similar warning:</p><p class="NormalWeb1"><em>Assignment of this IP space is valid as long
as the criteria for the original assignment are still met and is also
subject to the policies described in the RIPE NCC document entitled ...</em></p><div>---</div></div><div><br></div><div>Accordingly I do not think changing the status of an address block from PI Assignment to PA Allocation abides completely with the current RIPE Policy as it is written today. </div><div>And I think the policy text should be changed first to allow the RIPE NCC properly to perform such a practice.</div><div><br></div><div>This will be good for the RIPE NCC, as they are supposed to be following the policy text to the letter.</div><div>This will also be good for the community, I think, for transparency reasons: </div><div><br></div><div>A lot of people who are not following the current debate in the list may never have the chance to be aware of this "specific" practice to be adopted by the RIPE NCC, unless it is properly documented through a proposal and then in the policy document, which is the main purpose of the PDP in my opinion. </div><div><br></div><div>Finally I want to note that I do agree with the argument that the important thing here is to get the registration in the database right. </div><div>I am not disagreeing with this and in fact I do agree with this overall goal. </div><div><br></div><div>But I also am an advocate of doing things the right way. </div><div>The policy documents and the PDP are there for a reason. </div><div>We should be careful in by-passing them by adopting a practice after just holding a thread in a mailing list without a proper final-documentation for everyone. </div><div><br></div><div>Cheers</div><div>Filiz Yilmaz </div><div><br></div><div><br></div><br><blockquote type="cite"><br>Gert Doering<br> -- APWG chair<br>-- <br>have you enabled IPv6 on something today...?<br><br>SpaceNet AG Vorstand: Sebastian v. Bomhard<br>Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann<br>D-80807 Muenchen HRB: 136055 (AG Muenchen)<br>Tel: +49 (89) 32356-444 USt-IdNr.: DE813185279<br></blockquote></div><br></div></body></html>