Havard, Thanks for starting this disussion. Here's some comments from a database implementation point of view, and some things we have discussed here at the NCC wrt aggregates and/or prefixes. There's two things in our view here: - the RIPE database should become classless ie move to general classless type addressing that can be of the form: <begin> - <start> # very general <begin> <mask> <begin>/<bits> we like the first form as general representation to keep them similar to what we have now. The other two could be accepted by the software, but would be rewritten to the first one. Of course extra flags could be added to the database to force a different representation, and tools to convert from one to the other are reasonably simple. - the RIPE database should contain aggregates the idea here is to create a new object that would indicate someone that would aggregate for someone else; proxy aggregation. Now, the first thing we should try and figure out is if we move all routing information into a new object, or do we keep the "inetnum" object for this, with the classless extensions above, and something special for proxy aggregation. Personally I have no strong feelings either way. Now, for implementation: * Hint for implementation in the RIPE database: from a routing prefix eg. * "129.240/15" create keys for all the natural IP network numbers covered by * this prefix with pointers to the routing prefix object. This should be a * fairly straight-forward approach (say I who haven't really hacked on the * RIPE software... ;-) Side-effect: lookup of unassigned network numbers * within a routing prefix after this change will no longer give the "No * entries found for the selected source(s)" result when whois is used, but * instead the routing prefix(es) will be returned, but no inetnum object. We thought of this one as well of course, and the move to anything classless would mean a redesign of IP netnumber indexing in the database. We know we have to do this, but we have not yet found a suitable way of implementing this right now. The new indexing would then be real classless, so it would conists of something like ranges, and anything in that range would match that object, including hostaddresses even (with classless you cannot tell anymore what is a hostaddress and what is a netaddress in some cases). Disadvantage is that nets that have no "inetnum" but do fall in a aggregate or prefix or something like that that object will show up. You could even explain that as a feature ;-) I'd say, let's get some discussion on this. Also people who have ideas on indexing classless IP numbers are more than welcome. -Marten