May 2001 - ipmt-dev - mailman.ripe.net

Apologies!
by Guy Vegoda 18 May '01

18 May '01

I meant to say Manuel, rather than Valente in the last message. I don't quite know what came over me. As I say, I am sorry. -- ... it is easy to be blinded to the essential uselessness of them by the sense of achievement you get from getting them to work at all. In other words... their fundamental design flaws are completely hidden by their superficial design flaws. -- The Hitchhiker's Guide to the Galaxy, on the products of the Sirius Cybernetics Corporation. o guy(a)vegoda.org o www.thenakedfrenchman.com o +44 7958469532 o

1 0

Robo-Bijal version 0.9.5
by Guy Vegoda 18 May '01

18 May '01

We are very close now to a final release v 1.0 I have sorted out the migration script so that it isn't an evil hack any more, but a fully commented piece of software. I have also added a hierarchy display function, by registry, or all registries together, that lets you see at a glance, every assignment made. I anticipate that next will be W-Week. (www.robobijal.org will have links to the tarball. I'm hoping that Valente will let me also put it on the RIPE ftp site). It won't be even half as good as IPMT when it's finished. Hopefully though, it will tide people over (who want to use it) until IPMT ships. Take care all, Guy -- ... it is easy to be blinded to the essential uselessness of them by the sense of achievement you get from getting them to work at all. In other words... their fundamental design flaws are completely hidden by their superficial design flaws. -- The Hitchhiker's Guide to the Galaxy, on the products of the Sirius Cybernetics Corporation. o guy(a)vegoda.org o www.thenakedfrenchman.com o +44 7958469532 o

1 0

Re: Perl
by maldwyn morris 16 May '01

16 May '01

Dave wrote: >Yup IŽm subscribed too :) Nice to read you. >Personally IŽd be very much in favour of NOT using perl6. Many users at >least for the next two years will >not wish to upgrade just for this tool. Also >unless we actually NEED perl6 there is little point, or ? > I believe Perl 6 will remain a concept not an interpreter for some time yet, so the point is moot. >With regards the structure of the tool... > >Looks good. A few thoughts of my own... > >One of the processes could be seen comprised of the following steps: > >1. Address request - from salesman or customer >2. Approval of request - RIR, LIR, LIR delegate, automatic, >3. Assignment of addresses - network engineer, mobile phone dept, whatever. >4. Registration - maybe automatic - local and RIR databases >5. Configuration - presently outside scope but maybe we should provide >hooks. > >I would like to see the tool maintain the independence between these steps >as >they could each be carried out by different people. Good point. >A text DB would be good, but maybe it requires a little >structure - for example separate tables for each /16. >This is what we use >presently. I think all four DBs can probably be text-based in a basic implementation, but it would be nice to have IPMT access them via a standard interface like DBI which would allow easy upgrading to real DBs when required. Text-based DBs means easy(er) debugging too. Cheers, Maldwyn _________________________________________________________________________ Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com.

1 0

Perl
by Guy Vegoda 16 May '01

16 May '01

Are we using Perl 5 or Perl 6? I just read an exegesis on Perl 6 at use.perl.org and it looks pretty sumptuous.... Guy -- ... it is easy to be blinded to the essential uselessness of them by the sense of achievement you get from getting them to work at all. In other words... their fundamental design flaws are completely hidden by their superficial design flaws. -- The Hitchhiker's Guide to the Galaxy, on the products of the Sirius Cybernetics Corporation. o guy(a)vegoda.org o www.thenakedfrenchman.com o +44 7958469532 o

2 1

Re: Oooooh!
by maldwyn morris 16 May '01

16 May '01

Guy wrote: >Having looked at Maldwyn's excellent diagram, I now >"get it". I think your value of "excellent" may need updating... I used Somewindowssharewaretool + MSPaint + PaintShop but now I've found dia, I wish I'd used that: http://www.lysator.liu.se/~alla/dia/index.html >Yes: I think it looks right. That I can deal with. Cool. >I especially like the idea of abstracting over the >prexisting customer DB, but feel that in far too >many cases, leaving it to the LIR to impliment that >will be far too hard. Agreed - I think we should provide a default, simple one. >What I have discovered is that it was easier for >Level 3 to clean up the RIPE registry and import >that with scripts than to try and convert the old >QIP Oracle databse. Interesting. >(I am still finishing off the scripts; there are >several issues. When finished, I shall report back >experiences to this list). > >Therefore, I think that including a set of scripts >with version 1.0, that, _if necessary_ can create a >ready to go database in one of the free RDBMS's out >of the RIPE Whois database is a good idea. OK. >That way, WRT migrating the old data; those who can, >will and thosew who would have dificulty can fall >back on this system, which is still easier that >doing all the work themselves. Sounds like A Good Idea. Thanks for your valuable insight. I think the Top-down "We don't know much about it, but we think it should look like this" and the Bottom-up "We've actually done this, you know" are getting close to meeting in the middle... Cheers, Maldwyn _________________________________________________________________________ Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com.

