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

Hi,

I would just like to remind everyone that the issue that what the draft RFC
is attempting to solve is purely a unified way for resource holders to say
where the addresses are located.
That is it, it is not attempting to actually check where the addresses are,
just that it is actually the resource holder that is giving you this
information.

Additionally, the only thing being discussed here which is relevant is
"should we have a geofeed attribute that accepts a URL, or just a remarks
attribute with a value prefixed with Geofeed?"

"remarks: Geofeed https://example.com/geofeed.csv"
vs
"geofeed: https://example.com/geofeed.csv"

That is it, other things than that are not relevant to the db-wg, and
should go on other relevant mailing lists at the IETF or whoever is
coordinating this.

- Cynthia


On Wed, Oct 7, 2020 at 9:06 PM Matthias Merkel via db-wg <db-wg at ripe.net>
wrote:

> A RIPE hosted geolocation feed may indeed provide some advantages, however
> in my opinion this should instead be based on data supplied by the LIR (or
> end user for PI assignments), as it would be using an external geolocation
> feed, instead of automatically via Atlas. There are various reasons for why
> a measurement approach may return bad data (i.e. routing inconsistencies).
>
>
>
> *Matthias Merkel*
>
> Executive Vice President
>
> Staclar, Inc.
>
> +1-628-213-1141 | +49 15678 585608
>
> matthias.merkel at staclar.com
>
> staclar.com
>
> Munich, Germany
>
> [image: linkedin] <https://www.linkedin.com/in/matthias-merkel/>
>
>
>
>
>
> *From:* db-wg <db-wg-bounces at ripe.net> *On Behalf Of *Elad Cohen via db-wg
> *Sent:* Wednesday, 7 October 2020 17:01
> *To:* Horváth Ágoston János <horvath.agoston at gmail.com>; Job Snijders <
> job at instituut.net>
> *Cc:* db-wg at ripe.net >> Database WG <db-wg at ripe.net>
> *Subject:* Re: [db-wg] proposal: new attribute 'geofeed:'
>
>
>
> +1
>
>
>
> and I would like to suggest an adjustment:
>
>
>
> Not everyone will add the "geofeed" value and the geolocations in the csv
> will not validated by a 3rd party and may also be not up to date.
>
>
>
> I suggest to make the csv creation (of each INETNUM object) automatic and
> hosted by RIPE NCC, RIPE NCC can use all the current ATLAS Probes in order
> to check the physical location of each ip (using latencies from many probes
> to each ip, and using latencies from many probes to each router in the
> routing path to each ip, other ICMP queries can be used as well to query
> the routers in the routing path for physical information such as timezone
> as additional measures, etc). Algorithem will be efficient meaning at first
> only small number of probes will check each ip and then more probes
> physically near the first probe with the smallest latency.
>
>
>
> Kind Regards,
>
> Elad
> ------------------------------
>
> *From:* db-wg <db-wg-bounces at ripe.net> on behalf of Job Snijders via
> db-wg <db-wg at ripe.net>
> *Sent:* Wednesday, October 7, 2020 5:19 PM
> *To:* Horváth Ágoston János <horvath.agoston at gmail.com>
> *Cc:* db-wg at ripe.net >> Database WG <db-wg at ripe.net>
> *Subject:* Re: [db-wg] proposal: new attribute 'geofeed:'
>
>
>
> On Wed, Oct 07, 2020 at 03:43:33PM +0200, Horváth Ágoston János wrote:
> > An interesting proposal, but merging an external data set with RIPE
> > Database arises some questions:
> >
> > - RIPE Database is set up to contain hierarchical data already. With this
> > proposal, we would take some of this data outside the database in a
> manner
> > that does not guarantee consistency with the database itself.
>
> I don't think that is what is happening, this is more analogous to
> "abuse-mailbox:". The value contains an email address (which is an
> entrypoint outside the database, and interacting with the entrypoint is
> outside the scope of this working group).
>
> The "geofeed:" attribute is a pointer to elsewhere, and what a data
> consumer wants to do with that information is up to them.
>
> Kind regards,
>
> Job
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </ripe/mail/archives/db-wg/attachments/20201007/21329cd6/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.png
Type: image/png
Size: 177 bytes
Desc: not available
URL: </ripe/mail/archives/db-wg/attachments/20201007/21329cd6/attachment.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image002.png
Type: image/png
Size: 170 bytes
Desc: not available
URL: </ripe/mail/archives/db-wg/attachments/20201007/21329cd6/attachment-0001.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image006.png
Type: image/png
Size: 300 bytes
Desc: not available
URL: </ripe/mail/archives/db-wg/attachments/20201007/21329cd6/attachment-0002.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image007.png
Type: image/png
Size: 479 bytes
Desc: not available
URL: </ripe/mail/archives/db-wg/attachments/20201007/21329cd6/attachment-0003.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image008.png
Type: image/png
Size: 503 bytes
Desc: not available
URL: </ripe/mail/archives/db-wg/attachments/20201007/21329cd6/attachment-0004.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image009.png
Type: image/png
Size: 3222 bytes
Desc: not available
URL: </ripe/mail/archives/db-wg/attachments/20201007/21329cd6/attachment-0005.png>