CURRENT_MEETING_REPORT_
Reported by Dan Long/BBN
UCP Minutes
Agenda
o Introduction to UCP Working Group:
- What is it? What's been done so far?
- Discussion of Matt Mathis' National Trouble Ticket Tracking
writeup.
- Discussion of some operational issues by MERIT.
- What's Next?
Dan Long (Chair) presented a brief history of the UCP Working Group:
o FSU IETF: Initial discussion
- Structural proposals presented
- Refine goals/scope
- Writeups by Craig, Elise, & Martyne
o PSC IETF: Definition of terms:
- NSC (Network Service Center)
- P1 (user<->NSC communication protocol)
- P2 (NSC<->NSC communication protocol)
- Writeup by Matt
Matt Mathis (PSC) reviewed his description of a National Trouble Ticket
Tracking system. A lively discussion ensued about various aspects of
the proposal including:
o How do you define ``closure with the user'' (as in ``a ticket is a
contract to obtain closure with a user'')?
- What do you do about uncooperative NOC's?
- What do you do when you cannot satisfy the user due to
funding/engineering constraints?
- Transfer of a ticket is a mechanism for obtaining closure and
resolving the problem. We should acknowledge that certain
problems can't be closed in a technical sense. This may be
sufficient for closure with the user.
o What are the organizational implications of declaring a ticket to
1
be a ``contract''?
- Does that mean the NSC must respond to any old barage of
(nuisance) questions?
- Can an organization commit to adhering to this system without
knowing the expected demand?
o How are NSC's ``certified'' (as in ``NSC's must be certified at
least as far as adherence to the rules described in this
document'')?
- We don't want to be (or can't be) coercive.
- Needs some element of informal (polite) coercion rather than
legal coercion. The problem is to get somebody to start owning
the problem and a way of recording where the problem lies.
- Makes more sense to have the system be so useful that everyone
will want to join and conform.
- Certification should only be that the NSC's adhere to the
ticket hand-off protocols. Details of P2 protocol need to be
fleshed out by the person who sets up the TTC.
o What about peer-bashing (i.e., pointing fingers, blaming,...)?
- It's self-regulating (...glass houses...stones...).
- Would a national ombudsman be reasonable?
o What about lots of users complaining about the same problem?
- Have multiple user dialogs cross referenced with a single
``problem'' which has the other dialogs.
- Closure should be obtained with each user.
- We do want to track each caller so we know how many complaints
there are.
o What about privacy of ticket information?
- Tickets should be readable only by the owner and the ticket
arbitrage center (TAC).
o What do you do with the Engineering Dialog results?
- If the Engineering Dialog results in suggested improvements,
how do those get handled?
- Does everyone who hears about the suggestions understand the
possible implementation obstacles?
Dale Johnson (Merit) led a discussion on some aspects of this system not
covered in the document:
o Any national Ticket Tracking system will have to be used in
conjunction with local systems. For large sites which have
elaborate highly customized systems of their own, this might
require software to automatically copy tickets between the local
and national system. Making the national system available for all
networks' local tickets could simplify operations for many NOCs,
2
although this could result in an extremely expensive national
system. If the national system was freeware or was reasonably
available, then NOCs could at least use the same software for both
their local and national tickets.
o NSC's still need the tools to do the diagnosis. Especially
important is contact information for different network entities.
The NNSC Phone Book may help solve this problem. Contact
information should be both published and online.
o The NJM Working Group has started discussing common data formats
and access mechanisms for the routine (SNMP and other) data that
NOCs collect. Access to this kind of data from other networks
could become very useful when a NOC tries to debug a complex
problem outside of its own jurisdiction, or when another entity
wants to aggregate or contrast data from different NOCs. NJM will
continue with this project, but noted that this might also be
interesting to the UCP group because it is a form of inter-NOC
communication.
o How can we alert network users about outages, both planned and
unplanned? How about an X.500-based (or DNS-based) posting system
that people (and network utilities?) can query to determine the
operational status of various network components? There was a fair
amount of discussion about a low-tech short-term solution involving
a standard format for problem reports posted to the NSR mailing
list. The thought was that these standard reports could then be
automatically collected for occasional perusal/reference by NSC
staff.
Action Items
o Matt - will redraft with the suggested changes from the discussion:
- No compulsion; be neutral
- Privacy; tickets readable only by owner and TAC
- TAC will mention the ombudsman role
- Omit details of ticket format (for now)
- Need requirements for TTC
- It's ok for 1 ticket to have multiple user dialogs
o Dan/Craig - will clean up draft & submit into the FYI RFC pipeline
- Check FYI RFC standards to be sure that the ``2 voice'' format
is acceptable
- Provide copy of draft to FARNET's September meeting
Timetable Through 1990
August Matt will present revised draft; UCP group to
comment
3
September Dan/Craig will incorporate comments, and prepare
draft for presentation to FARNET and submission to
FYI RFC pipeline
October/November Collect comments and refine proposal.
December At IETF meeting, discuss deployment/future plans
Attendees
Stephen Adams decwrl::``adams@zeppo''
Eric Carroll eric@utcs.utoronto.ca
Carol Farnham carolf@mcescher.unl.edu
Dale Finkelson dmf@westie.unl.edu
Vince Fuller fuller@jessica.stanford.edu
Steven Hubert hubert@cac.washington.edu
Dale Johnson dsj@merit.edu
Ken Jones uunet!konkord!ksj
Dan Long long@bbn.com
Matt Mathis mathis@pele.psc.edu
Berlin Moore prepnet@andrew.cmu.edu
Donald Morris morris@ucar.edu
Craig Partridge craig@nnsc.nsf.net
Dana Sitzler dds@merit.edu
Allen Sturtevant sturtevant@ccc.nmfecc.gov
Carol Ward cward@spot.colorado.edu
Robert Woodburn woody@saic.com
4