3 2

Oooooh!
by Guy Vegoda 16 May '01

16 May '01

Having looked at Maldwyn's excellent diagram, I now "get it". Yes: I think it looks right. That I can deal with. I especially like the idea of abstracting over the prexisting customer DB, but feel that in far too many cases, leaving it to the LIR to impliment that will be far too hard. What I have discovered is that it was easier for Level 3 to clean up the RIPE registry and import that with scripts than to try and convert the old QIP Oracle databse. (I am still finishing off the scripts; there are several issues. When finished, I shall report back experiences to this list). Therefore, I think that including a set of scripts with version 1.0, that, _if necessary_ can create a ready to go database in one of the free RDBMS's out of the RIPE Whois database is a good idea. That way, WRT migrating the old data; those who can, will and thosew who would have dificulty can fall back on this system, which is still easier that doing all the work themselves. Just my $0.02 (-: ATB, Guy -- ... it is easy to be blinded to the essential uselessness of them by the sense of achievement you get from getting them to work at all. In other words... their fundamental design flaws are completely hidden by their superficial design flaws. -- The Hitchhiker's Guide to the Galaxy, on the products of the Sirius Cybernetics Corporation. o guy(a)vegoda.org o www.thenakedfrenchman.com o +44 7958469532 o

1 0

IPMT Structure
by maldwyn morris 15 May '01

15 May '01

Hi guys, I've made this overview of a proposed structure for IPMT. I think it's mostly obvious: The dotted line is the border of the LIR internal network; the mail handlers process incoming mail from a customer of the LIR or from the RIPE NCC; we don't have to implement the blue or purple boxes; the customer DB Interface is boxed off as I think it will be essential to make that an API that people can bolt their own Customer DBs on to. I think that - when we've agreed the structure - we should think about the major external functions that will be provided by the big red box ? Comments on the diagram, the process, the world, welcome. Cheers, Maldwyn _________________________________________________________________________ Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com.

1 0

development
by Guy Vegoda 04 May '01

04 May '01

I guess one thing we should talk about in the spec is how to we deal with migration (not technical details so much, but processes and procedures) beacuse I am right in the middle of one now. I could certainly have benefited from some mature tools. What d'yall think? Shall I draft some of the p's and p's myself and let you parise me for my forsight? Best, Guy -- Guy Vegoda likes: UNIX, IP networking, Perl Contactable on: 07958 469 532, 020 7961 8318 Owns: scar-tissue.org, thenakedfrenchman.org, sirius-cybernetics-corporation.com

2 1

Comments and specifications
by Manuel Valente 04 May '01

04 May '01

Hi all, Thanks to those who came to the WG presentation, I hope everyone now has a good idea of what we would like to achieve. This would probably be a good moment for people to come up with comments on what was said during the presentation, so please do not hesitate. I will append below the latest specfication document that was sent to the lir-wg, if only to have it in the archive of this mailing list. Cheers. -- Manuel Valente - Sofware Manager - RIPE NCC ------------------------------------------------------------------ Draft of Specifications for an IP Management Tool Manuel Valente, Leo Vegoda, Maldwyn Morris RIPE NCC swcontact(a)ripe.net 20010419 0. Introduction Following a presentation of an IP Management Tool by Guy Vegoda at the Tools BOF at RIPE 38 [1], interest was expressed in the development of an Open Source version of such a tool and we drew up Requirements (qv) 1. General Points Open Source: We will release this software under the LGPL licence [2]. We use this instead of GPL [3] because this means we will remain able to using non-GPL'ed libraries, should that prove necessary. The RIPE NCC is happy to support this project, but of course its Open Source nature means anyone else can use the code to begin their own Open Source project. We are also happy about that. IPV6: We would be foolish not to consider the possibility of using this tool for managing IPV6 addresses and writing it such that this is possible, but we think it will be useful even if it does not and do not consider IPV6 support a requirement. 2. Definitions: Parties : RIPE NCC: The European Regional Internet Registry, which grants IPV4 address allocations to its customers, the LIRs. LIR: A customer of the RIPE NCC which interracts with the RIPE NCC in order to make IPV4 address assignments to their LIRCustomers from the LIR's IPV4 address allocation. LIR Customer: A person or organisation which wants to receive IPV4 address assignments. LIR Hostmaster: A person working for a LIR whose job it is to make IPV4 address assignments to the LIR Customers. Registered IPV4 Address Information: There are two forms of IPV4 address information which are registerd by the RIPE NCC and which are stored in the RIPE Whois Database: IPV4 Address allocations and IPV4 Address assignments. IPV4 Address allocations: A range of IPV4 addresses from which the RIPE NCC allows a certain LIR to make IPV4 Address assignments to their LIRCustomers. IPV4 Address assignments: A range of IPV4 addresses from a LIR's IPV4 Address allocations which the RIPE NCC and the LIR allows a certain LIRCustomer to use on the Internet. Interactions: I1: LIR Customer Assignment Request: An LIRCustomer asks their LIR for an IPV4 Address assignment and the LIR replies. Composed of: I1.1: LIRCustomer communicates request for IPV4 Address assignment to LIR I1.2: LIRHostmaster evaluates request I1.3: LIRHostmaster queries LIRCustomer about request I1.4: LIRHostmaster actions request I1.5: LIRHostmaster informs LIRCustomer of request outcome I1.6: LIRHostmaster completes request for LIR Customer I2: LIR Assignment Request: An LIR asks the RIPE NCC for approval of an IPV4 Address assignment and the RIPE NCC replies. I2.1: LIRHostmaster formulates query I2.2: LIRHostmaster sends request to NCC I2.3: LIRHostmaster handles response I2.4: LIRHostmaster completes request I3: LIR Allocation Request: An LIR asks the RIPE NCC for an IPV4 Address allocation and the RIPE NCC replies. I3.1: LIRHostmaster formulates query I3.2: LIRHostmaster sends request to NCC I3.3: LIRHostmaster handles response I3.4: LIRHostmaster completes request I4: LIRH Manages Customers I4.1: LIRHostmaster composes report(s) of info on one customer I4.2: LIRHostmaster composes report(s) on all customers I4.3: Creation of new customer I4.3: Update customer info I4.3: Delete customer I5: LIRH Manages LIR's Assignments I5.1: LIRHostmaster composes report of all assignments I5.2: LIRHostmaster composes report on a specific assignment I6: LIRH Manages LIR's Allocations I6.1: LIRHostmaster composes report of all allocations I6.2: LIRHostmaster composes report on a specific allocation 3. IPMT Functional Breakdown The functions the IPMT tool must provide, divided per Interaction. I1: LIR Customer Assignment Request: I1.1. LIRCustomer communicates request for IPV4 Address assignment to LIR IPMT: F1: receive the LIR Customer Assignment Request F2: store request info F3: LIR Hostmaster sees new request I1.2 LIRHostmaster evaluates request IPMT: F4: Check request correctly formatted and I1.5: Deny if not F5: Check request valid and I1.5: Deny if not F6: Check LIR Customer valid and I1.5: Deny if not I1.3: LIRHostmaster queries LIRCustomer about request IPMT: F7: Get more info from LIR Customer regarding request F8: update request info F9: -> I1.2: Evaluate I1.4: LIRHostmaster actions request F11: Need to ask RIPE to perform request ? -> I2 if so F12: Check request F13: Update request info F14: Check other info concerning assignments F15: Update other info based on request I1.5: LIRHostmaster informs LIRCustomer of request outcome F16: Communicate request outcome and info to LIR Customer I1.6: LIRHostmaster fills in customer request F17: Generate info about request, possible with F7 4. Implementation proposals ?? LIR Hostmaster interracts with IPMT via a GUI. ?? IPMT GUI will have HTML form range of elements ( text, buttons, single-line text, multi-line text, radio buttons, check boxes ). I1.1 LIRCustomer communicates request for IPV4 Address assignment to LIR F1: receive the LIR Customer Assignment Request ?? LIR Customer sends request : - via html form - by snailmail/phone/other & LIRH fills in a GUI form - by email to designated address - address served by mail robot ? - FORGET for now - too complex ? - LIRH uses CLI to fill in - Other LIR fills in using IPMT via API F2: store request info ?? Store in 'LIR Customer request' record in DB ?? Request record: Request id LIR Customer email address date raw request info - from LIR customer comm.s LIRH ID - 'request owner' F3: LIR Hostmaster sees new request ?? IPMT 'fetch next request' button to show next LIR Customer Request in GUI - wait queue... - IPMT perfroms F4,F5,F6 I1.2 LIRHostmaster evaluates request F4: Check request correctly formatted and I1.5: Deny or I1.6 if not IPMT parses 'LIR Customer Request' record, extracts and stores in it: LIR customer id request size in num of IP addresses request category: ?? status: ?? IPMT informs LIR Hostmaster if parse fails F5: Check request valid and I1.5: Deny or I1.6 if not ?? IPMT checks 'LIR Customer request' record ?? I1.3 if more info needed OK ?? IPMT sets 'checked' flag F6: Check LIR customer valid and I1.5: Deny or I1.6 if not IPMT looks up LIR customer info ?? LIR customer info stored in a DB ?? 'LIR customer' record LIR customer id customer email addresses and other contact info. request ids of previous requests total space size of assignments - enough info to make Whois DB person object ? IPMT informs LIR Hostmaster if customer not valid I1.3: LIRHostmaster queries LIRCustomer about request F7: Get more info from LIR customer regarding request ?? LIR Hostmaster uses IPMT to compose and send email to LIR customer ?? LIR customer reply automatically added to 'customer request' record or LIRH can use IPMT to do this ( e.g. : enter phone conversation ) ?? IPMT 'action needed' button to show customer reply received F8: update request info LIR Hostmaster updates 'customer' and 'customer request' records F9: -> I1.2: Evaluate I1.4: LIRHostmaster actions request F11: Need to ask RIPE to perform request ? -> I2 if so IPMT Check LIR Assignment window vs size of request - force insert of NCC# ticket number of approval if it's needed - need access to LIR Assignment window reports to LIR Hostmaster F12: Check request IPMT examines request record vs customer and LIR assignment and allocation records ?? assignment records - in whois ??: - or IPMT stores this locally - or LIR's records ?? via defined API ?? ipv4 range - IPMT makes _suggestion_ - allow choice of methods by config file as debatable - what methods are there ? netname - IPMT makes _suggestion_ ?? allocation records - in whois ??: - or IPMT stores this locally - or LIR's own records ?? via defined API ?? ipv4 range F13: Update request info ?? IPMT generates assignment addresses from 'customer request' record and assignment and allocation records LIR Hostmaster agrees or alters assignment addresses F14: Check other info concerning assignments - too varied so LIR to implement - IPMT provides I4,5,6 to allow LIRH access to info it has ?? LIR workflow stats ?? LIR Hostmaster stats ?? LIR infrastructure updates ?? LIR customer billing F15: Update other info based on request IPMT stores assignment addresses in 'customer request' record I1.5: LIRHostmaster informs LIRCustomer of request outcome F16: Communicate request outcome and info to customer LIR Hostmaster uses IPMT to compose and send email to customer Update 'customer request' record I2: LIR Assignment Request: An LIR asks the RIPE NCC for approval of an IPV4 Address assignment and the RIPE NCC replies. I2.1: LIRHostmaster formulates query F20: LIRH uses IPMT to produce a filled-out 141 Form. Gets data from customer, request and assignment records I2.2: LIRHostmaster sends request to NCC F21: Send request to RIPE-NCC by e-mail I2.3: LIRHostmaster handles response F22: Check response of RIPE-NCC and resent request if necessary -> repeat F20 I2.4: LIRHostmaster completes request F23: Update customer, request and assignment records. I3: LIR Allocation Request: An LIR asks the RIPE NCC for an IPV4 Address allocation and the RIPE NCC replies. I3.1: LIRHostmaster formulates query F30: Gets data from assignment and allocation records and fills out pro-forma request to RIPE-NCC. I3.2: LIRHostmaster sends request to NCC F31: Send request by e-mail. I3.3: LIRHostmaster handles response F32: Check response of RIPE-NCC and resent request if necessary -> repeat F30 I3.4: LIRHostmaster completes request F33: Update assignment and allocation records

1 0

Me too!
by maldwyn morris 04 May '01

04 May '01

Hi guy(s), Don't worry - Manuel and I are here, and I think that brings us up to a quorum... Some salient points from the Tools WG: - Unix ( which I read as 'Unix-like' ) is favoured by the vast majority of potential users. - There are lots of potential users. - Help from the author of yet another similar tool may be forthcoming. - Assignment address range selection schemes are many and varied ( I think we should start with a simple one, and I think we agree it will be suggestion only ). I think we should start with a system block diagram - I'll post one next week when I've got access to xfig, unless someone beats me to it... Cheers, Maldwyn -- maldwyn(a)maldwyn.com _________________________________________________________________________ Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com.

1 0