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