[db-wg] Proposal regarding Orphaned Objects

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 at 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
> 
>