[db-wg] proposal: new attribute 'geofeed:'

+1

Matthias Merkel
Executive Vice President
Staclar, Inc.
[cid:image001.png at 01D69CB4.4D061960]
+1-628-213-1141 | +49 15678 585608
[cid:image002.png at 01D69CB4.4D061960]
matthias.merkel at staclar.com<mailto:matthias.merkel at staclar.com>
[cid:image007.png at 01D69CB4.4D0EA4E0]
staclar.com<https://staclar.com/>
[cid:image008.png at 01D69CB4.4D0EA4E0]
Munich, Germany
[cid:image009.png at 01D69CB4.4D0EA4E0]
[linkedin]<https://www.linkedin.com/in/matthias-merkel/>


From: db-wg <db-wg-bounces at ripe.net> On Behalf Of Cynthia Revström via db-wg
Sent: Wednesday, 7 October 2020 14:14
To: Job Snijders <job at instituut.net>
Cc: DB-WG <db-wg at ripe.net>
Subject: Re: [db-wg] proposal: new attribute 'geofeed:'

+1 this is a much more reasonable solution than remarks imo

- Cynthia

On Tue, 6 Oct 2020, 18:29 Job Snijders via db-wg, <db-wg at ripe.net<mailto:db-wg at ripe.net>> wrote:
Dear DB-WG,

Some colleagues are working to address the never-ending-story of 'where
the heck are IPs geographically?'. This problem space has been brought
up numerous times in the Database Working Group, but we never managed to
solve it. As with all compsci problems adding a layer of indirection can
help ;-)

This current draft suggests overloading the RPSL 'remarks:' field with a
structured attribute value, however I suspect we would do ourselves a
disservice to overload a 'remarks:' field.

Instead it would be better to add a 'geofeed:' attribute to the RPSL
inetnum/inetnum6 class dictionary, which as value contains a URL with
http or https scheme.

The draft: https://tools.ietf.org/html/draft-ymbk-opsawg-finding-geofeeds

The value of the attribute could be validated using something like
"org.apache.commons.validator.UrlValidator", the attribute would look
like this, only valid in the inetnum/inet6num:

    "geofeed:   [optional]   [single]     [ ]"

Example object:

    inetnum:        192.0.2.0 - 192.0.2.255
    netname:        EXAMPLE
    country:        NL
    geofeed:        https://example.com/geofeed.csv
    ... snip ...
    source:         RIPE

What do others think?

Kind regards,

Job

ps. In IRRd v4.2 support for the 'geofeed:' attribute will be added
https://github.com/irrdnet/irrd/issues/396
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </ripe/mail/archives/db-wg/attachments/20201007/3d628991/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.png
Type: image/png
Size: 177 bytes
Desc: image001.png
URL: </ripe/mail/archives/db-wg/attachments/20201007/3d628991/attachment.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image002.png
Type: image/png
Size: 170 bytes
Desc: image002.png
URL: </ripe/mail/archives/db-wg/attachments/20201007/3d628991/attachment-0001.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image006.png
Type: image/png
Size: 300 bytes
Desc: image006.png
URL: </ripe/mail/archives/db-wg/attachments/20201007/3d628991/attachment-0002.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image007.png
Type: image/png
Size: 479 bytes
Desc: image007.png
URL: </ripe/mail/archives/db-wg/attachments/20201007/3d628991/attachment-0003.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image008.png
Type: image/png
Size: 503 bytes
Desc: image008.png
URL: </ripe/mail/archives/db-wg/attachments/20201007/3d628991/attachment-0004.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image009.png
Type: image/png
Size: 3223 bytes
Desc: image009.png
URL: </ripe/mail/archives/db-wg/attachments/20201007/3d628991/attachment-0005.png>