On Wed, Oct 07, 2020 at 06:31:11AM +0000, Lutz Donnerhacke via db-wg wrote: > > By enriching the RPSL dictionary and having a “geofeed” RPSL attribute > > (which by the way should not be mandatory)
Indeed, it is not mandatory. > > will be easier for someone to extend his parser to use that field > > without overloading the parser with many “if” and regex expressions. > > Plus the upcoming RFC specifies A that "The format MUST be as in > > this example,“ so a verification needs to be applied later on. > > I second this. > > > Of course it’s weird to talk about enriching RPSL on 2020 but putting > > this apart, I believe it’s more correct to implement it in this way. > > If nobody ever adapts RPSL to the new requirements, RPSL is dead. > So the question is: Should we throw away the RRDB in favour of something else, > or do we extend RPSL in the way it was designed? Given that the implementation cost of adding a 'geofeed:' attribute in WHOIS servers is almost negligible, and it merely is a pointer to a the 'geofeed' data file in a format which can be used in different contexts (perhaps linked from peeringdb, perhaps referenced from RPKI objects), it seems a durable investment regardless of RPSL's future. Kind regards, Job
