Operational Contacts

Sorry, if my comments should be not completely coherent and a bit long...

  >   > Arnold Nipper <nipper at 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

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).

  > 	No, proceed as agreed in Paris.
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 at 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 at 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 at 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.