draft minutes, DB-WG meeting, RIPE-23, Jan.96, Amsterdam

 Dear all,

 regarding the discussion of a "NOC" object:
> Message-Id: <9603081902.AA08048 at ncc.ripe.net>
> Subject: Re: draft minutes, DB-WG meeting, RIPE-23, Jan.96, Amsterdam
> To: woeber at cc.univie.ac.at (Wilfried Woeber, UniVie/ACOnet)
> Date: Fri, 8 Mar 1996 19:01:44 +0000 (GMT)
> Cc: db-wg at ripe.net, woeber at cc.univie.ac.at, ncc at ripe.net
> From: Michael Behringer <M.H.Behringer at dante.org.uk>
> 
> [...]
> >   The Role: or NOC: object needs more thought and detailed definition.
> >   There is still some uncertainty whether a full-blown new object (with a
> >   handle) is really needed, or whether the person object can be extended.
 [...]
> 
> >From my perspective: I do not really *need* the role object. If this object
> will not be implemented, we will find some sort of a workaround by using
> comments in a person object. Then we would define a person "XY-NOC" for
> example, address and such is obvious, and the additional information we need
> will be put into the comment fields, using our own sub-definition, ie,
> we would put essentially the same thing I proposed into the comments, and
> only the parser would need to be different. Not nice - but it does the job.
> 
> The reason why I am pursuing this here though is that I think that the 
> role object is really missing in the DB. And I get back to the same old 
> example: When someone is leaving a company, and the route/AS/other objects
> containing this person are not updated, it looks like the AS/route/other is
> maintained by someone from a different organisation. And you have to make 
> changes in all objects that refer to this person. 
> 
 From my daily experience I can only follow Michael - a NOC-object (or similar)
 would be extremely handy. I have some overview of data regarding contacts
 from our networks: we generate an internal mailing list from the contact
 information and see pretty well from the "undeliveries" how many are valid.
 The weekly rate of changes is around 1-2%. These changes are
 * Some of the persons just change their mail addresses but stay with their
   organization. Most of these can be handled because we urge people to use
   mail addresses like "user at organization.country", excluding hosts, if they
   insist on using personal mail addresses
 * Most of the invalid addresses are caused by people leaving their organi-
   zation. We urge organizations to use local mail fanouts like "group at org.cy"
   (we handle these locally and not via the RIPE database) instead of personal
   mail addresses. These are normally reachable but we do not know if the
   persons are still valid contacts - however, we DO have a valid contact
   mail address.
 * Very difficult to handle are persons who insist on using a personal mail
   address. Quite often we find that they take a new job in another organi-
   zation but keep their original account and mail address (sometimes for
   years)
 I estimate that the contact information is not uptodate for at least 10% of
 the networks. Most of the changes we do on the RIPE database is updating
 person information.
 Therefore, I think it is a very good idea to have a Role or NOC object. This
 does not mean that person objects are less important than before. But having
 this new object makes the data more consistent and uptodate. I also think
 that the implementation is not overly difficult - the Role or NOC object
 shares many components with the maintainer object.
 Regards
    Joachim Schmitz
_____________________________________________________________________________

   For any problem reports regarding DFN-IP, please send your e-mail to
                      >>>>>>   noc at noc.dfn.de   <<<<<<
                        DFN Network Operation Center         
  Rechenzentrum Universitaet Stuttgart, Allmandring 30, D-70550 Stuttgart
  Phone: 0711-685-5810, 0711-685-5576, FAX +711 6787626 (business hours)
      EMERGENCY phone +711 1319 139 with answering machine and pager
                     more info: finger help at noc.dfn.de
_____________________________________________________________________________