<html>
  <head>
    <meta content="text/html; charset=ISO-8859-1"
      http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    On 5/5/12 16:43 , Jérôme Benoit wrote:
    <blockquote
      cite="mid:20120505164343.3b3e2fc4@nemesis.grenouille.com"
      type="cite">
      <pre wrap="">On Sat, 05 May 2012 12:22:15 +0200
Philip Homburg <a class="moz-txt-link-rfc2396E" href="mailto:philip.homburg@ripe.net"><philip.homburg@ripe.net></a> wrote:

</pre>
      <blockquote type="cite">
        <pre wrap="">I don't know about SamKnows, but for RIPE Atlas, talks contain a lot
of details about how the system works. To the extent that there is a
well defined road map, we talk about it.
</pre>
      </blockquote>
      <pre wrap="">
I'm having hard time to find the roadmap and the talks on the RIPE Atlas
web site as a public user with no account. But I might have not
searched enough. Where are they ? 

</pre>
    </blockquote>
    There is not a single comprehensive road map. What is there, is just
    bits and pieces. Most of it was discussed during the most recent
    RIPE meeting. The talks by Robert and Daniel should be online. <br>
    <br>
    To list some things that have been mentioned:<br>
    <ul>
      <li>TTM shutdown, Atlas is expected to provide functionality
        similar (but not identical) to what TTM provides</li>
      <li>DNSMON gets moved to Atlas</li>
      <li>Roll out of Atlas Anchor boxes (regular PCs at well connected
        locations that can serve as the target of measurements and as a
        more powerful Atlas probe)<br>
      </li>
      <li>Measurements for IPv6 launch</li>
      <li>Better UDM interface</li>
      <li>UDM for all RIPE members (instead of just probe hosts and
        sponsors)<br>
      </li>
    </ul>
    <blockquote
      cite="mid:20120505164343.3b3e2fc4@nemesis.grenouille.com"
      type="cite">
      <pre wrap="">
</pre>
      <blockquote type="cite">
        <pre wrap="">As much as I like open source projects, I really don't see it working 
for the current Atlas system.
</pre>
      </blockquote>
      <pre wrap="">
It work very well, we do it since age but we took a very different
approach : 

The measurement agent is designed as a standalone component with that
requirement : 

* Must be portable, that mean all measurements must be implemented
  natively.   
* Datagram-based measurement are divided in four components
    - packets forge 
    - packets injection
    - packets capture
    - packets filter 
Each component work is mapped to a dedicated thread (an Lwt job more
precisely, which bring in a very nice way to manipulate packets in a
asynchronous fashion). </pre>
    </blockquote>
    Note that for Atlas, it has to work on an underpowered CPU without
    MMU and with 8 MB of memory. <br>
    <blockquote
      cite="mid:20120505164343.3b3e2fc4@nemesis.grenouille.com"
      type="cite">
      <pre wrap="">
* Other measurement can be mapped with a plugin dynamically loaded (the
  API is not stable yet)
* A syntax (that is not yet finished) permit to express what a
  measurement will do. The syntax is thought as a way to express
  what the software functionalities are and how each component
  interact with each other. I give a working example just to show
  the idea : </pre>
    </blockquote>
    <br>
    However, I think this would be a great area the community can work
    on. Plenty of people has expressed interest in something more
    general than what is currently implemented in Atlas.<br>
    <br>
    So if people can come up with a design that is both secure and can
    work on 8 MB probes, then maybe that can be used to create a common
    interface to the different measurement platforms.<br>
    <blockquote
      cite="mid:20120505164343.3b3e2fc4@nemesis.grenouille.com"
      type="cite">
      <pre wrap="">
</pre>
      <blockquote type="cite">
        <pre wrap="">Probe are just too fragile, the whole 
system is too complex.
</pre>
      </blockquote>
      <pre wrap="">


I fail to understand this argument. 
Every single piece of software is a complex system, that has never ever
be an argument to not opensource it. 
And for the fragility, probably a design issue of the probe (but I
can't known for sure, no source code to review). </pre>
    </blockquote>
    <br>
    Running an open source project is not a goal of the RIPE NCC. If
    that's supposed to be a goal then the members will have to ask for
    it through the appropriate channels. <br>
    <blockquote
      cite="mid:20120505164343.3b3e2fc4@nemesis.grenouille.com"
      type="cite">
      <pre wrap="">
</pre>
      <blockquote type="cite">
        <pre wrap=""> Does releasing the Atlas source benefit the
RIPE community? I don't know. Fortunately, that is not my decision to
make.
</pre>
      </blockquote>
      <pre wrap="">
RIPE call. I think RIPE have made a mistake by not going opensource
since the beginning. </pre>
    </blockquote>
    I guess opinions differ there.<br>
    <blockquote
      cite="mid:20120505164343.3b3e2fc4@nemesis.grenouille.com"
      type="cite"><br>
      <blockquote type="cite">
        <pre wrap="">If you have a dedicated team in an open
source project, then you should be able to duplicate our work. You
can always for feedback on any design, or ask how we do things.
</pre>
      </blockquote>
      <pre wrap="">
I do not know the list of active measurements an Atlas probe cover. 

</pre>
    </blockquote>
    At the moment, ping, traceroute, tdig (dns), httpget, sslgetcert.<br>
    <br>
    <br>
  </body>
</html>