Our internal solution does:

-> assigns subnets out of internal 'allocations' to help aggregation. The LIR allocations and internal 'allocations' form a tree down to the most specific assignments.

I think that this comes under designing the human viewable data structures to store information about the IP address space itself. I think what you have done is a good idea, though. As Nigel Titley pointed this out to me originally, IP lends itself very nicely to a binary tree of largest free blocks. Lets design the data structure available to the hostmaster.

-> validation against 'overlapping' assignments and assignments out of 'less specific' allocation bounds.

We definately need overlap detection.

-> 'allocation pools' for flexible assignments in cases where addresses for a single site are not aggregated into a single block.

This comes under designing the data structures, I think.

-> searching of unassigned space using a combined exact-fit/first-fit strategy.

Please expand on this. I don't want an end product that decides for you which subnet you will be assigning. That will be useful for people who need to migrate already used ranges of IP address space into the tool (ie everyone). QIP 4 does this, which is another reason why IMHO, it's totally useless. (My views do not represent anybody that Lucent can sue).

-> heuristic net_name generation

I think that this is a lovely touch, but it doesn't come into the "minimal requirements" umbrella.

-> quick overview of allocation tree, also showing unassigned gaps.

think that this will indeed be a useful feature of any data structre we decide on.

-> data is stored in a database that also stores routing and reverse DNS information.

I don't believe if IPMT is mandated to deal with DNS at all, at least in its first incarnation.

no support for IPv6 so far...

IPv6 is something I'd like IPMT to eventually support. Still, this might have to get stuck on the back burner for the moment... So; A summary so far: 1) We need to check for properly formulated dotted quad format IPs: n.n.n.n/m where n >= 0; n <= 255; m >= 1; m <= 32; 2) We need to check for overlaps so that two subnets cannot overlap any space. We need to check for: (where a is frist IP in range, z is last IP in range) 0 : No overlap a1---z1 a2---z2 a1---z1 a2---z2 1 : Range 1 totally inside range 2 a1---z1 a2--------------z2 2 : Range 2 totally inside range 1 a1--------------z1 a2---z2 3 : Partial overlap a1-----z1 a2-----z2 a1-----z1 a2-----z2 4 : Perfect overlap, range 1 == range 2 a1-----z1 a2-----z2 5 : Edge overlap = someone screwed up, editing by hand a1---z1 a2---z2 a1---z1 a2---z2 ie. 10.15.20.0 -- 10.15.21.0 10.15.21.0 -- 10.15.21.255 (oops). 3) We need some kind of data structure to be defined, so that the hostmaster can access the IP space in a sensible way. I reckon this should include: o A way of seeing the IP space - what is free, what is used. o A way of dividing the IP space into sections for assigning to different areas, such as colo, dialup etc. o A sensible method of assigning free space (ie not always the next free block - think of migration). 4) We need to think about IPv6 I hope people will comment on this summary and pummel beat it into shape. Nothing worthwhile ever happened by people being polite. Thank you very much Michael for your comments. 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)