+1 turning over historical to DNS-OARC.
From .ca point of view, we don't need "backwards compatibility" in the new DNSMON tool, which is pretty good BTW. Before DNSMON was just a monitoring tool, now it's a platform for innovation :-)
Jack
-----Original Message----- From: dns-wg-bounces@ripe.net [mailto:dns-wg-bounces@ripe.net] On Behalf Of Joe Abley Sent: June-04-14 12:33 PM To: Jim Reid Cc: RIPE DNS WG Subject: Re: [dns-wg] DNSMON changes
On 4 Jun 2014, at 12:17, Jim Reid <jim@rfc1035.com> wrote:
The points made by Peter and Daniel are worth further discussion and I encourage you all to do that. On one hand, there could be some benefit in providing "backwards compatibility" for visualising old data. OTOH, this may put an unreasonable burden on the NCC by creating an open-ended commitment to support legacy cruft and result in users who can't/won't migrate to the current platform. It would be good for WG members to express their opinions about this.
On that particular point, the important thing is for the data behind the old dnsmon to be available, together with a clear description of how it was collected and how it is stored (file formats, directory structure, filenames, etc).
I don't think it's necessary for the NCC to burn devops cycles on making visualisations of the old data available, either in exact old-DNSMON form or in any other form. If anybody really needs a visualisation of existing data, they can make their own so long as the data is available.
I don't think there's a practical difference between the RIPE NCC making data available directly or providing it to DNS-OARC (say) for storage and visualisation. Either way would work for me.
My personal view is somewhere inbetween: provide some way of visualising the old data if that can be done with minimal effort/resources from the NCC on a best efforts, unsupported basis. If that facility later dies, it dies and that's the end of the matter. YMMV.
I would like to see a commitment to the data being made available indefinitely. I don't like throwing away historical data.
Joe