<div dir="auto">Hi Denis,<div dir="auto"><br></div><div dir="auto">Apologies if this email comes off as rude or harsh, that isn't my intention, but I am not quite sure how else to phrase it.<br><div dir="auto"><br></div><div dir="auto">So when I say things like this, it's not because of cost or anything like that.</div><div dir="auto">I say it because I don't think validating the CSV is something that would be a benefit.</div><div dir="auto"><br></div><div dir="auto">Abuse contacts are validated and required (except for some legacy resources iirc) because they are important in order to report abuse.</div><div dir="auto"><br></div><div dir="auto">Having a geofeed service is not a requirement, and additionally I would think that the data consumer would almost always be software dedicated to this.</div><div dir="auto">If so, then that software can easily validate the CSV data itself.</div><div dir="auto"><br></div><div dir="auto">I see abuse contacts and geofeed as very different things considering those 2 things.</div><div dir="auto"><br></div><div dir="auto">-Cynthia</div></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Apr 7, 2021, 00:45 denis walker <<a href="mailto:ripedenis@gmail.com">ripedenis@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi guys<br>
<br>
I've changed the subject as it goes a bit off topic and becomes more<br>
general and reaches out beyond just the DB-WG. I've been going to say<br>
this for a while but never got round to it until now. Apologies for<br>
saying it in response to your email Job but it's not directed at you.<br>
<br>
There are two phrases that frustrate me every time I see them used:<br>
"The RIPE NCC is not the 'xyz' police"<br>
"It's not the job of the RIPE NCC to do 'abc'"<br>
<br>
These are just dramatised ways of saying no to something. But the<br>
drama doesn't really add anything. No one is expecting the RIPE NCC to<br>
investigate any crimes or arrest anyone. They are not the 'geoip<br>
police', the 'internet police', the 'abuse police'. So what are they?<br>
I think everyone would agree that what the RIPE NCC does today is not<br>
the same as they did when they first started in business. So the job<br>
that they do has changed. Their role or mandate has grown, expanded,<br>
contracted, moved sideways, diversified, etc. Every time they started<br>
to do something different or new, it could have been said (and maybe<br>
was said) that it was not their job to do that. But they are doing it<br>
now anyway. So I would rather turn these infamous statements round and<br>
be positive instead of negative. Let's stop saying what it's not their<br>
job to do and ask if it is, or should/could it be, their job to do<br>
something helpful or beneficial.<br>
<br>
The internet technical infrastructure is like a whole ecosystem now.<br>
Lots of different elements all working together and managed or<br>
controlled by large numbers of organisations. If anyone wants to have<br>
a good life in this cyber world, all parts of this ecosystem need to<br>
be operating well. Many of these elements have no checks or<br>
monitoring. They run on trust. Trust is hard to build and easy to<br>
lose. Once people lose trust in one element they start to call it a<br>
swamp, say it's inaccurate, useless, needs to be replaced. These<br>
comments have often been made about the RIPE Database as a whole,<br>
often by people partly responsible for it's content. It's also been<br>
said about parts of the content like abuse contacts. It could end up<br>
being said about geofeed data.<br>
<br>
One of the reasons people use to justify these infamous statements is<br>
the cost or complexity of doing something. They think to do checks<br>
needs FTEs sitting behind desks doing laborious tasks. That costs<br>
money for the members. They forget this is the 21st century. We have<br>
learned now how to use computers to do these tasks for us. Abuse<br>
contact checking is a good example. Every proposal to do anything in<br>
this area is repeatedly hit with these infamous statements and more.<br>
Perhaps because the technical checks now being done are done the wrong<br>
way. If an email address fails the checks it triggers manual<br>
intervention requiring an FTE to schedule an ARC with the resource<br>
holder and follow up discussions. This should be fully automated. If a<br>
monthly check fails, software should send an email to the registered<br>
contact for the resource holder. If n monthly checks fail the<br>
ORGANISATION object in the RIPE Database should be tagged as having an<br>
invalid abuse contact. That information should be available for anyone<br>
to see. Public disclosure can be the penalty for failing to handle<br>
abuse. People can then make informed decisions.<br>
<br>
How does this affect geofeed? The same principles apply here. What we<br>
have now is a handful of companies providing geolocation data. I am<br>
sure they put a lot of effort into ensuring their data is accurate.<br>
This geofeed attribute will delegate this information process out to<br>
thousands of organisations. Some of these will put a lot of effort<br>
into ensuring their data is valid and accurate. Some may put less<br>
effort in, especially over time. If a proportion of this data starts<br>
to degrade over time, is shown to be inaccurate or syntactically<br>
invalid, trust in the whole system dies. If checks and tests can be<br>
done to validate the data in any way it may help to keep it up to date<br>
and accurate. If each RIR maintains a list of geofeed urls in a file<br>
on the FTP site, each RIR can check availability of those urls each<br>
month for all the RIRs lists. I don't know if checks from 5 locations<br>
is enough. Maybe a third party system can be used for the 'is it up'<br>
check? Any repeated failures can be notified to the resource holders'<br>
contact. If each RIR downloads the files for their region they can<br>
check the syntax, check for conflicting data in multiple files within<br>
a hierarchy, etc. Any failures can be reported to the contact. All of<br>
this can be automated. If any repeated errors are not fixed the<br>
geofeed data in the RIPE Database can again be tagged as invalid or<br>
suspect. When anyone accesses this data it comes with a red flag. It<br>
is up to them if they will trust any of that data file.<br>
<br>
For both abuse contacts and geofeed, a system can be set up for<br>
(trusted) users to report problems. Maybe abuse contacts that are<br>
valid but never resolve any reported issues. Or geofeed data that is<br>
known to be inaccurate. By adding appropriate tags to the meta data in<br>
the RIPE Database which can be publicly viewed this becomes a<br>
reputational system. Overall it would improve the quality of data<br>
available in or through the RIPE Database, which improves the value of<br>
the services. There may be other elements in the database that could<br>
benefit from this type of tagging and reporting.<br>
<br>
I see the RIPE NCC as being in a good position to do these type of<br>
checks and tests. It would not be the RIPE Database software doing the<br>
checks, but an additional RIPE NCC service. Minimal costs with fully<br>
automated checks can give added benefits. I think it is their job to<br>
do this for the good of the internet.<br>
<br>
cheers<br>
denis<br>
co-chair DB-WG<br>
<br>
<br>
On Tue, 6 Apr 2021 at 19:50, Job Snijders <<a href="mailto:job@sobornost.net" target="_blank" rel="noreferrer">job@sobornost.net</a>> wrote:<br>
><br>
> Thanks for the extensive note Denis, thanks Cynthia for being<br>
> first-responder. I wanted to jump in on a specific subthread.<br>
><br>
> On Tue, Apr 06, 2021 at 06:38:29PM +0200, Cynthia Revström via db-wg wrote:<br>
> > > Questions:<br>
> ><br>
> > > -Should the database software do any checks on the<br>
> > > existence/reachability of the url as part of the update with an error<br>
> > > if the check fails?<br>
> ><br>
> > I would say yes as this is not a new concept to the DB as I believe<br>
> > this is already done with domain objects.<br>
><br>
> I disagree on this one point, what is the RIPE DB supposed to do when it<br>
> discovers one state or another? Should the URIs be probed from many<br>
> vantage points to compare? Once you try to monitor if something is up or<br>
> down it can quickly become complicated.<br>
><br>
> The content the 'geofeed:' attribute value references to something<br>
> outside the RIPE DB, this means the RIPE DB software should not be<br>
> crawling it.<br>
><br>
> All RIPE NCC's DB software needs to check is whether the string's syntax<br>
> conforms to the HTTPS URI scheme.<br>
><br>
> > > -Should the RIPE NCC do any periodic repeat checks on the continued<br>
> > > existence/reachability of the url?<br>
> ><br>
> > I would say that checking once a month or so could be fine, as long as<br>
> > it just results in a just a nudge email.<br>
> > Like don't enforce it, but nudge people if it is down.<br>
><br>
> It seems an unnecessary burden for RIPE NCC's business to check whether<br>
> a given website is up or down. What is such nudging supposed to<br>
> accomplish? It might end up being busy work if done by an individual RIR.<br>
><br>
> > > -Should the RIPE NCC do any periodic checks on the content structure<br>
> > > of the csv file referenced by the url?<br>
> ><br>
> > I don't have a strong opinion either way here but I feel like that is<br>
> > not really something the NCC is responsible for checking.<br>
> > But if the NCC should check then my comments about the repeat<br>
> > reachability checks above apply here too.<br>
><br>
> The RIPE NCC should not check random URIs, they are not the GeoIP police ;-)<br>
><br>
> Kind regards,<br>
><br>
> Job<br>
</blockquote></div>