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@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