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/address-policy-wg@ripe.net/
[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 ]