LIR-WG Action LIR-34.8 - Additional values for the inetnum status field

Better late than never, here is a slightly modified version of my proposal
(originally posted before RIPE 34) for an additional value for the status
field in an inetnum object (specifically "status: LIR-ALLOCATED").

James

----- ___                       - James Aldridge, Senior Network Engineer,
---- /    /   /  ___  ____ _/_ -- EUnet Communications Services BV
--- /--- /   / /   / /___/ /  --- Singel 540, 1017 AZ Amsterdam, NL
-- /___ /___/ /   / /___  /_ ---- 
-                           ----- Tel: +31 20 530 5327; Fax: +31 20 622 4657

---------- cut here ----------

         "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 may help to explain things at this point:

     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
     ...
     source:    RIPE

     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:    EUNET-MNT
     mnt-lower: EUNETZZ-MNT
     ...
     source:    RIPE

     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:    EUNETZZ-MNT
     ...
     source:    RIPE

Here the  first  inetnum  object  refers  to  the  top-level
allocation  made  to  a local IR by the RIPE NCC and has the
normal  RIPE-NCC-HM-MNT  maintainer  field  which  restricts
changes  to  the  RIPE  NCC  Hostmasters  only.   The second
inetnum object is registered by the central administrator of
the  local  IR  and  the  normal  maintainer object for that
administrator - EUNET-MNT in this case.   There  is  also  a
mnt-lower  field  permitting  the  national administrator to
whom this sub-block  is  "allocated"  to  register  end-user
assignments.    The  last  inetnum  object  here  is a final
assignment from the national organisation to a customer.