Re: [db-wg] Reverse aut-num queries in the database
David Freedman wrote:
After the feedback from the DB-WG Meeting in Vienna last week, I'd like to bring this back to the list.
I'd been trying to clean up an Aut-Num to return it to the NCC. I wanted to know if there was a way of undertaking an inverse search against the RPSL policies of my peers' Aut-Num objects to ensure they could remove all references to be before handing the resource back.
So - do I understand this correctly, you would like to have a query that lists all route[6]: objects with a particular origin: AS number in it? Or do you think about the Routing Policy analysis, e.g. the use of a particular AS number in a "macro"?
I'm currently doing this with a free-text search, since the database doesn't hold references to the tokens in the RPSL policy (or does it?)
Any better ideas?
Dave.
Sorry for not responding to this message for so long. Blush :-( Wilfried
On 20/04/2012 11:30, "Wilfried Woeber, UniVie/ACOnet" <Woeber@CC.UniVie.ac.at> wrote:
David Freedman wrote:
After the feedback from the DB-WG Meeting in Vienna last week, I'd like to bring this back to the list.
I'd been trying to clean up an Aut-Num to return it to the NCC. I wanted to know if there was a way of undertaking an inverse search against the RPSL policies of my peers' Aut-Num objects to ensure they could remove all references to be before handing the resource back.
So - do I understand this correctly, you would like to have a query that lists all route[6]: objects with a particular origin: AS number in it?
Or do you think about the Routing Policy analysis, e.g. the use of a particular AS number in a "macro"?
No, let me give you an example, from my AUT-NUM, AS8426 , which is quite large (for particular reasons, the subject of another discussion) *** remarks: AS1140 (PEER) - SIDN Stichting Internet Domeinregistratie Nederland mp-import: afi ipv4.unicast from AS1140 195.69.144.49 at 195.69.144.82 accept AS1140 mp-export: afi ipv4.unicast to AS1140 195.69.144.49 at 195.69.144.82 announce AS-CLARANET *** lets imagine that SIDN suddenly decide that they wish to cease operating and return their AS number back to the NCC, I'm left with this fragment in my object, and nobody knows it is there unless they find it by a freetext search, so it doesn't get cleaned up. The problem is that the database (I'm led to believe) doesn't normalise any of this stuff sufficiently to make it searchable! Dave.
I'm currently doing this with a free-text search, since the database doesn't hold references to the tokens in the RPSL policy (or does it?)
Any better ideas?
Dave.
Sorry for not responding to this message for so long. Blush :-( Wilfried
participants (2)
-
David Freedman
-
Wilfried Woeber, UniVie/ACOnet