Tagging of IP adresses / Application-Database

=> >> back to basics:  The only thing I wanted was an attribute
=> >> which said "SMTP connections from these IP numbers shouldn't happen"

  Yup, that was where it came from :-)
  And we are grateful to you for seeing this "spark" to get the whole
  discussion going!

=> >
=> >'overloading' of the current IP-Database with additional, 
=> >basically unrelated informations was not wanted.
=> 
=> Rather than bloat the idea to that size, I thing I'd rather drop
=> the proposal then.
=
=Ok, that would be the easiest way to get this issue done, sort of...

  Well, from the "users'" point of view, the innards of the implementation
  shouldn't be that important ??

>On the other hand, the administrative overhead
>for the IP-Database with tags as extensions 
>is likely to be at least the same
>as for a new, separate database.

  During the various discussions we hit a few interesting aspects
  (non-exhaustive list):
  
  - people do have a broad set of ideas what they woukd like to see
    documented. From dial-up use of IP addresses to "golden" networks for
    registry servers or root NS, to web-cache sites/peerings, to IPv6
    tunnels...
    
  - the problem of over-loading existing objects, both schema-wise as well
    as maintainance-wise. E.g., for a larger ISP there's a good chance that
    the LIR staff wouldn't want to/be able to maintain application level
    entries...
    
  - the problem of authority for the data.
    We do have "over-loading" already, within the RIPE-DB. 

    . I.e. the DB is (formally) authoritative for IP numbers, 

    . it's a "reasonable" place to offer a routing registry service, but
      with much less (formal) authority attached by the NCC

    . it's offered/used as a repository for DNS data, discussion has
      started if "authority" for that subset should be moved to CENTR

    . an application type registry probably needs some sort of
      environment. Learning from DNS, I suppose the NCC is very reluctant
      to spend implementation effort unless we can come up with a model
      for use, authority and - eventually - funding.
      
  But, this list is emphasising the potential stumbling blocks...

  I'd be much more interested in proposals on the use and setup, how to 
  maintain the data, how to derive and attach credibility, and the like.
  
  The floor is your's!
  Input, please!
  
  Wilfried.
 --------------------------------------------------------------------------
  Wilfried Woeber                :  e-mail: Woeber at CC.UniVie.ac.at
  Computer Center - ACOnet       :  Tel: +43 1 4277 - 140 33
  Vienna University              :  Fax: +43 1 4277 - 9 140
  Universitaetsstrasse 7         :  RIPE-DB (&NIC) Handle: WW144
  A-1010 Vienna, Austria, Europe :  PGP public key ID 0xF0ACB369
 --------------------------------------------------------------------------