These are my $0.02 on the IMPT specs:

General functionality:

IPMT should provide the LIRHostmasters with list, create, update, and delete access to information regarding their LIR's IPV4 allocations.

I think that data should be stored either in a relational database back end or a CVS flat plaintext file, both of which are accessible to the DBI.

These actions must be undoable where necessary.

I think that the software should keep a change log for every action performed, recording the user that performed it, the time stamp and a complete description of what change was actioned. This is so that roll back can take place, ie undoable.

Basic validity checks will be performed on all input.

We can't add 275.441.45.2/-33 so we better make sure we don't. Equally, having added 10.0.0.0/24 once, adding it again would be a bad thing. Check for these conditions specifically. Can anyone else think of any others to check for?

IPMT should provide the LIRHostmasters with list, create, update, and delete access to information regarding their LIR's IPV4 assignments. These actions must be undoable where necessary.

Ditto.

Basic validity checks will be performed on all input.

I'd add that with assignments, we should check not to exceed the assignment window as well.

IPMT should allow the LIRHostmasters to receive requests for IPV4 assignments from the customers of their LIR and allow them to process them.

I think an online set of forms that can be used in the majority of web browsers would be the best way to approach this. We will need to define and refine the data structures observable to the hostmaster. By this I mean, will he see a range divided up into free space and used space? Will he see pools inside ranges, pigeonholing space for infrastructure, colo, customer dialup etc. Once we have a clearer picture of this, we can go and dicuss an interface, but we need to know what the interface is for before we can design it. I would say that I think that JavaScript is a good idea for saving state, sanitizing input, dredging through entries and make the interface pretty. We will have to be careful as lots of nasty MS extensions are unavailable to other browers. We don't need anything overwhelmingly complex, we do need something that Netscape, Konqueror, Oprah etc can use.

IPMT should allow LIRHostmasters to send well-formatted email requests for new IPv4 assignments to the RIPE NCC and allow the LIRHostmasters to receive and process responses from the RIPE NCC.

We need to define just how much we can automatize sending an receiving emails. I imagine sending; a lot since RIPE NCC already provide robots for quite a lot of stuff already. Receiving emails and parsing human language is beyond that scope of _my_ perl skills, so if anybody is up for the challenge, by all means. I think though, that interpreting what the hostmaster posted back to you is going to be about the level of searching with a reg exp for a ticket number and then flagging the attention the hostmaster to deal with it.

IPMT should allow LIRHostmasters to send well-formatted email requests for new IPv4 allocations to the RIPE NCC and allow the LIRHostmasters to receive and process responses from the RIPE NCC.

I think that using sendmail or exim to open up a mail and send the contents to a ripe recipient should be easy enough. We will need to decide how much automagic stuff should be done by the various scripts. Should the script say "Hey, Hostmaster, you're over 80%. Here, fill out this form and request some more - I'll even post it for you" or should it say "Hey, hostmaster, I noticed we were low on space, last Tuesday and I took the liberty of requesting some more for Frankfurt, and you can now use this new /18 which I just added".

User Interface:

LIRHostmasters should be able to conveniently access IPMT functions from a wide range of Desktop Operating Systems, possibly including non-modern, non-Unix-like ones. A GUI interface is the minimal acceptable convenience level.

Since it has to speak to UNIX and other operating systems (some of you might even be using BeOS) I think that a browser is the most sensible place for a GUI.

A less-convenient interface to IPMT for more complex functions and administration is acceptable.

But infact harder to write something that works on UNIX and Win32. (Although whoever will be running Perl on Windows will no doubt have his work cut out anyhow). A browser is normally more convenient for the user than an Xterm and I for one do not want to be playing around with ncurses. ######## A few other points: IP library? I think Manuels is probably fine. The one I wrote is also fine for IPv4 but I think that Manuel is way ahead of me on the IPv6 front. DBI? I would say its a good place to start. User authentication? I would say that any regular databse would be able to do it fairly easily itself, buit we have a problem with someone wanting to use a CSV file.

The RIPE NCC only accepts requests for new IPv4 Assignments and Allocations via email to hostmaster@ripe.net and replies only via email [4].

This should not present too much of a difficulty.

IPV4 Assignment requests must be in RIPE 141 format [5]. Requests for new IPV4 Allocations have no special format.

Again, if we are talking about 141s and such, the NCC have already built a robot for us a jury rig into the new project.

LIRHostmasters handle customer requests for Assignments via telephone, email and web pages.

Any sufficiently well defined interface / form, should make adding a customer assignment little work.

IPMT must have access to the RIPE DB [6] or a local mirror thereof.

Using whois and piping the results through a set of regular expressions has worked for me in the past. It is not fast, but it works. Please comment and help refine this into something people are queueing up to help develop! Thanks everyone who is taking an interest. ATB, Guy -- Guy Vegoda \ guy@vegoda.org *Please do not send html* NIC: GUY-RIPE \ guy@cryptography.org.uk *attachments* Unix, Linux Hobbyist \ +44(0)20 7961 8318 (work) www.thenakedfrenchman.com \ +44(0)958 469 532 (cell)