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/db-wg@ripe.net/
[db-wg] proposal: new attribute 'geofeed:'
- Previous message (by thread): [db-wg] proposal: new attribute 'geofeed:'
- Next message (by thread): [db-wg] proposal: new attribute 'geofeed:'
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Lutz Donnerhacke
L.Donnerhacke at iks-service.de
Wed Oct 7 08:31:11 CEST 2020
> By enriching the RPSL dictionary and having a “geofeed” RPSL attribute > (which by the way should not be 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?
- Previous message (by thread): [db-wg] proposal: new attribute 'geofeed:'
- Next message (by thread): [db-wg] proposal: new attribute 'geofeed:'
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
[ db-wg Archives ]