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

Hello Gert Doering!

On Tue 2003-01-21 (14:58), Gert Doering wrote:
> Hi,
> 
> On Mon, Jan 20, 2003 at 05:22:01PM +0100, Christoph Mohr wrote:
> > 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.
> 
> Indeed there is a problem here - 3.1 doesn't specify the type of "status:"
> to be used in the a sub-allocation inetnum object.  
> 
> I propose to use "SUB-ALLOCATED PA", but I'm not sure whether the NCC or 
> community has some other ideas here.
> 
> > Now the question I have is if this will apply to all inetnum objects which are
> > already in the database.
> 
> This section might sound new, but it isn't - it was always a mistake to
> create "ASSIGNED" inetnum objects inside existing "ASSIGNED" inetnums.
> 
> The database doesn't enforce this restriction today (for IPv4), but if
> you run the "asused" check tool, it will complain about overlapping 
> objects (and so will the RIPE hostmasters).
> 
> > 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.
> 
> What you do is, by definition of "ASSIGNED PI", already a violation of
> the policy (PI space is not supposed to be given to other institutions,
> by definition).  It makes lots of sense to do it :-) but the policy doesn't
> take that into account.

Please have a look at 141.6.0.0/16 (BASFAG-NET) which is the Class B network
of BASF (ASSIGNED PI). Now there are to other ASSIGNED PI networks nested in,
namely 141.6.207.0/24 (BASFAG-CH-NET) and 141.6.198.0/23
(BASFAG-DYN-NET-141-6-198), which obviously don't belong to other institutions.
It seems to me very reasonable because there are other contacts in the smaller
networks. On the other hand, it doesn't seem reasonable, to apply "ALLOCATED
PI or PA" to the large B net 141.6/16.
This is just an example of nested inetnum objects with the status ASSIGNED PI,
there could be found many others.
I think the RIPE database should reflect this difficult situation, otherwise
the network managers/administrators won't put in inetnum objects for smaller
networks with different contacts so that finally the database doesn't provide
useful information.

> On the other hand, this is "old" PI stuff, which is likely to be assigned
> before there even was a set of RIPE rules, and thus the standard rules do
> not apply...
> 
> [..]
> > 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.
> 
> It's not the central purpose of this draft document to disallow things
> (to the contrary :-) ), this section is mainly intended to clarify the
> underlying rules - ASSIGNMENTs come from ALLOCATIONs or SUB-ALLOCATIONs,
> and nowhere else, and MUST NOT be nested.
> 
> Reading your comment, I feel that it might be useful to change 3.2 to
> apply only to PA (the whole draft is only targeted at PA space) and 
> reconsider what to do with "old" PI assignments.

Maybe this could be a solution at the moment. Will there be an appropiate
new draft document in the web?

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