Operational Contacts

...
  >We should soon introduce this new NOC object. If for example a service provi
der
  >wants to give support to all his customer networks, all three attributes hav
e
  >to be added to a lot of networks. And then the phone number changes ...
  >Don't waste time.
The entry was meant the other way round. Not the service provider registers
its operational contacts, but the network owner has a chance to register
his general operational contact there. I do see a point in Arnolds remark,
that the situation is twofold (at least):

<any_internet_user>----------<service_provider>------------<customer>

If net of <customer> has problems, <any_internet_user> wants to identify
someone to troubleshoot them. The most natural point to contact is
<service_provider>, so <service_provider> should be registered as general
POC for the network. But if <customer> has problems, and <service_provider>
wants to contact <customer>, the appropriate information can be stored
in the general contact information as well. Pls keep in mind, that this
contact information doesn't supersede the named [at]c's in the objects,
but will provider general contact point if the specific poeple are not
reachable. The *om: can be used for generating e-mail lists by
a service provider to communicate trouble ticket or configuration changes...

The twofold meaning above can't be solved with introduction of a NOC object.
A solution would be, that <service_provider> keeps customer information aside
RIPE DB entries (most of the sp already do).

As a NOC object doesn't solve the problem, my vote is:

Go ahhead with the lightweight approach and lets invent a NOC object to
be introduced in the future.

	Andreas Schachtner