[address-policy-wg] [db-wg] Guidance Requested: Reassigning Referenced ASNs
- Previous message (by thread): [address-policy-wg] [db-wg] Guidance Requested: Reassigning Referenced ASNs
- Next message (by thread): [address-policy-wg] [db-wg] Guidance Requested: Reassigning Referenced ASNs
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Andrey Semenchuk
andrey at trifle.net
Thu Jun 27 10:53:46 CEST 2013
On 06/27/13 10:59, Gert Doering wrote: > Hi, > > On Thu, Jun 27, 2013 at 09:51:56AM +0300, Andrey Semenchuk wrote: >> On 06/27/13 01:52, Andreas Schachtner wrote: >>> Sanity checking upon submitting to the DB could prevent this. >> And it's the main problem that we should talk. But not about removing >> some references to the objects that doesn't exists >> The lack of sanity check for the corresponding fields during database >> updates - is the root of the problem. > It's not the *root* of the problem, but just one aspect (when the AS number > is returned, all references to it are perfectly fine, up to that point) - > and even then, you can't really solve the whole issue with technical means. > > Consider this: > > AS X is returned > AS Y references it, database object is changed by NCC to remove reference to X > <two month pass> > AS X is reassigned to someone else > AS Y sends an update to it's aut-num: object, restoring the reference to X > > now what - is this "illegal" because it's "an old reference", or should > this be permitted, because it's really referencing to "the new holder of X"? Reference to any object is not the "old reference" or the "new reference" - it's the "the only one valid reference". Anytime End User that holds AS Y can add reference to AS Y. And it's not the problem of reassigning ASNs: until this information is not checked by RIPE's software (for example - like adding origin field to the route object) - any user will can add reference to any ASN (but for the assigned ASNs only). It's the separate question: how to prevent users to add references to objects that shouldn't be referenced by this object. It may be done by checking cross-references from the referenced and referencing objects for example. But it's not the question to ASN reassignment process > So, speaking as router admin, my preference is to > > - inform holders of objects with dangling references (admin-c, tech-c) > - if nothing changes in, say, two weeks, inform LIR contacts as well > - two weeks later, if the object is still referencing stale ASes, change > object in DB, and again inform admin-c, tech-c, LIR contact > > - reassign the no longer referenced AS And your proposal is inconsistent with your example: the End User still can "restore reference to AS X inside AS Y object description during updating aut-num object" -- Best wishes, Andrey Semenchuk Trifle Internet Service Provider (056) 731-99-11 www.trifle.net
- Previous message (by thread): [address-policy-wg] [db-wg] Guidance Requested: Reassigning Referenced ASNs
- Next message (by thread): [address-policy-wg] [db-wg] Guidance Requested: Reassigning Referenced ASNs
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]