Re: Who should do entries in RIPE database?

["Wilfried Woeber, UniVie/ACOnet" <]

  Folks,
  
  thanks for bringing this up for discussion!

>The other point is to prevent the RIPE database from further pollution.
>There should be some settings to guarantee this. What is your opinion:
>should I post my suggestions just to 'lir-wg@localhost 'db-wg@
>ripe.net' or in addition also to 'local-ir@localhost

  I'll try to summarize from my point of view (both as DB-WG chair,
  Local-IR rep and of course as a dumb user :-)
  
  We have long since worked from the assumption that the "owner" of an
  object is responsible for it's on-going maintenance. We have always
  felt, that tigthening the rules too much would have a negative impact on
  all parties' willingness to register (at all) or to perform updates
  regularly.
  
  Then we introduced measures to protect *existing* objects by limiting
  the sources where updates (+ deletes :-) are accepted from (maintainer
  mechanism). This is particularly relevant for the IP Registry and for
  the Routing Registry.

  The next step has been protection of hierarchies in the object space
  with the mnt-lower mechanism, in particular for the Domain-Registry. 

  Right now the Routing-WG and the NCC are working on the implementation
  of cross-notification for the routing registry.
  
  All of these mechanism can by now (or very soon) be used to ascertain a
  useful level of security and update control, including the referenced
  objects.
  
  This leaves us with two major weaknesses - or features:
  
  - A considerable percentage of the objects is not yet protected by the
    mechanisms which are readily available, 
    and "tightening" the ropes requires a more careful approach by the
    various registries - leading to more work, in the end. 
    In particular if we think about "owning" and protecting the person
    objects as referenced by data for the various registries....
    
  - Nothing is there to prevent *any* party to put e.g. person objects
    into the DB. (And I certainly appreciate that myself!)
    Also, I suppose some other types of objects can be put into the DB
    without problems, unless they are in dircet conflict with one of the 
    well-managed object spaces for a particular registry.
    
  This leaves us with a legacy of entries from the "Dark Ages" of DB
  deployment and with the on-going pollution of object space by way of
  "user error". 
  This aspect is being addressed by the DB-Consistency Project. We work
  towards offering mechanisms to identify inconsistencies as described by
  a "catalogue of frequent problems" as well as by coming up with the
  logistics to repair these deficiencies. Again, to be successful, the
  registries shall be required to spend (considerable?) effort to
  participate in that activity.
  
  So what can be done on top of that to improve the situation?
  
  - We can offer improved mechaisms to deal with identification and
    authentication: this is on the agenda for the DB-Security Task Force.
    
  - We can try to improve the user interface. 
    In particular to help the end-users to avoid the popular crimes like
    putting in just another person object as soon as there's a new
    reference: We (the AT-TLD administration) are in the process of
    designing and prototyping an interactive interface that should prevent
    most of these incidents.
    We're in contact with the NCC to determine the usefulness of that
    approach. Please stay tuned.
    
  - Last but not least we could think about "closing" the DB for public,
    that is anonymous, update or registration of objects. I think *that*
    would require *very* careful consideration, discussion, and
    establishing a broad consensus across (all of) the RIPE-WGs. 
    I'd also expect considerable impact on activities like RIDE.

    But it is certainly not impossible to get that discussion going.
    Although (wearing no hat at all right now :-) I do not see a pressing
    need right now - taking into account that we have a set of mechanisms
    in the works to improve the situation.
    
  Comments and input welcome!

  Apologies for the lengthy speech...
  Wilfried.
 --------------------------------------------------------------------------
  Wilfried Woeber                :  e-mail: Woeber@localhost
  Computer Center - ACOnet       :  
  Vienna University              :  Tel: +43 1 4277 - 140 33
  Universitaetsstrasse 7         :  Fax: +43 1 4277 - 9 140
  A-1010 Vienna, Austria, Europe :  RIPE-DB (&NIC) Handle: WW144
 --------------------------------------------------------------------------