Dear Colleagues! Referring to http://www.ripe.net/ripe/draft-documents/sub-allocations.html, I found a problem which maybe will arise after publishing the document. In 3.2 Restriction on creation of inetnums with an "ASSIGNED" status I read: The creation of an inetnum object with a status of "ASSIGNED PA" or "ASSIGNED PI" will not be allowed if there is either a less specific or more specific inetnum object with an "ASSIGNED" status. The assigned status inetnum is the most specific registration allowed. Now the question I have is if this will apply to all inetnum objects which are already in the database. We, the Academic Network of the Federal State of Baden-Wuerttemberg (BELWUE), manage the internet not only for the universities in Baden-Wuerttemberg, but as well for many public schools. To provide public schools with internet addresses, we are allowed by the universities to use some of the addresses in their own class B network they don't need. (I think there won't be one university which currently uses all their IPv4 addresses in its B block.) So we are able to economise IPv4 resources by using IP addresses which wouldn't be used otherwise. That's why there are overlapping inetnum objects which are both "ASSIGNED PI", which will be forbidden in the future if I understand well the new document. Example: Within 132.230/16 which is FDN (Freiburg University) one can find 132.230.194.0 - 132.230.196.255 (BELWUE-SCHULEN) which are IP addresses of public schools in the Freiburg region. We prefer to have this inetnum object because we don't want the university to deal with abuse mails which may occur because there isn't always specialised staff in the schools to manage firewalls, mailservers etc. correctly. When there is an abuse incident we are able to react quickly by contacting the respective school. We made yet the experience that these entries in the database were very useful. Well, perhaps I misunderstood the draft document and there won't be any problems like the one I mentioned. Anyway, there should be some clarification about the objects the database won't allow to create in the future. Best regards, Christoph Mohr -- -- Christoph Mohr, BelWue Coordination ---------- mailto:mohr@belwue.de ----- Computing Center University of Stuttgart (RUS) Phone: +49 711 685-2079 Allmandring 30, D-70550 Stuttgart Fax: +49 711 678-8363 ------------------------------------------------- http://www.belwue.de/ -----