Andrea,
On Monday, 2015-05-04 17:09:54 +0200,
Andrea Cima <
andrea@ripe.net> wrote:
> 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.
Right.
> 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.
So basically the answer is, "just sign a contract and you can clean up
your address space".
While I sympathize with the RIPE NCC's position, the end result is that
this makes it more difficult to get correct information into the
database. I can easily imagine a well-intentioned network administrator
would be unwilling or unable to deal with the hassle of updating
contracts, so just gives up.
Ultimately we are talking about changes to the database. The cost for
error is having to reverse these changes later. If someone has a
well-maintained inetnum object and it is deleted inappropriately then
they will get notified and can immediately start getting it fixed.
Personally I am happy for the parent objects to gain authority over
everything more specific.
Cheers,
--
Shane