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
