[db-wg] Proposal regarding Orphaned Objects

All,

On Tue, 05 May 2015 09:25:05 +0100
"Niall O'Reilly" <niall.oreilly at ucd.ie> wrote:

> On Mon, 04 May 2015 21:03:20 +0100,
> denis walker wrote:
> > 
> > In a neat and perfect world where everyone had all documentation for
> > all contracts, deals, agreements that have ever been made regarding
> > address space, then I agree there is no problem giving out these
> > permissions as everything can be put right if mistakes are made.
> > 
> > However, we don't all live in that perfect world. There have been
> > examples where a block of addresses was given to an organisation
> > many years ago to be divided up and distributed to other
> > organisations. But sometimes that parent block still exists in the
> > RIPE Database and is registered with an organisation. If we give
> > this organisation the reclaim permissions 'by default' they can
> > delete anything they want.
> 
>   Thanks for explaining, Denis and Andrea.
> 
>   Without knowing whether the division and distribution was intended
>   as a sub-allocation or rather as a transfer, it's not possible (for
>   the RIPE NCC or for another external observer) to be sure whether
>   control over the parent block as an aggregate reasonably "belongs
>   to" the registered organization.

This is true.

However, we know that some people who maintain the parent objects are
unable to correct the database. This is a problem both for those
maintainers and for anyone hoping for accurate information about the
network.

We know there is a theoretical problem where someone might have network
information deleted from the RIPE database that they want to keep there.
We do not now if this is an actual problem.

I remind the working group that if someone *does* have their network
deleted inappropriately, then the record can be re-created. Updating a
RIPE Database entry does not instantly de-peer people or the like.

I'm quite happy with a dispute policy that works to always restore a
more-specific inetnum object in case of complaint by the former
maintainer of the object, and then lets any further resolution occur
using other means.

Cheers,

--
Shane