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