Hi Ed,

This seems like a good implementation to me.

However, I don't think it's a good idea to limit the values on the "remarks" attribute in this way, as this could cause unwanted side effects with for ex. messages left on objects for other network operators.

Also:
> "Do not support non-ASCII values in URL domain names or path (these must be converted beforehand)"

Do you by this mean not supporting non-ASCII entirely? Or to have for ex. the web-interface convert IDNs to punycode, and have this listed on the object?

If the latter, and remarks can remain free-form, I'd say let's implement.

Cheers,
Jori Vanneste
FOD11-RIPE

-------- Original Message --------
On Apr 8, 2021, 2:27 PM, Edward Shryane via db-wg < db-wg@ripe.net> wrote:

Hi Randy,

> On 8 Apr 2021, at 13:54, Randy Bush via db-wg <db-wg@ripe.net> wrote:
>
>> Could we consider creating an NWI with a reduced scope?
>
> as an exercise, how minimal can we get?
>
> randy
>

Given the draft RFC:
https://datatracker.ietf.org/doc/draft-ietf-opsawg-finding-geofeeds/?include_text=1

I suggest the following minimal Solution Definition for an NWI:

- Implement support for an optional, single "geofeed:" attribute in inetnum and inet6num object types.
- Validate there is a maximum of either one "remarks: Geofeed" or "geofeed:" attribute per object.
- Validate the "geofeed:" URL is well-formed and specifies the HTTPS protocol.
- Include the "geofeed:" attribute in database dumps and split files.

And inversely, what we could leave out (to simplify the implementation):

- Do not support non-ASCII values in URL domain names or path (these must be converted beforehand)
- Do not migrate (re-write) "remarks: Geofeed" values as "geofeed:" attributes
- Do not validate that the URL is reachable (available) and do not validate the content

Is this enough to satisfy the draft requirements? Is it enough to be useful for the DB-WG?

Regards
Ed Shryane
RIPE NCC