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@polsl.pl