LIR-ALLOCATED revisited

LIR and DB Working Groups (with apologies for duplicate email),

Discussed  at  RIPE-34 but with little subsequent action, I would
like to repropose the addition of LIR-ALLOCATED as a valid status
value  for  inetnum  objects in the RIPE database.  Attached is a
slightly revised version of  the  document  ("troff  -ms"  source
version   available   on  request)  I last posted a year ago as a
result of LIR-WG Action  LIR-34.8.   The  suggestion   then   was
that   this  could  be massaged into a RIPE document (I think dfk
volunteered!)  to update  ripe-185  (European  Internet  Registry
Policies  and   Procedures)   and   that   support  for  the  new
value be added to the database (and NCC tools as necessary).

Regards,
James

-- 
Senior Network Engineer, IP Archictecture Group, KPNQwest
Singel 540, 1017 AZ Amsterdam, NL

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

         "Status: LIR-ALLOCATED" Considered Useful

                       James Aldridge
                       ----- --------

          This  document  proposes  a new value for the
     status field of the inetnum  object  in  the  RIPE
     database  in  addition to those listed in sections
     3.4.2  (PA  vs  PI  space)  and  4.4   (Allocation
     Registration)  of  the "European Internet Registry
     Policies and Procedures" document ripe-185.

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

                             -2-

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:    REGY-MNT
     mnt-lower: REGYZZ-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:    REGYZZ-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 - REGY-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 final  inetnum  object  here  is  a  final
assignment from the national organisation to a customer.