RIPE 34 LIR WG Draft Agenda

On 10th September I wrote:
> I think that it could be useful to start some discussion on whether an
> additional value for the inetnum "status" field would be useful.
> 
> What I would like to see, and which would be useful for a large registry such
> as "eu.eunet" which I coordinate, is somethig like "LIR-ALLOCATED" which could
> be used to tag a block of addresses as being sub-allocated by a local registry
> for some purpose (e.g. identifying a block as being used for assignments by a
> particular local operation, PoP, etc.) but which wouldn't cause all the real
> assignments under that block to be flagged as overlaps or duplicates by the
> NCC's registry auditing processes.

I've seen no comments on this so maybe I need to explain a bit more why I
think that a LIR-ALLOCATED value in the status field would be useful:

----------

		"Status: LIR-ALLOCATED" Considered Useful
		=========================================

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).

An example:

	inetnum:   10.1.0.0 - 10.1.255.255
	netname:   ZZ-REGY-19990916
	descr:     REGY Allocation
	country:   EU
	...
	status:    ALLOCATED PA
	mnt-by:    RIPE-NCC-HM-MNT
	...

	inetnum:   10.1.0.0 - 10.1.31.255
	netname:   ZZZ-REGY-ALLOC
	descr:     REGY - Local assignments in ZZZ
	country:   ZZ
	...
	status:    LIR-ALLOCATED PA
	mnt-by:    REGY-MNT
	mnt-lower: REGY-ZZZ-MNT
	...

	inetnum:   10.1.0.0 - 10.1.0.63
	netname:   CUSTOMER-XYZ-NET
	descr:     Customer XYZ in ZZZ
	country:   ZZ
	...
	status:    ASSIGNED PA
	mnt-by:    REGY-ZZZ-MNT
	...

----------

Any comments?

James

----- ___                       - James Aldridge, Senior Network Engineer,
---- /    /   /  ___  ____ _/_ -- EUnet Communications Services BV
--- /--- /   / /   / /___/ /  --- Singel 540, 1017 AZ Amsterdam, NL
-- /___ /___/ /   / /___  /_ ---- Tel: +31 20 530 5327; Fax: +31 20 625 5913
-                           ----- 24hr emergency number: +31 20 421 0865