[db-wg] Proposal to cleanup some hack's with status values

Dear DB-WG Members

Proposal:

I propose to introduce some new status lines for INET(6)NUM objects to
cleanup some hacks.

Problem description:

Right now we have at least four category of hacks in the status lines:

1. ::/0

inet6num:       ::/0
netname:        IANA-BLK
(...)
status:         ALLOCATED-BY-RIR
remarks:        This network in not allocated.
                This object is here for Database
                consistency and to allow hierarchical
                authorisation checks.
(...)

2. 0/0

inetnum:        0.0.0.0 - 255.255.255.255
(...)
status:         ALLOCATED UNSPECIFIED
(...)

3. IPv6 allocations made by IANA to RIPE NCC

inet6num:       2001:600::/23  (this is just an example)
(...)
status:         ALLOCATED-BY-RIR # This block was actually allocated by the IANA
(...)

4. IPv4 allocations made by IANA to RIPE NCC

inetnum:        185.0.0.0 - 185.255.255.255   (this is just an example)
(...)
status:         ALLOCATED UNSPECIFIED
(...)

Hacks no 1 and 3 looks easy. Those are definately not ALLOCATED-BY-RIR.
So I propose to introduce two new status values: IPV6 for ::/0 and
ALLOCATED-BY-IANA for IANA IPv6 allocations.

Hacks no 2 and 4 are bit tricky. According to "IPv4 Address Allocation
and Assignment Policies for the RIPE NCC Service Region":

"ALLOCATED UNSPECIFIED: This address space has been allocated to an LIR
or RIR. Assignments may be PA or PI. This status is intended to document
past allocations (...)"

It is quite obvious that 0/0 is not "past allocation". So I propose to
introduce new status value: IPV4 for 0/0.

Moreover, it looks like "ALLOCATED UNSPECIFIED" has been overused also.
For example 185/8 has been allocated to RIPE NCC on 2011-02-08. This was
done after many of the previous versions of the "IPv4 Address Allocation
and Assignment Policies for the RIPE NCC Service Region" which include
quoted definition have been published.

So I propose to introduce new status value ALLOCATED IANA for such
cases.

Some possible issues to be addressed:

1. When this proposal will be supported by the DB-WG, then it has to be
discussed with AP-WG and IPv6-WG.

2. There are two more hacks which could be discussed: IETF reserved
blocks and legacy allocations under various RIR administration.

Looking for your comments.

Piotr

-- 
gucio -> Piotr Strzyżewski
E-mail: Piotr.Strzyzewski at polsl.pl