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 at 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 at vegoda.org *Please do not send html*
NIC: GUY-RIPE \ guy at cryptography.org.uk *attachments*
Unix, Linux Hobbyist \ +44(0)20 7961 8318 (work)
www.thenakedfrenchman.com \ +44(0)958 469 532 (cell)

The RIPE NCC uses cookies. Some of these cookies may have been set already. More information about our cookies can be found in our privacypolicy. You can accept our cookies either by clicking here or by continuing to use the site.