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