[guy@localhost: IPMT specen.]
- Date: Thu, 19 Apr 2001 11:48:29 +0100
Hi there all you internet people!
I hope your all well,
I emailed this to everyone yesterday and was dismayed
when nobody commented on it.
Only this morning did I notice that I mailed it to
lir-wg@localhost rather than
lir-wg@localhost by mistake )-:
Hmm. Please enjoy your reading this mail. Thaaaank
youuuuu.
So here is my considered and very close to final draft
of the top down specs for the IMPT program.
You are all invited to tear it to peaces in the
purpose of constructive whatsit.
I would ask, if you are going to point out a problem,
at least also point out a solution.
________________________________________________________________________
Questions:
1. Which platforms are we looking to support?
I think that UNIX platforms would be easier for
development, and would cover the needs of the
majority of users. Also, ala Perl.
A gui provides windows users with an opportunity
to use the sotware too.
The same could be achieved on a win32 platform
under visual basic, but this would strain the GNU
lisence considerable, as well as denying use by
the UNIX users amongst us.
Miscrosoft have a web platform and we could
theortically write the whole thing in ASP.
MS's web server is NOT free however, and ASP, in
my opinion is less open than Perl.
An apache web server is free, and I believe that
they even have a windows version. Perl exists for
windows. I don't recommend this setup, but I believe
that it's better than ASP under a MS web server.
Equally, the majority of people would find Perl
easy and familiar.
Many excellent, free, IP libraries already exist.
They are also exstensible.
2. What's up with this IPv6 thing?
Since, AFAICT, IPv6 still isn't _finished_
finished, let's leave room for it, but not
impliment it yet.
When the time comes, and it is polished and ready,
we can slot in IPv6 support.
> General functionality:
>
> IPMT should provide the LIRHostmasters with list, create, update, and
> delete access to information regarding their LIR's IPV4 allocations.
> These actions must be undoable where necessary.
> Basic validity checks will be performed on all input.
>
> 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.
> Basic validity checks will be performed on all input.
Questions:
1. How do we store this information?
How about a back end database capable of being
acccessed by the DBI for the following reasons:
a. If you don't want to run a database, the DBI can
be used with a CSV filei. (Beware multiple
users about data integrity).
b. SQL shouldn't change too much from one DBMS to
another, and the DBI code stays the same.
c. It's free (the DBI) and talks to free DBMS's
like mysql and postgreSQL.
2. In which case, how will data modifications be
achieved?
We're just talking 'bout plain old SQL here.
3. How will we make updates undoable?
a. So, you changed the wrong customer's address
by accident and now you need to change it
back, but you can't find the original scrap of
paper. How do you reverse the change?
We're are talking about keeping logs, here,
right?
It would be simple if every DBMS was the
same, but since we cannot rely on that, we
need a database independent solution.
I recommend a table containing this
information, accessible in the same way by the
DBI.
b. We can embed enough information in the tables
store a chronological history of what has
happened to a particular and restore previous
incarnations.
4. How will be make the software multi user proof?
I haven't figured this one out yet. There is a
really easy way with MySQL, but that doesn't scale
to other DBMS systems.
5. Which checks need be done?
I believe the following are crucial:
o IP Address Space ranges must not overlap each
other.
o IP ranges must be entered correctly, or else
give error messages.
o Non IP information, such as customer names and
addresses should be unique.
o IP addresses should not be on illegal bit
boundaries.
o Assignment windows should not be exceeded for
any given customer.
6. How should IP ranges be inserted?
By this I am asking about the mechanisms for
choosing how to assign out of one's allocation.
I recommend an auto-manual solution wherby the
computer is able to work out exactly which IP
ranges matching your criteria are free and assignable,
and allign them all nicely along the bit
boundaries.
The human can then choose out of a list which IP
range to assign. The advantages are that you don't
have to do too much math yourself, but neither are
you stuch when it comes to migrating existing
allocations into the program.
7. How much non IP info should be stored in the
database, such as customer address, names,
contact...?
My view is that enough should be stored to
be able to autogenerate an intenum object.
Remaining problems:
1. With regard to storing both allocation
information assignment information, perhaps also,
customer information: What kind of data structure
will we use?
What about people with multiple registries?
2. We still need to tackle the mutli user problem.
3. If assigning something would exceed the window, we
need to have some process. Autogenerate a 141?
Maybe. If we did, how do we tell the software that the
assignment has been approved? Have a toggle?
Perhaps, but this need furthere discussion.
> IPMT should allow the LIRHostmasters to receive requests for IPV4
> assignments from the customers of their LIR and allow them to process
> them.
Questions:
1. What does this mean? It is very general.
(I should have spotted this during the reqs stage
and primpted for more clarity. My bad.)
Does the IMPT program sit on the end of an email
address and parse 141 forms?
My belief is that IMPT needs to be simple.
By all means, have an inetnum autogenerator built
into the program as that's easy. As for "allowing
the LIRHostmasters to receive requests", I think
that this means "Not getting in the way".
All companies and organisations have their own
policies and protocols for dealing with customers.
We need an easy GUI for entering cust info and
making assignments.
Automise what we can and simplify what we can't.
Clearly this needs further discussion WRT details!
2. Process them: ie integrate them into their DB?
Do we save customer information accross multiple
assignments, or keep a separate customer record
for each assignment?
I strongly opt for the former. This suggests that
a customer object/table in the database would be a
GOOD THING (tm).
> 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.
>
> 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.
Questions:
1. Which requests should be sent?
For assignments, I believe that the following are
non negotiable:
a. inetnum objects, (whether or not the customer
already has a person object- thats's what
auto-1 is for.)
So how do we tell IMPT when RIPE assigns the
person object to a customer?
How about hourly reminders so that the human
is reminded to reguraly check his/her email
and add the contact info when it is ready?
b. 141 forms.
These can be a right illigitimate child. Cull
information from the DB and automate it as much
as possible.
I believe that any required use of the RIPE
Whois is an example of a defincieny in the
scope of data stored by the backend DBMS.
For allocations, I believe these _are_ negotiable:
Requests for more space. It's nice having this
automated. However, how easy would it be to
program? I've a feeling, letting the hostmaster
know that NOW is a good time to get new space
might have to do.
And most hostsmasters are bright enough to know
this themselves.
Problems:
1. Basicaly, this needs low level refining.
What and how.
2. To what extent do we need to deal with replies
from RIPE NCC?
Should we attempt to flag the users attention or
parse the email itself?
Should we extract any ticket numbers? What do we
do with them?
> 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.
>
> A less-convenient interface to IPMT for more complex functions and
> administration is acceptable.
I think I discussed most of this at the top.
Questions remaining:
1. Java script enabled?
My choice would be a cautious yes... Maybe an old
Javascript just for keeping state and sanatizing
input (performing above checks?), so that most
browsers won't choke.
2. Fancy shmancy HTML?
I'm no web designer. Not sure how thos would be
too much a problem as long as its multi broswer
compliant.
3. Cookies?
Not, should we use them, but, do we need them?
4. Keeping state otherwise?
See, I think we need to get this far.
5. Who will design it so it looks pretty?
Who among you does designs thinsg to be easy to
use, and to look purdy?
________________________________________________________________________
So, hows about letting me know what y'all think?
Thanks,
Guy
--
Guy Vegoda \ guy@localhost *Please do not send html*
NIC: GUY-RIPE \ guy@localhost *attachments*
Unix, Linux Hobbyist \ +44(0)20 7961 8318 (work)
www.thenakedfrenchman.com \ +44(0)958 469 532 (cell)
