<div dir="ltr"><div>Well, not really. Say, if geofeed: is accepted, that also sets the way how to store geolocation data in the RIPE Database. I mean, allowing geofeed: and then adding country:, city: attributes in inetnum would be inconsistent and confusing.</div><div><br></div><div>So it is much more than just an optional attribute. I do think discussion about externalizing data (that also used to be part of inetnum via the country: attribute back in the day) belongs here.<br></div><div><br></div><div>Cheers,</div><div>Agoston<br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Oct 7, 2020 at 4:20 PM Job Snijders <<a href="mailto:job@instituut.net">job@instituut.net</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">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>
</blockquote></div>