Hi Niall, community, Niall O'Reilly wrote:
On 15 May 2008, at 10:02, Gert Doering wrote:
This means that the proposal needs to re-enter review phase, and we'll ask you to closely look at it, and confirm that you're expressing support for the *latest revision* of the proposal.
I am trying to do that once again and I am *not* able to express my support for the latest (Version 2) revision of the proposal and the draft doc. http://www.ripe.net/ripe/draft-documents/ripe-424-draft.html , for a couple of reasons: - the headline of this draft is "IPv4 Address Allocation and Assignment Policies for the RIPE NCC Service Region" which for me implies that it is supposed to apply to address space distributed as a service by the RIPE NCC to its Service Region. This seems to be confirmed (in Section 9.0) by the paragraph headline of "End Users requesting PI space should be given this or a similar warning:" Looking at the (1st block of) NEW TEXT talking about PI and routability seems pretty reasonable and consistent. However, looking at the next block of text labelled ADDITION TO DOCUMENT which starts to - out of context - talk about ERX (to me) seems grossly illogical and structurally misplaced. - trying to sneak in a retro-active requirement into a policy which would require the NCC to impose usage limitations, contractual work or new fees onto *legitimate* holders of legacy resources without, at the same time, offering some reasonable incentive for the resource holders to agree and comply, poses the risk of damaging the perception of the RIPE NCC as a professional, impartial and "reasonable" organisation trying to support the community. I thus propose to remove this additional text block (which seems to have been introduced without much review and consistency checking when producing Version 2). At the same time I'd like to explicitely voice support for the goal of - eventually - trying to bring the legacy resource holders (including AS numbers) under the umbrella of the RIPE NCC's regular resource management environment. The most reasonable point in time to do that seems to be the availability of the RPKI Service (in production quality) and maybe by way of a separate policy proposal - if a new policy is necessary at all at that point in time, rather than simply a new service offer. Regards, Wilfried.