[dns-wg] WG comment on DNSMON changes

[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]