Hi, Yesterday, in the brewery, I understood from Henk that you guys are going to have a myasn meeting somewhere in the near future. I thought it might be usefull if I send in some ideas of what needs to be done/implemented. I'm also looking for a new contract right now and I would be quite willing to work on myasn again :) Either way I hope that my input helps. Cheers, Alexis Prio 1. - bugfixes/feature implementation (obvious) - proper authentication module (with logout option) - optimization/clean-up myasn-scan/myasn-send/myasn-admin move the functionality of these programs into respective RIPE::NCC::myASn::Scan RIPE::NCC::myASn::Send (this will untie lots of knots and make myasn much more extendable) - reimplement XML import with XML::DOM and use <registry name=".."> as DTD - enable retromatch (will be trivial after myasn-scan reimplemented as perl interface; retromatch is already in there but requires a rather resource inefficient invokation of myasn-scan) - handle notification mail bounces/errors with some inteligence - graphical (.png) summary on the start page Prio 2. - prefix independent alarms with complex (multi-part) regular expressions (this is one most important and powerfull feature that will make myasn usefull for much larger range of applications) - site global alarm groups with possibility to subscribe to them (martians system/default route) - visibility alarms - churn based alarms - snmp alarm notifications - pgp signing of notification messages (usefull?) Prio 3. - auto sync with IRR and LIR portal (for prefixes and as numbers) - self tuning alarms