The following is my recollection of the Paris discussion about this:
Andreas Schachtner had proposed to add an attribute to all non-person objects specifying the mailbox of the operational contact points. This had been mailed around on ripe-op before the Paris meeting.
The proposal was discussed and a separate NOC object was proposed in order to prevent duplication of the same data all over the database and have a better mapping with reality. This was considered a too heavyweight soloution for the time being.
We should soon introduce this new NOC object. If for example a service provider wants to give support to all his customer networks, all three attributes have to be added to a lot of networks. And then the phone number changes ... Don't waste time.
Consensus was to add separate optional attributes to all objects except persons for e-mail, phone and fax of the operational contacts. If this gets widely used then introduction of a NOC object and replacement of these attributes by a pointer to it can be considered at a later stage.
I propose the following naming:
ATTR op op-phone ATTR of op-fax ATTR om op-mail
All optional and multiple.
Semantics:
Generic contact information for operational purposes like a common mailbox for the NOC or operations group and/or a NOC hotline etc.
Not intended for duplication of information that can be found via the tc, ac, and zc persons!
Comments?
Daniel
Arnold
Arnold Nipper <nipper@ira.uka.de> writes:
We should soon introduce this new NOC object. If for example a service provider wants to give support to all his customer networks, all three attributes have to be added to a lot of networks. And then the phone number changes ... Don't waste time.
This sounds like re-opening the discussion. Questions: - Do more people feel strongly about this? - Might they even feel strongly enough to circulate a proposal for the NOC object? - Shall we come back on the interim soloution? If there is consensus on the list discussion that (contrary to the Paris consensus) we should proceed immediately and quickly with the NOC object, I am very reluctant to put an interim soloution into place. Please comment on this, even if it is just Yes, reopen the discussion. No, proceed as agreed in Paris. The NCC needs to know what the DB WG wants quickly. Daniel PS: My personal preference is to go ahead quickly with the NOC object but I think this was not the consensus in Paris.
Sorry, if my comments should be not completely coherent and a bit long...
Arnold Nipper <nipper@ira.uka.de> writes:
We should soon introduce this new NOC object. If for example a service provider wants to give support to all his customer networks, all three attributes have to be added to a lot of networks. And then the phone number changes ... Don't waste time.
This sounds like re-opening the discussion. Questions: yes - and I feel that there are quite diverse intentions (and requirements) around, which need to be carefully separated.
- Do more people feel strongly about this? I feel strongly - to be careful about a NOC object, and to get - at least the mailbox part of - the interim solution available soon.
However the most important in my opinion is to make VERY clear what each field in our data base records really is intended and will be used for. The proposed mailbox (phone and fax) field(s) should be used precisely to remove the problem that our current schema just allows for the (wanted!!) personal pointers; having ONLY personal pointers however makes people ask for registering role-specific addresses in their person records (which is wrong and creates conflicts). The fields are optional and should be used only to override "tc" info; I suggest they also should address LOCAL entities. If NOC pointers are introduced it will be neccessarry to clarify the relation between NOC pointers, the various contact person pointers, and the optional operational pointers.
- Might they even feel strongly enough to circulate a proposal for the NOC object? no - not me
- Shall we come back on the interim solution? The "interim solution" IMHO was not intended to emulate a NOC pointer. At least my arguments for having the interim solution - or at least the mailbox field - definitely were not supporting NOC pointers and certainly not to support Arnold's idea.
If there is consensus on the list discussion that (contrary to the Paris consensus) we should proceed immediately and quickly with the NOC object, I am very reluctant to put an interim soloution into place. I think that doing a NOC object will be a very tough task - since that will need to come up with a general modell of what NOCs consist of, what roles they have to offer, and to deal with a broad spectrum of different organizational modells. If the "interim solution" of attaching optional role related mailboxes and phones is to be absorbed by NOC pointer's the NOC modell need to go down as low as specify each parttime postmaster as a NOC while at the upper end you need to care for modelling sizable organisations (just send a mail to postmaster@ DECWRL and see that they require you to decide which mailbox selected from a dozen differnet roles you want to address!)
Also for putting in NOC pointers into objects will need to allow for multiple levels (at least campus NOC ./. regional&service provider!). And we certainly do not want to create a NOC record for each part time postmaster that has defined a postmaster mailbox separate from his personal mail identity!
Please comment on this, even if it is just
Yes, reopen the discussion. NOC object will need serious discussion & work
No, proceed as agreed in Paris.
I also fear that actually some of the demand for NOC pointers actually are meant to document service provider relations (which may call for being modelled in a differnet way from NOC relations). the Paris definition addresses something different from NOCs; a good definition should to be agreed upon and implemented quickly. Some of the problems also might be solved by kludges (?) in using some of the available fields in a different way. I easily could register persons "Domains DE-NIC", "Operator DE-NIC", and the like, and reference them; since the pointer values already are coming from different domains (due to the NIC handle kludge introduce to handle naming conflicts) this would not even be a new kind of abuse of the pointer fields (though of the person name or NIC handle fields). This is not to advocate to start this without coordination. (And I would like to see some syntactic sugar indicating whether a person pointer really is a person name or NIC handle - or something else.) Ruediger Ruediger Volk Universitaet Dortmund, Informatik IRB DE-NIC Postfach 500 500 D-W-4600 Dortmund 50 Germany E-Mail: rv@Informatik.Uni-Dortmund.DE Phone: +49 231 755 4760 Fax: +49 231 755 2386 P.S.: The "Domains DE-NIC" idea seems not too different from what the DDN-NIC whois uses in a few cases; just look at these: whois "dom arpa" Advanced Projects Research Agency Domain (ARPA-DOM) Domain Name: ARPA Administrative Contact, Technical Contact, Zone Contact: Government Systems, Inc. (HOSTMASTER) HOSTMASTER@NIC.DDN.MIL (800) 365-3642 (703) 802-4535 Record last updated on 25-Sep-91. Domain servers in listed order: ... whois \!hostmaster Government Systems, Inc. (HOSTMASTER) HOSTMASTER@NIC.DDN.MIL Attn: Network Information Center 14200 Park Meadow Drive Suite 200 Chantilly, VA 22021 (800) 365-3642 (703) 802-4535 Record last updated on 01-Oct-91.
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
participants (4)
-
Andreas Schachtner -
Arnold Nipper -
Daniel Karrenberg -
rv＠deins.informatik.uni-dortmund.de