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