- lir-wg - mailman.ripe.net

[guy@sirius-cybernetics-corporation.com: IPMT specen.]
by Guy Vegoda 20 Apr '01

20 Apr '01

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

7 9

RE: [guy@sirius-cybernetics-corporation.com: IPMT specen.]
by Hallgren, Michael 19 Apr '01

19 Apr '01

> > Hi there all you internet people! > > Hello. 'lo, > > > 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. > > FWIW Perl with the TK toolkit/widget set runs under both *nix and > Windows. > > I still would prefer a web based solution. > Would as well. > WRT people's comments about php vs. perl - php is very easy > to learn, and > it's very easy with perl to write code in such a way as to render it > incomprehensible to anyone else (or to anyone who dosn't > understand you > particular dialect of perl). > > also doing compilcated datastructures in perl is a pain. hrm,... recent versions (5, 6) have gotten a _lot_ more freiendly than old 4. mh > > you can't (afaik) do non web based gui's in php tho. > > -- > Internet Vision Internet Consultancy Tel: > 020 7589 4500 > 60 Albert Court & Web development Fax: > 020 7589 4522 > Prince Consort Road > vision(a)ivision.co.uk > London SW7 2BE http://www.ivision.co.uk/

1 0

Re: [guy@sirius-cybernetics-corporation.com: IPMT specen.]
by Gyan Mathur 19 Apr '01

19 Apr '01

In response to Guy Vegoda: > However, JavaScript might be equally worth considering. Please don't make something that can only be used with Javascript. In our office, Javascript is considered a security risk and it is not allowed to switch it on on any browser here, so we would be unable to use your tool. Gyan Mathur nl.demon

1 0

ANNOUNCEMENT: New Version of Asused
by Maldwyn Morris 19 Apr '01

19 Apr '01

Hi, The RIPE NCC are pleased to announce the release of a new version of Asused - this is Version 3.60. Asused is a tool to check and summarise address space registered in the RIPE database. For a given list of allocations the tool prints various information concerning the allocations and the assignments they contain. The software is written in standard Perl 5 and uses several Perl modules. It was written and tested on BSD/OS 3.1, but should work with any modern UNIX-like operating system. All the files needed are stored in this file: ftp://ftp.ripe.net/tools/asused-3.60.tar.gz or alternatively, just: ftp://ftp.ripe.net/tools/asused-latest.tar.gz You will need to use gzip and tar to extract them, then please follow the instructions in the README file. The main change since Version 3.52 is that Whois DB Version 3 objects are now handled correctly. Timur Bakeyev of RIPE NCC did the programming. We are keen to receive your further feedback on this software - please address your comments and/or suggestions to the address below. Cheers, Maldwyn Morris swcontact(a)ripe.net

1 0

draft agenda (v1) for IPv6 working group RIPE39
by David Kessens 18 Apr '01

18 Apr '01

Hi, Below follows the first draft of the agenda for the ipv6 wg. The current plan is to use the second part of our session for ipv6 policy discusions. This part will be a joint session with the local-ir working group. Please let me know if you have any other topics that you want to have discussed or if you would like to volunteer for a presentation. We still have some time left in our agenda for additional topics. Thanks, David K. --- Agenda for the IPv6 Working Group Meeting RIPE39, Bologna Tuesday, May 1, 2001, 14:00-17:30 1st part 14:00-15:30 A. Administrative stuff - appointment of scribe - agenda bashing (David Kessens) B. Status of the 6bone (David Kessens) C. Securing the Mobile-IPv6 Binding Update (Tony Hain) D. Developments/initiatives regarding IPv6 in the RIPE region and beyond (input from the audience) 2nd part 16:00-17:30 joint session with lir-wg E. Draft on allocation sizes (Niall Murphy) F. Status of IETF/RIR allocation boundary discussions (Randy Bush/Mirjam Kuehne) Z. AOB ---

1 0

Migration of the TEST database is delayed
by Andrei Robachevsky 18 Apr '01

18 Apr '01

Dear colleagues, Unfortunately due to hardware problems with the computer running TEST database server we need to delay the migration of the TEST database that was planned on 17-18.04. We plan to start the migration of the TEST database tomorrow, 19.04. We will keep you informed. Sorry for any inconvenience this caused. Regards, Andrei Robachevsky DB Group Manager RIPE NCC

1 0

Discussion on change to policy process
by Hans Petter Holen 12 Apr '01

12 Apr '01

Dear WG, I would like to start a discussion on slightly improving the process for setting new policy. http://www.ripe.net/ripe/wg/lir/howto_devolep.html This is inspired by the ARIN policy process: http://www.arin.net/announcements/policy_eval_process.html Altough this is very different from how we do things in the lir-wg there is one change I would like us to discuss: "To be considered for presentation at these meetings the proposal should be submitted to ARIN staff six (6) weeks prior to commencement of the meetings to allow time for it to be posted and an announcement to be sent out at least thirty (30) days before the meetings convene." Should we in our procedures include a requirement for the proposed change to be submitted to the lir-wg some weeks before the lir-wg meeting ? Hans Petter

2 1

change maintainer
by Stefan.Gasteiger＠Gendorf.de 10 Apr '01

10 Apr '01

sorry, if this is trivial or has been asked before. how can i change the mnt-by attribute of an object? i am authoritative for both maintainers. Kind regards, Stefan Gasteiger I+K Betrieb (zertifiziert nach DIN EN ISO 9001) InfraServ Gendorf Tel.: +49 8679 7 5599 Fax: +49 8679 7 39 5599 Mobiltel.: +49 172 8649205 E-Mail: Stefan.Gasteiger(a)gendorf.de

2 1

PI assignments
by Arif OKTAY 10 Apr '01

10 Apr '01

Hi, Can anybody help me about PI assigments please ? I have sent a PI request nearly 2 mounths ago. Though the automatic answer said that it was handed to a hostmaster, I couldn't receive any response since then. I have also send an e-mail to ncc(a)ripe.net and I couldn't receive any answer yet either. Is there a policy conflict I'm missing ? Regards arif ao189-ripe

2 1

Re: change maintainer
by RIPE Database Administration 09 Apr '01

09 Apr '01

Dear Colleagues, We have answered Mr. Gasteiger's question. For any questions regarding the RIPE database, please contact <ripe-dbm(a)ripe.net>. Regards, A. M. R. Magee ______________ RIPE NCC

1 0