Guys I don't see the issue of what, if anything, should be validated as a show stopper for introducing the "geofeed:" attribute. This is my idea of utilising the RIRs to improve the value of services with increased validation. That's why I changed the subject line and started it as a different thread. We can come back to this later. Apologies for taking you down a side road, but at least I got some initial feelings from you on this more general issue.
cheers denis co-chair DB-WG On Thu, 8 Apr 2021 at 00:28, George Michaelson via db-wg <[email protected]> wrote: > > The Geofeed: field is a URL. > > It points to a resource. > > The semantic content of the resource should not be checked, what > matters is that the URL is not a 404 at the time of publication. > > if you want to check it isn't a 404 after that, its like Lame checks: > good to do, not strictly essential in the role of Whois/RPSL. > > if you want to check the semantic intent of the .csv geo data, thats not > db-wb. > > This work is important. it substantially improves the STEERAGE to find > the delegates assertions about geo for their INR. This is sufficiently > high value in itself its worth doing. Checking the integrity of what > they say goes beyond the role of a steerage/directory function. > > (my opinion) > > cheers > > -G > > On Thu, Apr 8, 2021 at 8:19 AM Cynthia Revström via db-wg > <[email protected]> wrote: > > > > Hi, > > > > I just wanted to clarify my stance on validation a bit more. > > > > I am totally against trying to validate the data itself, that is not > > what the NCC is supposed to do. > > Validating the format of the CSV might be okay but honestly anything > > beyond validating that it is not a 404 not found is a bit too much in > > my opinion. > > > > I also agree with Leo's points with regards to fixing the data, I > > believe that the data publishers have a pretty strong incentive to > > have the data be accurate. > > And as Leo also mentions, the tech-c and/or admin-c contacts are also > > published so finding a reporting mechanism for issues would not be > > very difficult. > > > > And with regards to misformatted data, yeah I would probably just > > ignore that entry if I was writing a parser and log the error and > > report it to an engineer who can then forward it to the admin contact > > if they determine it to be a real issue. > > > > In order to not infinitely delay this, I feel like while it shouldn't > > be rushed, I am not sure how realistic this issue would be and how > > much harm it would cause to anyone. > > > > Also, changing how much validation is done could be changed in the > > future if it is shown to be an actual real world problem. > > > > -Cynthia > > > > On Wed, Apr 7, 2021 at 10:58 PM Leo Vegoda <[email protected]> wrote: > > > > > > Hi Denis, > > > > > > This message is in response to several in the discussion . > > > > > > In brief: I have seen network operators distraught because their > > > network was misclassified as being in the wrong geography for the > > > services their customers needed to access and they had no way to fix > > > that situation. I feel that publishing geofeed data in the RIPE > > > Database would be a good thing to do as it helps network operators > > > share data in a structured way and should reduce the overall amount of > > > pain from misclassified networks. > > > > > > I personally would like to see an agreement on your draft problem > > > statement and some feedback from the RIPE NCC before focusing on some > > > of the more detailed questions you raised. > > > > > > I also agree with you that accurate and reliable data is important. But... > > > > > > On Wed, Apr 7, 2021 at 7:19 AM denis walker via db-wg <[email protected]> > > > wrote: > > > > > > [...] > > > > > > > You say most consumers of this geofeed data > > > > will be software capable of validating the csv file. What will this > > > > software do when it finds invalid data? Just ignore it? Will this > > > > software know who to report data errors to? Will it have any means to > > > > follow up on reported errors? > > > > > > I would have thought that anyone implementing a parser for this data > > > would also be able to query the database for a tech-c and report > > > validation failures. Based on my previous interactions with the > > > network operators who have suffered misclassification, I am confident > > > that there is a strong incentive for networks to publish well > > > formatted accurate data and to fix any errors quickly. > > > > > > That said, there are many possible ways to reduce the risk of badly > > > formatted data. For instance, the RIPE NCC could offer a tool to > > > create the relevant files to be published through the LIR Portal or as > > > a standalone tool. This is why I'd like to see feedback from the RIPE > > > NCC ahead of an implementation discussion. > > > > > > > Services like geofeed are good ideas. But if the data quality or > > > > accessibility deteriorates over time it becomes useless to misleading. > > > > That is why I believe centralised validating, testing and reporting > > > > are helpful. I think the RIRs are well positioned for doing these > > > > tasks and should do more of them. > > > > > > I agree with you that defining what data means and keeping it accurate > > > is important. But in the case of geo data, could the RIPE NCC validate > > > the content as well as the data structures? I'd have thought that the > > > publishers and the users of the data would be in the best position to > > > do that. Am I wrong? > > > > > > Kind regards, > > > > > > Leo > > >
