[db-wg] geofeed issue: can't add geofeed attribute to PI /48

Hi Massimo,

> On 21 Feb 2022, at 16:29, Massimo Candela via db-wg <db-wg at 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
>