[atlas] Survey results on Atlas open-sourcing

Morning everyone

On Thu, Jan 5, 2012 at 12:23 AM, Philip Homburg <philip.homburg at ripe.net> wrote:
> On 1/4/12 17:07 , Iñigo Ortiz de Urbina wrote:
>>
>> As the survey shows, and as Simon just stated, I do not think that
>> security through obscurity is the way to go, provided the nature of
>> this volunteering measurement platform. However, it is not all that
>> simple, IMHO.
>> I particularly support the idea of releasing the source code
>> gradually, even under temporary NDAs if necessary, in order to improve
>> the security of probe or controllers by getting the code audited by
>> more people.
>
>
> Doing stuff under NDA is of course something completely different.
>
>
>> Enhancing the system by introducing more features
>> (different traceroute algorithms and options) or polishing the
>> existing ones (IPv6 support, which is currently limited by the busybox
>> version probes are running atm, IIRC) is something possible and
>> desirable, if we dont forget that its Atlas itself what has to
>> improve.
>
>
> We are not limited by any code we already have. In particular, we are not
> saying: we cannot do this or that because it is not in busybox. The probes
> are out there and we want to make the most of them.
>

This is good to hear. I was meaning that according to the FAQ, there
seems to be something around IPv6 (not affecting ping6 or
traceroute6). See:

"
Q: I have an IPv6-only network. Will the probe work on it?
A: Although the probe itself is IPv6-ready in general, some of the
off-the-shelf software components on it are not (yet). We hope that
this will be resolved soon, but until then the probe needs IPv4 to
communicate with our infrastructure. The measurements themselves can
run on IPv6.
"
> So if you have any ideas on what kind of measurements are worth doing that
> we currently cannot do, please let us know, in particular, make sure that
> Vesna or Ann keep track of what you want. :-)
>

Sure, so far they both have been very kind and responsive to user feedback :-)

But, as Jens already jumped in, I want to support his comments on
adding DNS or HTTP checks. Sometimes ICMP cant be unfiltered, or the
user experience is degraded due to HTTP, DNS response times
themselves, and not the latency.