Dear all, We'd like to offer some clarification here. If the legacy holder has a contractual relationship with the RIPE NCC, the RIPE-NCC-LEGACY-MNT maintainer is added to the object, which enables the reclaim functionality. The holder of the parent object can also remove more specific route domain objects. When legacy resources are covered by a contractual relationship with the RIPE NCC, the resource holder has provided documentation that supports their claim to be the legitimate holder of those resources. In cases where legacy resources are not covered by a contractual relationship, the RIPE-NCC-LEGACY-MNT is not added, and so this functionality is not available. Please let me explain why this is the case. Legacy address space does not follow the same clear hierarchy as address space that was allocated by the RIPE NCC. The blocks we issue are "allocated" to LIRs, who can then further "assign" to their customers. In these cases, the LIR retains holdership and has responsibility over the IP block. With regards to legacy resources, we mentioned the following in our impact analysis of the policy proposal:
It is often not clear if the legitimate holder of these resources is the organisation that received the resources from InterNIC for redistribution, or the subsequent organisation that received the resources. It is therefore not clear which of the organisations involved has the right to enter into a contractual agreement.
When the situation presents itself where there are multiple layers of legacy resources distribution, it is the responsibility of the parties involved to find an agreement on which party is the legitimate holder of the legacy resource. Only when the parties involved have agreed on a decision, the RIPE NCC will evaluate a contractual relation request.
In cases where holdership is unclear, the RIPE NCC needs to remain neutral and impartial for all organisations involved. Allowing the organisation maintaining the parent inetnum object to remove everything more specific would essentially mean taking a strong position regarding who the legitimate holder of the address space was. However, in cases where a contractual agreement is in place, the holder of the resources has already provided documentation supporting their claim to holdership of the resources, and have confirmed that they will follow RIPE Policies and RIPE NCC procedures. Of course, if the community believes that the holders of parent objects should automatically gain authority over everything more specific, we can implement this. I hope this clarifies. Best regards Andrea Cima RIPE NCC On 3/5/15 18:10, Niall O'Reilly wrote:
On Fri, 01 May 2015 20:34:43 +0100, Job Snijders wrote:
On Fri, May 01, 2015 at 07:07:00PM +0000, Shane Kerr wrote:
On Fri, 1 May 2015 11:15:52 -0400 William <william.sylvester@addrex.net> wrote:
In my use cases, the holder of the inetnum is the ultimate authority
In any use case I can imagine the inetnum should be the ultimate authority, it comes as a suprise to me this is not the case for some types of space. The entire security model flows from there.
I sympathize with your problem, and actually tend to agree with your philosophy here.
Why should we treat legacy networks differently from non-legacy networks?
Making it difficult to clean up related objects just results in crap in the database, and may have actual operational impact (inability to peer, incorrect reverse DNS, and so on).
So I think we should accept your proposal, which then becomes, "apply reclaim functionality using all inetnum objects".
I agree with the above.
I think I might also, but I'm not sure I've fully understood.
It would be much appreciated if anyone offer insight in how this came to be and why we should consider it anything else then an undocumented inconsistency (or should I just say 'bug')?
I definitely agree with this.
Niall