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] source: field for non RIPE address space
- Previous message (by thread): [db-wg] source: field for non RIPE address space
- Next message (by thread): [db-wg] source: field for non RIPE address space
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Job Snijders
job at instituut.net
Fri Nov 14 14:05:48 CET 2014
On Fri, Nov 14, 2014 at 11:15:22AM +0000, Nick Hilliard wrote: > <snip> > > But that aside, some organisations use IRRDB information extensively, > particularly IXPs running route servers. Many of these organisations > filter on source: because of the amount of trash in alternative IRRDBs. > > So, could the RIPE NCC database people consider using a different source: > value for non RIPE address space, so that it would be possible for irrdb > users to easily filter out authoritative data from non authoritative data? > > E.g. 185.6.36.0/22 might continue to have "source: RIPE", but a prefix like > "210.57.192.0/20" might have "source: RIPE-NONAUTH". > > Would this be feasible for the RIPE DB software? I think this is a good idea. If we implement such a RIPE-NONAUTH source, I'd expect a query structered like this: $ whois -h whois.ripe.net -- "-K -s RIPE -Troute 210.57.192.0/20" to return "%ERROR:101: no entries found". Maybe another way of phrasing the feature request: anything created due to authorisation against the RIPE-NCC-RPSL-MNT object will have "source: RIPE-NONAUTH" set, instead "source: RIPE".? Do we expect a different split file on the FTP site for RIPE-NONAUTH objects? Kind regards, Job
- Previous message (by thread): [db-wg] source: field for non RIPE address space
- Next message (by thread): [db-wg] source: field for non RIPE address space
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
[ db-wg Archives ]