<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
<style type="text/css" style="display:none;"> P {margin-top:0;margin-bottom:0;} </style>
</head>
<body dir="ltr">
<div style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
+1</div>
<div style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
<br>
</div>
<div style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
and I would like to suggest an adjustment:</div>
<div style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
<br>
</div>
<div style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
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.</div>
<div style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
<br>
</div>
<div style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
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.<br>
</div>
<div style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
<br>
</div>
<div style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
Kind Regards,</div>
<div style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
Elad<br>
</div>
<div id="appendonsend"></div>
<hr style="display:inline-block;width:98%" tabindex="-1">
<div id="divRplyFwdMsg" dir="ltr"><font face="Calibri, sans-serif" style="font-size:11pt" color="#000000"><b>From:</b> db-wg <db-wg-bounces@ripe.net> on behalf of Job Snijders via db-wg <db-wg@ripe.net><br>
<b>Sent:</b> Wednesday, October 7, 2020 5:19 PM<br>
<b>To:</b> Horv�th �goston J�nos <horvath.agoston@gmail.com><br>
<b>Cc:</b> db-wg@ripe.net >> Database WG <db-wg@ripe.net><br>
<b>Subject:</b> Re: [db-wg] proposal: new attribute 'geofeed:'</font>
<div> </div>
</div>
<div class="BodyFragment"><font size="2"><span style="font-size:11pt;">
<div class="PlainText">On Wed, Oct 07, 2020 at 03:43:33PM +0200, Horv�th �goston J�nos wrote:<br>
> An interesting proposal, but merging an external data set with RIPE<br>
> Database arises some questions:<br>
> <br>
> - RIPE Database is set up to contain hierarchical data already. With this<br>
> proposal, we would take some of this data outside the database in a manner<br>
> that does not guarantee consistency with the database itself. <br>
<br>
I don't think that is what is happening, this is more analogous to<br>
"abuse-mailbox:". The value contains an email address (which is an<br>
entrypoint outside the database, and interacting with the entrypoint is<br>
outside the scope of this working group).<br>
<br>
The "geofeed:" attribute is a pointer to elsewhere, and what a data<br>
consumer wants to do with that information is up to them.<br>
<br>
Kind regards,<br>
<br>
Job<br>
<br>
</div>
</span></font></div>
</body>
</html>