LIR-PARTITIONED - Final version

[Nurani Nimpuno <]

Dear all,

Following the announcement 28 Sep 2001 on these lists, please find below 
the final details of the LIR-PARTITIONED PROPOSAL. This proposal will be 
implemented by the RIPE NCC in the coming period and presented at the RIPE 
41 meeting in January 2002.

Comments and suggestions made on this list have been incorporated in the 
proposal below.

+-----------------+
| LIR-PARTITIONED |
+-----------------+

Background
-----------
This proposal (initially named "LIR-ALLOCATED") was originally discussed at
September 1999. James Aldridge later sent out a first proposal to the
LIR-WG mailing list, 14 Jan 2000. (See:
http://www.ripe.net/ripe/mail-archives/lir-wg/20000101-20000401/msg00007.html)

The full final proposal (15 Jan 2001) by Aldridge can be found at:
http://www.ripe.net/ripe/mail-archives/lir-wg/20010101-20010401/msg00003.html

At the RIPE 38 meeting,(22-26 Jan 2001), the RIPE NCC accepted the
action to implement this proposal.

Motivation (as expressed by James Aldridge)
--------------------------------------------
"For various reasons large registries often need to distribute their
allocated address space between various parts of their organisation (for
example we have separate national operations in 20 or so countries
obtaining address space through the eu.eunet registry). In these
situations it makes sense to document this redistribution in the RIPE
database but there is currently no way to do this without throwing up
errors in the RIPE NCC's auditing procedures or by removing flexibility
and adding more work to the already busy NCC hostmasters by having each
local operation treated as having their own allocation.

Previously the RIPE database software allowed anyone to register an object
with a status value of "ALLOCATED" but this was abused by people who
didn't know what they were doing and so this is no longer possible and all
non-NCC registered inetnum objects must now have the status of "ASSIGNED".
However, having multiple levels of assignments in the RIPE database causes
error reports from the NCC's auditing processes which now see anything
under the higher lever sub-allocation as being a duplicate (or
overlapping) assignment which makes finding "real" problem assignments
difficult or impossible.

By allowing a local IR to register an inetnum object with a new status
value of "LIR-ALLOCATED" it becomes possible to differentiate between a
higher level sub-allocation ("status: LIR-ALLOCATED") and a final
assignment by a LIR ("status: ASSIGNED"). By allowing this registration of
intermediate objects it would also be possible to restrict changes to
lower-level objects differently in different blocks of addresses within
the LIR's allocation by setting different "mnt-lower" values without
having to open the whole allocated block up for changes by anyone who
might have a valid reason for updating a particular (range of) inetnum
object(s)."

Database Objects affected
-------------------------
Only inetnum objects may have the "LIR-PARTITIONED" status value.

Usage
-----
The "LIR-PARTITIONED" feature allows LIRs to delegate maintenance of
lower-level objects representing assignments within the address space
specified by the inetnum object with the status "LIR-PARTITIONED PA" OR
"LIR-PARTITIONED PI".

Functionality
-------------
When creating or modifying the inetnum object the database will check the
value of the "status:" attribute according to the following rules:

- The value of "ALLOCATED PA" or "ALLOCATED PI" is allowed if the object
is maintained by the RIPE-NCC-HM-MNT mntner (this name is specified in
ALLOCMNT variable of the configuration file)

- The value of "LIR-PARTITIONED PA" is allowed if one level less specific
inetnum object contains a "status:" attribute with the value of
"ALLOCATED PA" or "LIR-PARTITIONED PA".

- The value of "LIR-PARTITIONED PI" is allowed if one level less specific
inetnum object contains a "status:" attribute with the value of
"ALLOCATED PI" or "LIR-PARTITIONED PI".

Additional clarification
------------------------
This proposal addresses the added inetnum status value as proposed by James 
Aldridge. This is strictly a database feature, allowing LIRs to delegate 
maintenance within their allocations in the RIPE Database. The 
implementation of this proposal will not affect IP address allocation 
policy. This means that it will not affect the responsibility LIRs have for 
allocations and assignments held by them. Furthermore, it will not change 
the manner in which the RIPE NCC verifies allocation utilisation. There is 
an on-going policy discussion addressing this specific issue.


Kind regards,

Nurani Nimpuno

*-----------------------------------*
| Nurani Nimpuno nurani@localhost  |
| Internet Address Policy Manager   |
| RIPE Network Co-ordination Centre |
| http://www.ripe.net               |
*-----------------------------------*