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.