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@sirius-cybernetics-corporation.com rather than lir-wg@ripe.net 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@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)