[RIPE NCC *Advisor* hat firmly on. Note this hat no longer bestows responsibility for the services under discussion] On 3.06.14 8:46 , Peter Koch wrote:
... As I said at the microphone in Warsaw, I think it would be a plus not only to maintain the old data, but also some way to visualize it, so some trends over the years can be looked up (literally, not only dug in the raw data) in comparison. That does not imply running an unmaintained or unmaintainable system indefinitely, neither does it postpone the shutdown date for said system. Getting the viz back in some "reasonable" time would be great.
Maintaining the old data available is easy and should be done. Continuing to visualise it will need resources out of a limited pool. It is up to the community to indicate relative priorities for the use of these resources. We use roadmaps http://roadmap.ripe.net/ to help with this. So I suggest to put this under "Requested" on the roadmap. Then we can discuss it in the context of other things we want to see.
The other point I want to submit "in writing" is that I am not convinced by the reasoning that led to giving up the two hour delay. The fact that "measurements are public" or "anybody could set up their own measurements" neglects the very value added by the (new) visualisation: not only is there an instant feedback channel, but that channel is _the_ well reputed source. In 1980s' words: the revolutionary army not only has a transmitter, but it has direct write access to the 20:00 main news. Doesn't give me sleepless nights, but I question the unilateral decision based on that fatalistic reasoning.
From a distance I see four possibilities in order of increasing implementation cost:
1) Do nothing and visualise data in real time. 2) Add a blanket 2h delay to the dnsmon visualisation affecting all users. 3) Add a 2h delay to the dnsmon visualisation to all users that are not logged in as a RIPE NCC member. 4) Add a delay to publication of any RIPE Atlas measurement result in some form. In my humble opinion option 4 is unrealistic because of the complexities involved. If the community wants that it will add a lot of pain to current Atlas users and, more importantly, draw a lot of resources away from adding useful capabilities to RIPE Atlas. Option 2 makes dnsmon much less useful for operational folk to follow a "situation" in real time. I have found this capability invaluable several times in the past to judge the extent and impact of service deteriorations. I would not want to miss it. Therefore the real choice is between 1 and 3. I would be OK with 3 if that makes people like Peter sleep better. We just have to realise that the authorised group is rather large and therefore this is just a deterrent, a fig leaf if you will. If we agree that option 3 is what we want, let us put it on the roadmap too. Daniel [still wearing a hat without responsibility for this service]