Let it bleed....

O.k. here is a first draft at the Operational Contacts (4.2) of the
GISD document.  I'm writing from the perspective that this covers
a service providers customers and not NOC contacts (5.1). 

I have some suggestions about section 4.1 (trouble tickets).  First,
I think that there should be some sort of escalation process whether
or not it's a paper based system.  If it is an on-line system,
there definately should be some sort of automated escalation and
notification procedure and the degree of notification should be
more extensive (i.e. auto-calls/page) as demanded by the level of
service.   If there were some mention of statistics on the tickets
to identify chronic problems and staffing inadequacies, it would be
helpful.  I'm not sure if these statistics would be covered in 5.2
or not.  This ties into mean time to repair.  We have a mean time
between failure section.  Should mttr be separate or mentioned here
in the trouble tickets?  And would it be worth mentioning someplace
that there some specific applications developed and in use by some
of the major providers and that some of them will provide their
code on request?  

So, I hope to generate some discussion on this.  I want to stress this
is a first draft (and my first attempt at writing in this type of
arena).  Please be gentle :-)   

klong


4.2. Operational Contacts
What

Operational contacts are data which identify the affiliates of a 
particular internet service provider.

Why

In the course of trouble shooting problems, maintenance or security
issues it becomes necessary to have a method of contact.

Options

It is probable that most service providers would have some sort of
listing or database for the members of their network.  This will
identify the level of detail and the amount of integration that the
different options comprise.  It should be understood that itemized data is
to be progressively incorporated into the next level of service.

-	Text files are kept with only one site contact.  The individual
	items in the text file may or may not include name, postal and
	e-mail addresses, postal shipping address if diffferent,
	phone and fax numbers, domain name and network numbers. 
	Circuit information and provider information is on record.
	Updating information is more re-active than pro-active.

-	A database of information is kept listing a number of contacts
	for different types of services at the site, i.e.: news adminis-
	trator, security, operations, administrative, engineering as
	well as having circuit and related information. 

 	In this particular aspect perhaps the number of contacts might be
	limited to administrative and operational but the information
	is integrated in such a way that it is easily updated and 
	maintained for accuracy.  Periodic verification is done to 
	assure the relevance of the data.

-	A comprehensive database is kept of all aspects of the site activities
	which might include the kinds of services they offer (news
	feeds, listserv and mailing lists, mbone feeds), contacts for
	all services, after hours or emergency procedures, hardware and
	software rev levels on provider maintained equipment,
	demarcation information, circuit and circuit provider
	information.  Frequent verification of data is done to assure
	accuracy. 

SOAP BOX

It is thought that the scale of operation would influence the degree of
detail that is kept by the service provider.  One which has a smaller
amount of affiliates probably cannot afford the staff and level of
management that is required by a service provider with a large number of
sites.  Large operations require a high level of documentation and
frequent verification due to the number of staff members accessing the data.
Ideally, a service provider will know all the aspects of their
affiliates in order to be responsive to their particular needs.