This archive is retained to ensure existing URLs remain functional. It will not contain any emails sent to this mailing list after July 1, 2024. For all messages, including those sent before and after this date, please visit the new location of the archive at https://mailman.ripe.net/archives/list/[email protected]/
[db-wg] Proposal regarding Orphaned Objects
- Previous message (by thread): [db-wg] Proposal regarding Orphaned Objects
- Next message (by thread): [db-wg] Proposal regarding Orphaned Objects
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
William Sylvester
william.sylvester at addrex.net
Fri May 1 17:15:52 CEST 2015
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
- Previous message (by thread): [db-wg] Proposal regarding Orphaned Objects
- Next message (by thread): [db-wg] Proposal regarding Orphaned Objects
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
[ db-wg Archives ]