[db-wg] Proposal regarding Orphaned Objects

All,

To clear things up, it looks like while these features may exist for certain kinds of space they do not work for all kinds of space. Specifically "status: LEGACY” blocks do not have this ability. I know this has raised some concerns about how the technical limitations are a limiting factor so much as the policy implications. In the dealing heavily with the new legacy space as we try to get the legacy blocks in the hands of people who are best able to utilize them, I have found a series of limitations where there are objects with stale data. Many of these examples appear to be older data and misconfiguration. In practice this prevents these number blocks from being accurate due to the current limitations of the existing implementation.   I would say only about 20% of the time can you contact a network provider and resolve the issue. In the other 80% of the time, the emails and phone numbers do not work. In some circumstances RIPE NCC has been very helpful in being able to locate details, but this a manual process that takes time and resources. Typically, if RIPE NCC is unable to locate the party then they must make the changes which can create other requirements that should not be necessary. 

In my use cases, the holder of the inetnum is the ultimate authority for a number block and associated routing. It’s possible that due to historical reasons there is a lot of older data that needs cleaning up. I know for example locked ‘status: LEGACY’ objects typically have high proof of holder-ship required. Once this is done, a holder is able to have their object un-locked. These associated objects are not always included in this process. Should they be? Is there a case where an inetnum holder should not be able to dis-associate in-addr or routing objects from their inetnum? 

Thanks,
Billy

> On May 1, 2015, at 9:11 AM, Gert Doering <gert at space.net> wrote:
> 
> Hi,
> 
> On Fri, May 01, 2015 at 08:28:05AM -0400, William Sylvester wrote:
>> Just to be clear, this proposal is specifically for objects related 
>> to an inetnum like routing and in-addr where the maintainer is not 
>> the same as the maintainer of the inetnum. 
> 
> We hear you, but you do not listen.  Route: objects can be deleted already
> today if you have maintainer rights on the corresponding inetnum: object
> (mnt-routes: might be needed).
> 
> You can not *change* them, but you can delete and recreate them with
> current information.
> 
> Gert Doering
>        -- NetMaster
> -- 
> have you enabled IPv6 on something today...?
> 
> SpaceNet AG                        Vorstand: Sebastian v. Bomhard
> Joseph-Dollinger-Bogen 14          Aufsichtsratsvors.: A. Grundner-Culemann
> D-80807 Muenchen                   HRB: 136055 (AG Muenchen)
> Tel: +49 (0)89/32356-444           USt-IdNr.: DE813185279