[lir-wg] draft-documents: sub-allocations.html

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 at 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/ -----