[db-wg] cmd line asused and webasused

Hi Nigel,

I can assure you that the action the board gave, what Axel understood and what we are developing is perfectly aligned. "Merely provisioning an API into the webasused tool" is not what I said and definitely not what we're creating. 

Our goal is to cater to all needs that the membership has with regards to address space information and management. Some just want a simple web based interface that they can check without needing to download and run a local tool. Some have a need to integrate address space information into their local (IPAM) toolsets and workflows. But what all users have in common is the desire to have a more comprehensive information set than is currently available, such as an overview of the invalid assignments, as Nina pointed out. This is why we're taking an approach of using Registry data instead of the RIPE Database. 

To summarise, again, we will provide functionality for both web-based and stand-alone use. In the mean time, we will do everything we can to make sure the current asused functionality is not disrupted.

Kind regards,

Alex


On 17 Jan 2012, at 17:53, Nigel Titley wrote:

> Nick, Alex et al
> 
> At the Board meeting on the 8th December the board gave Axel an action "to reinstate/redevelop the stand-alone version of the RIPE NCC ASused tool"
> 
> I doubt that this action would be satisfied merely by the provision of an API into the webasused tool.
> 
> Alex, you may like to check this with Axel. It is possible that it was misunderstood by him, but it is very clearly minuted.
> 
> And I'd agree with Nick that lack of platform portability is one of the few brickbats that cannot be aimed at  perl.
> 
> Nigel
> 
> -----Original Message-----
> From: db-wg-bounces at ripe.net [mailto:db-wg-bounces at ripe.net] On Behalf Of Nick Hilliard
> Sent: 17 January 2012 16:22
> To: Alex Band
> Cc: db-wg at ripe.net
> Subject: Re: [db-wg] cmd line asused and webasused
> 
> Hi Alex,
> 
> On 17/01/2012 14:25, Alex Band wrote:
>> Thanks for bringing up asused. It is a tool that was written and 
>> maintained by the RIPE NCC many years ago and later handed to the open 
>> source community, where it can be found in packages such as Debian:
>> http://packages.qa.debian.org/a/asused.html
>> 
>> This, along with the fact that is was written in a very platform 
>> specific manner, is the reason why the tool is no longer actively 
>> developed and supported by the RIPE NCC. On the other hand, we have 
>> always kept the existence of asused in mind, which means that we would 
>> never intentionally change anything to our (whois) configuration that 
>> would break asused. I want to assure you that we'll try to fix any 
>> issue that you may have on a best effort basis.
> 
> Problem is, we don't yet have a replacement command-line tool for dealing with quick-n-easy LIR resource usage summarisation.  This has meant that the people who depended on this tool were left hanging for the last 8 years, because the code slowly rotted as interfaces subtly changed over time.  This is not a criticism of changing the DB interface or anything, btw - progress needs to happen.
> 
> In terms of being platform specific, it was limited to any platform which could run perl - perhaps with minor modifications.  There are lots of complaints that people make about perl, (some legitimate) but platform portability is not one of them.
> 
> OTOH, webasused can be very slow.  E.g. I submitted a request for a LIR at
> 15:28 GMT today, and got a reply at 15:39.  This makes it unusable for a typical workflow process (e.g. run asused, check output against internal records, submit a couple of updates, run asused again, check again, repeat until satisfied).
> 
> The web version is also unauthenticated which means that it's open to third parties submitting requests for arbitrary LIRs.  And it doesn't support ipv6, which means that it's still difficult to do resource reconciliation for v6 assignments.
> 
> I'll admit that not everyone likes command line tools, but for those of us who continue to us asused, it's a real pity that it wasn't maintained and further developed to support ipv6.
> 
> Nick
> 
>