Hi Massimo,
On 21 Feb 2022, at 16:29, Massimo Candela via db-wg <db-wg@ripe.net> wrote:
Hi Ed,
Thanks for the work done.
Thank you!
On 21/02/2022 15:56, Edward Shryane via db-wg wrote:
We will also start enforcing the same validation on "remarks: geofeed" as on "geofeed:" for consistency.
I think you should not enforce anything on remarks. For what I know, remarks have been a free text field up to now.
I agree! In general, Whois doesn't attempt to validate free-text fields, since they can contain anything, in any format. However, the RFC draft that we base the implementation on, allows for a "remarks: geofeed <url>" as an alternative to a "geofeed:" attribute: Ideally, RPSL would be augmented to define a new RPSL geofeed: attribute in the inetnum: class. Until such time, this document defines the syntax of a Geofeed remarks: attribute which contains an HTTPS URL of a geofeed file. The format MUST be as in this example, "remarks: Geofeed " followed by a URL which will vary. (Ref. https://datatracker.ietf.org/doc/html/draft-ymbk-opsawg-finding-geofeeds)
In my view: (1) RIPE NCC promotes the "geofeed" field for the geofeed purpose, instead, using "remarks" it is not the practice suggested by RIPE NCC and so I don't believe it is RIPE NCC's responsibility;
The DB team have implemented the draft RFC to standardise "geofeed:", but "remarks:" is defined as the alternative. As "remarks:" can be used as an alternative to "geofeed:", if we don't also validate "remarks:" it can be used to bypass any validation done on "geofeed:". The "remarks:" format in the draft gives it a structure that allows it to be validated (i.e. it's not really free text). If the two constructions are considered equivalent by clients, any unequal validation on "geofeed:" will be a disincentive to replace "remarks:", and we will be left with both indefinitely.
(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:").
(3) starting to validate the content of remarks creates a precedent in which RIPE NCC is responsible for checking remarks content (possibly, in the future, not only about geofeeds).
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.
But I don't know anything about legal things, so this is just my point of view.
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:" ? Not doing any validation is not an option given the Legal review. Regards Ed Shryane RIPE NCC
Ciao, Massimo