This proposal is a sound one. However, I would a slight change in the syntax: *in: <net-lo> - <net-hi> Reasons: - If a contiguous range consists of two supernet blocks the use of a mask would still make two database objects necessary. Example: 12 contiguous addresses (one 8 and one 4 net block) If a range of network numbers is used this does not happen. Supernet masks can easily be calculated from the range information if needed. - If a naive user queries a network in a range and gets the answer back as <net> <mask>, the meaning of the response will not necessarily be obvious. (The proposed "-" in the syntax is there to make the range meaning even more obvious) Daniel
"Wilfried Woeber, ACOnet, +43(1)58801-3614" <woeber@access.can.ac.at> write s: Andreas Schachtner (afs@Germany.EU.net) submitted the following proposal for discussion in Paris (RIPE-DB WG, agenda:2.3) --------------------------------------------------------------------------- ----- As it is getting more common, to allocate nets according to supernetting, the RIPE database should reflect this.
It might change the perspective for a router manager (and might change the technical implications as soon as classless routing will be deployed), if someone realizes that [s]he's in fact seeing a supernetted network inste ad of a siongle class C.
Considering this, I would propose to have thos networks classes in the RIPE DB as <net> <mask> pairs:
*in: 192.124.0.0 255.255.0.0
instead of 256 (ok, 254 :-) network entries.
The RIPE DB software has to be changed, of course. It would be clever, if for the purpose of indexing the software explodes the <net>,<mask> pair to all networks covered by this. All those index entries should point to the supernetted object, of course.
By this, if such a network number comes along, I simply do a query as for an ordinary class C, but get the supernetted as answer.
Opinions ? Andreas Schachtner --------------------------------------------------------------------------- -----