Hi Ed, On 22/02/2022 09:54, Edward Shryane wrote:
(Ref. https://datatracker.ietf.org/doc/html/draft-ymbk-opsawg-finding-geofeeds)
I remember that :)
The "remarks:" format in the draft gives it a structure that allows it to be validated (i.e. it's not really free text).
The RFC defines a structure for the user to insert their entries, and for the readers to parse those entries. But it does not say that the RIR should start validating remarks, and no other RIR is doing that. What was defined in NWI-13 was defined for the new "geofeed" attribute, not for remarks. By using remarks, the rfc promotes a self-organized approach to use current geofeed technology in current whois technology, it doesn't introduce nothing new in the logic of remarks.
(2) Users can always encode the same information in remarks without geofeed (which would just increase the mess and bypass the check);
Correct, I am proposing that we validate both equally to avoid this (we don't want an incentive for "remarks:").
What I meant is that, you can enforce a regex "geofeed URL" in remarks as much as you like, but as soon as users realize that, they can bypass that with another syntax. What it take it's just one big geolocation provider to suggest an alternative syntax. When things get too complicated, users find ways around it, making the problem worse.
Correct, it's already possible to write anything in "remarks:", however if we don't validate we're giving an incentive to keep using "remarks:" for geofeed I am open to suggestions on how to resolve this. For example, instead of validating "remarks: geofeed", can this construction be deprecated (removed) in favour of "geofeed:" ?
At the moment RIPE NCC is the only one having a specific field for "geofeed", so I would not drop the support for "remarks". It is also the only one validating "remarks". Honestly, for how it is getting complicated, I am more in favor of dropping "geofeed" and go back to remarks. Ciao, Massimo