G : We should focus on clearing the TODO List, then go to testing phase,
    since the end is nearing... ( I finish on august, 3 )

To be done :
    Catch a more precise exception thant Exception at line 108 in vifibnet.py
    ( UPnP forwarding )

    Upgrade the logging function in order to be able to log message like
    "Refreshing peers DB ... done", or add log messages to specify that an
    action advertised by a previous log message has been completed

    use the server as a bootstrap node -> switch peer discovery to be done
    by vifibnet directly ?

    Use an algorithm to choose which connections to keep and/or establish
    instead of pure randomness

    Find a name for the project : the projet is ( or should be ) independant
    from vifib, openvpn, babel, and so should the name; btw we aim to build a
    distributed, scalable, resilient VPN.... ( if it helps with the name )

    Replace comments at the beginning of functions with docstrings & give all
    fn docstrings

    In peers DB, flag the dead peers so we only choose them if necessary and we
    can remove them if we have enought peers

    Use a timeout for the server peersDB so we can flag unreachable peers and
    remove the peers whose certificate is no longer valid

    Specify a lease duration in ForwardViaUPnP

    Handle LAN internally in order not to have catastrophic results ....
    ( avahi could be used )

    When we count the number of routes througt an interface, we should filter on
    the prefix size and the subnet

To be discussed:
    U : Babel seems to be very long to establish the routes : maybe we should
        tell him thant we are not on a wired network but on a mobile network ?
    G : babel establish routes quickly enough i'd say. There are two new
        options : hello and wireless, for hello_interval and treating all
        interfaces as wireless. However, treating an interface as wireless
        doesn't lessen the hello_interval, it only changes how babel estimates
        quality link, and cost.
    U : from babel web page : "When the Babel daemon detects a wired network,
        it will use a larger interval between hellos".
        Moreover, it seems that the wireless option only means
        "hostile environment" which seems best for a resilient network.
        30 sec of hello interval seams also too much. The default value for
        babel is 4 sec (from babel man page).
        According to raphael's stats on the nexedi's server downtime,
        45% of the problems dont last more than 2 minutes, 55% no more than
        3 minutes If it takes 2 min to detect a dead connection, then we wont be
        solving many problems with our overlay network
    G : ok, so babel hello-interval should be set to a lower value,
        we should do some tests to pinpoint the best compromise between
        speed and bandwith usage.
        Btw, is there a doc ( pdf, image, file ) resuming Raphael's stats
        on nexedi's server downtime ? it could be useful for the internship
        rapport

    U : Why are --ip and internal-port mutually exclusive ?
        Currently upnp only forward via UDP. Should he also forward via TCP ?
        Why dont we only use UDP ?
        No error should be raised when no upnp is detected : we should allow
        machines having public IP to do an automatic configuration using the
        discovery by an other peer
    G : Actually, i was wrong, --ip and internal-port are no longer exclusive
        Julien said udp might not be used by some people because of
        restrictions imposed by the ISP ( FAI in french ), so we should
        allow both, and act according to the options specifying which servers
        to start (upd, tcp-server)

    G : I think the number of route going through an interface should be a
        Connection attribute, not a dict in tunnelManager
    U : Yes, it was planned, just wait for me to finish implementing it

    U :  '--up', 'ovpn-server %s/%u' % (server_ip, len(network)) in plib.py
        if you use len(network), this means that all our network is on the 
        same LAN and that the interface of the server is connected to it
        wich means that any packet should be routed to this interface
        an interface should only advertise the /64 (or less) which has been 
        attributed to it