LIR-PARTITIONED proposal (originally LIR-ALLOCATED)

LIR-PARTITIONED PROPOSAL
------------------------

Following James Aldridge's proposal below, here follows an implementation
proposal by the RIPE NCC for a new status value in the RIPE Database.

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

The full final proposal (15 January 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 January 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)."

Proposed Name
-------------
RIPE NCC proposes to use the term: "LIR-PARTITIONED" ("LIR-PARTITIONED PA"
and "LIR-PARTITIONED PI") rather than "LIR-ALLOCATED", to clarify the use
of this added database feature. As "LIR-ALLOCATED" could be misinterpreted
as a policy feature, we believe that "LIR-PARTITIONED" is a more suitable
term, not involving policy terminology, but merely describing a partition
of the LIR's allocation.

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-PARTIONED PA" is allowed if one level less specific
inetnum object contains a "status:" attribute with the value of
"ALLOCATED 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".

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. An
implementation of this proposal would not affect IP address allocation
policy. It would not change the responsibility LIRs have for allocations
and assignments held by them. Furthermore, it would not change the manner
in which the RIPE NCC verifies allocation utilisation.

Timeline
--------
Before RIPE 41, January 2002.

----------------

As explained above, this implementation proposal only relates to the
proposal outlined in this mail. We welcome the feedback from the LIR-WG
and the DB-WG on the "LIR-PARTITIONED" proposal.

However, recent comments on the lir-wg mailing list have indicated a wish
among some members of the community for a more extensive change, allowing
LIRs to sub-allocate IPv4 address space to subsidiaries or downstream
ISPs.

Such a change would be a rather significant change in current IPv4 address
allocation policy, as it has an impact on the LIR's responsibility for its
address space as well as the manner in which the RIPE NCC would verify
utilisation.

If the general feeling in the community is that the "LIR-PARTITIONED"
proposal does not cover the LIRs' need, but a more significant change to
current IP allocation policy is necessary, then I propose that this be
discussed in detail in the LIR-WG.


Kind regards,

Nurani Nimpuno

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