CURRENT_MEETING_REPORT_
Reported by Dan Long/BBN and Karen Roubicek/BBN
UCP Minutes
Summary
The UCP meeting consisted of a discussion of the UCP Internet Draft.
Some of the discussion was to clarify aspects of the draft. The main
issue that arose is the obligation for an NSC to accept calls from
anyone on any subject. It was agreed that an NSC should be allowed to
limit its ``liability'' by referring callers from outside its customer
base or specialty to the ``right'' NSC. The draft will be ammended to
reflect that.
There was also discussion on the issue of the centralized aspects of the
UCP plan--how much monitoring is done by the Ticket Support Center and
which tickets get tracked by the Ticket Tracking System. There was no
consensus on the details but people felt that not all tickets should be
tracked and that perhaps suggesting NSC's produce reports on ticket
activity would be the most we could ``standardize''.
There was a brief discussion on the format/mechanism for ticket handoffs
but it was acknowledged that we really need some operational experience
before suggesting any specifics.
Issues
o Complaints that are dropped between NOC's.
o NOCs that lose tickets.
o Status of problems in design and engineering of networks.
o Statistics on complaints for evaluation.
o Accountability.
Cases
o End host is down.
o MILNET.
o General international connections.
o Anomalous or unexpected routing through experimental networks.
o Telnet options negotiations.
o Vendor software problems.
o General host or applications problems.
1
o Limitations of low-budget implementations.
o Packet filters.
o Lack of complete problem description.
o Kludge requests.
END HOST IS DOWN - example: user called NEARNET to report that unable
to get to andrew.cmu.edu
Two models
1. Nearnet follows through:
user----> |nearnet|-----> cmu
<--- | nsc |<----
2. Pass off to CMU nsc:
user---->nsc---cmu <---> cmu
| nsc
| |
\______________/
It's rare that a campus would be an NSC because they don't want to
track/handle problems outside their campus.
(user services) user -----> campus-----> nearnet nsc
NSC is required to:
o Take ticket regardless of class of problem.
o **agrees to abide by a core set of rules**.
o Implies responsibility for accepting calls and passing tickets.
Organization can have something outside of its organization that can
2
break rules (like saying ``you're not my customer'')
not accept calls <-----> wrong number concern there will be an
overload of calls - e.g.: MERIT
Dana Sitzler: why would a NOC want to be an NSC? What's at the root of
the problem? help users, ``support'' funding agencies
Issue of coercion: If I have to take calls, it becomes a funding issue
Suggest limits on what calls NSC has to take:
o Who must I take calls from?
o What kind of a call must an NSC accept?
________________
NSC customers: peers | | |
nsc's | help | NSC |
|_______|_______|
Help - acts as filter - redirects people to other NSC's
Question of hours or operation: not specified, too variable among
organizations
Store information about NSC's in DNS? (eventually) Start with ASCII file
Need to be sensitive to constraints of NSC's
Need to indicate for each NSC:
o Customer base
o Scope of expertise
True cost is really too great - need to leverage what exists - pressures
regionals to handle more without compensation.
900 number for help?
Only real objection seems to be the requirement to accept all calls
3
Higher Entity - when NSC's can't get closure, have a frustrated user.
But what power does it have?
Text of draft must be revised to recognize:
o Limit scope and customers
o Filter calls
Proposal: NSC's must accept calls from other NSC's but can redirect
non-NSC's to other NSC's.
Format for transferring tickets between NSCs (email?).
o TTS supposed to archive completed tickets, have current status
(which NSC is holding which ticket)
o Can be an archive of a mailing list
o Authorized NSC's get read access
minimum:
To: new-nsc
cc: tts
Subj: Ticket 3076
_______________
_______________
_______________
limitations of this minimum: doesn't address who sees what, timers
Only archive (cc:) inter-NSC tickets?
Doesn't address local NOC support issues (what if problem never gets
to TTS?)
TSC's are supposed to:
Expedite tickets that aren't making progress, according to timers
arbitrate between NSC's act as user ombudsman
Do all the tickets get reported to TSC? No, not intra-NSC ones.
As an alternative, NSC's can do a monthly/weekly report on number of
tickets processed, resolved, etc.,
4
How to clarify service requests:
JimoSheridan:TasomekminimalesettofrrequirementsoforuNSC:ble tickets.
o Provide reporting on tt's.
Gene Hastings: Rather than requirements, should produce guidelines (at
least for publicly-funded organizations) for reporting classes of
problems, monthly summaries, etc.
TSC -- keeps track of handoffs?
Some service centers have better ``clubs'' (i.e., leverage)
Classes of calls:
general info who makes what can't get somewhere who's
responsible for... how address mail performance where is a
resource unexpected routing is ????? online losing packets
protocol X doesn't work application level
Difference between complaint classification vs problem classification
(called in as one thing, but turned out to be another)
Sheridan: can break down classes into 12 (?) types (hardware,
software, connectivity, info, ....)
Reporting recommendations for NSC's - must incorporate into document.
o Jim Sheridan, Gene Hastings, and Dan will draft.
o Is this related to Statistics Working Group?
o Should it be part of monthly report?
o Working Group members will go to OPSTAT meeting and discuss.
To become an NSC, have to agree to rules (define customer base and scope
of expertise).
o Accept calls from users in your base
o Follow-up
o Refer to other NSC (redirect)
5
Should vendors be NSC?
o Sheridan ``no''
o O'Leary ``yes''
Can publish statistics and put pressure on vendors.
Action Plan
1. Make changes to doc that were discussed.
2. Make recommendation about NSC performance statistics.
3. Maybe someone will implement? write code or procedures?
4. O'Leary will start?
Attendees
Vikas Aggarwal vikas@JVNC.net
Kathy Atnip kathy@wugate.wustl.edu
Eugene Hastings hastings@psc.edu
Steven Hunter hunter@es.net
Dale Johnson dsj@merit.edu
Dan Jordt danj@nwnet.net
Darren Kinley kinley@crim.ca
Tracy LaQuey Parker tracy@utexas.edu
Mark Leon leon@nsipo.arc.nasa.gov
Daniel Long long@nic.near.net
Lynn Monsanto monsanto@eng.sun.com
Mark Moody ccmarkm@umcvmb.missouri.edu
Joel Replogle replogle@ncsa.uiuc.edu
Ron Roberts roberts@jessica.stanford.edu
Karen Roubicek roubicek@bbn.com
Daisy Shen daisy@watson.ibm.com
Jim Sheridan jsherida@ibm.com
Dana Sitzler dds@merit.edu
Mike Spengler mks@msc.edu
Bernhard Stockman bygg@sunet.se
Joanie Thompson joanie@nsipo.nasa.gov
6