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

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.

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.

Gert Doering
        -- NetMaster
-- 
Total number of prefixes smaller than registry allocations:  55857  (55593)

SpaceNet AG                 Mail: netmaster at Space.Net
Joseph-Dollinger-Bogen 14   Tel : +49-89-32356-0
80807 Muenchen              Fax : +49-89-32356-299