CURRENT_MEETING_REPORT_ Reported by Ken England/ Boston University and Karen Roubicek/ BBN Connectivity Tool Demonstrations Metin Feridun made a brief announcement of demonstrations of the ``Connectivity Tool'' that he has been working on. The CT is designed to present a network detective of modest skills with a suite of analysis tools and built-in technique to make the problem of tracking down internet connectivity easier. Last Meeting At the last (first) meeting of UCP-WG, Craig Partridge, Elise Gerich, and Karen Bowers each made presentation of a point of view on modeling the operations of the Internet. Unfortunately, none of these worthy thinkers was able to attend the IETF this time, so the host had to make due with unworthy re-presentations of these ideas and copious reference to notes from postings that these thinkers had made to the ucp list, prior to this meeting. Perhaps the original ideas came across anyway. Craig Partridge's Model Craig Partridge's model was reviewed. Karen Roubicek coined the term ``UCP Central'' to denote the national ``center'' with an 800 number, and this term was extended to include elements of following models. Craig identified at least four elements of an architecture: o UCP Central (the 800 number service) o Site Entity o A User (of this system under study) o A Regional Entity (tentatively put forth for study) Elise Gerich's Model Elise identified some structure within the ``UCP Central Entity'' [note that terminology is deliberately vague, in order to avoid excessive connotative baggage -kwe] In addition to recognizing Site and User Entities, like Craig's model, Elise put some structure to the UCP Central Entity, by postulating: o National Center (we called it UCP Central) o (Six) Regional Centers 1 and corresponding structure. Karen Bowers' Model Unfortunately for us, Karen has left the Internet community and was unable to write up a description of her model. The host was inadequate to the task of recalling her model, but members of the audience who had been impressed by her words last time recalled that Karen had allowed a richer connectivity from Site to Site or from Regional to Regional in her model. Synthesis Some common points arise from these models and beg some questions: We must define a User Entity and consider how these Users, who may be end-users or may be lower level representatives of end-users, such as campus NOCniks; enter this system, how they interact with this system we are defining, and how their problems are staged and addressed. Assumptions of available tools and skills depends on who we assume the User is. We have to consider centralized (UCP Central) versus decentralized (Site/Regional Entity) issues, and clearly delineate responsibilities and interactions. We must consider the authority of the UCP Central and how it is derived. We must consider the nature of the Site and Regional Entities; are they Network Operations Centers, or Network Information Centers, or both, or neither? Let us call these entities Network Service Centers (NSCs) for the moment, and withhold evaluation of what they really are. General Discussion Who is it that owns these facilities? Who are the players; the campuses, the regionals, the backbones, the commercial service providers, etc? How will these entities; these Users and NSCs; be coordinated? How do we resolve problems that the participants in this model cannot solve, such as host interoperability problems? Are there others that must get involved to solve these sorts of problems? We need a means of filtering out chronic problems, ones that have been identified, but are not yet solved, or are unsolvable by our system. 2 Trouble Ticket Systems Trouble ticket systems came up as something that seems to be an integral part of the solution of UCPs. Matt Mathis commented that we need a protocol for managing ownership of trouble tickets, that we need some centralization for dealing with problems (UCP Central), but we must have filters so that UCP Central does not have to deal with too many routine problems. We also need to make sure that tickets don't ``evaporate'' and we could use a meta-UCP protocol for evaluating how well individual UCPs were handled by the system. We also need to discriminate equipment failures from infrastructure or engineering problems, which this system may not be able to handle. We also have to consider how the User is notified of progress on his Ticket. Further Synthesis What can we glean from what everyone has said so far? 1. We need to put a boundary around the problem; around the system we are trying to define. 2. ``Users'' are outside this system boundary. ``Network Service Centers'' are entities that are within the boundary of our system and our model. 3. Users need a ``protocol'' or procedure for how they interact with this system. Let us call this the P1 protocol; User-to-NSC. 4. NSCs need a ``protocol'' or procedure for how they interact among themselves. Let us call this the P2 protocol; NSC-to-NSC. 5. At a minimum, we need to define what a ``User'' is, what an ``NSC'' is, and what the P1 and P2 protocols are. Work in this direction will undoubted lead to further modeling requirements. We need to consider at least these steps in the process: o diagnosis of the problem o the resolution process o closure o connectivity versus interoperability problems Someone described the AT&T trouble ticket model, and noted that the person in the system that was ``closest'' to the end-user was responsible for updating the user on progress and for closure, but that the ticket database was centralized and centrally managed. There was discussion of the P2 protocol and how it related to lines of authority and contractual relationships. There was a feeling that an instatiation of a P2 link between two NSCs was an agreement to work together in a certain way on UCPs. The handling of a ticket between NSCs is bi-lateral. Should NSCs be certified to generate tickets? Should they be certified to accept 3 tickets? Would one level of NSC be a ``generate only'' NSC while other NSCs could be ``accept/generate'' NSCs? Every contact from a User (via the P1 protocol) must be logged and tracked by this system. The system must be conservative, it must not lose track of any calls (tickets) and it must reach closure on each ticket. What constitutes closure? All closures must be reported back to the User (via P1) and the User must be able to get status reports as the User requires (again via P1). What are the minimum capabilities of an NSC? They should include: o contact points (phone numbers, e-mail addresses, ...) o hours of operation (when can the NSC be activated?) o what do they do (ie, level of functionality) o referrals (where do they refer UCPs via P2?) o closure (they must be able to close open tickets via P1) el Chiappa jnc@PTT.LCS.MIT.EDU Steve Deering deering@pescadero.stanford.edu Dave Forster Richard Fox sytek!rfox@sun.com Karen Frisa karen@kinetics.com Steve Hubert hubert@cac.washington.edu Van Jacobson van@helios.ee.lbl.gov Stev Knowles stev@ftp.com Yoni Malachi yoni@cs.stanford.edu Keith McCloghrie sytek!kzm@hplabs.HP.COM Leo J. McLauglin III ljm@twg.com Jeff Mogul mogul@decwrl.dec.com John Moy jmoy@proteon.com Mike Patton MAP@LCS.MIT.EDU Drew Perkins ddp@andrew.cmu.edu Stephanie Price cmcvax!price@hub.ucsb.edu Michael Reilly reilly@nsl.dec.com Greg Staz satz@cisco.com Tim Seaver tas@mcnc.org Frank Slaughter fgs@shiva.com Richard Smith smiddy@pluto.dss.com Brad Strand bstrand@cray.com Cal Thixton cthixton@next.com John Veizades What is the role of UCP Central on routine UCPs? Should UCP Central get copies of all tickets from all NSCs? Should UCP Central be primarily mail based, as far as tracking tickets? What is the nature of a ticket? The ticket must be structured such that it leads to a proper analysis of the problem. This implies a certain minimum of information. Can tickets be structured to include fields, as in a database? Guy Almes made the point that in talking about a distributed trouble ticket system, we are essentially trying to create a distributed database system. Perhaps we can glean some insight on how to structure P2 and create a coherent distributed trouble ticket system from distributed database design? Can we create a trouble ticket grammar? Should the trouble tickets be textual, so that they can be moved via mail, not requiring a database query language or other special protocol? Educating End Users Martyne Halgren of Cornell contributed a memo to the ucp list prior to this meeting, addressing issues regarding educating end-users, and described NETHELP and NETLEARN tools to accomplish the education process. Unfortunately, the entire session needed to be devoted to a discussion of the larger picture, and there was no time to delve into the end-user part of the model. Martyne's contribution was held for follow-up discussion at a later time. 4 Session Closure The host outlined a minimum of three things that need work: o NSC Requirements o the P1 protocol o the P2 protocol The host twisted arms: Matt Mathis agreed to work on NSC requirements, the P1, and the P2 protocols. Guy Almes agreed to work with Matt on the P2 issue. Dan Jordt also indicated willingness to contribute. Follow-up discussion and postings of work in progress will be to the ucp list ``ucp[-request]@nic.near.net''. 5 ATTENDEES Guy Almes almes@rice.ed Glee Cady ghc@merit.edu Tom Easterday tom@nisca.ircc.ohio-state.edu Kent England kwe@bu.edu Metin Feridun mferidun@bbn.com Martyne Hallgren martyne@tcgould.tn.cornell.edu Gene Hastings hastings@psc.edu Tom Holodnik tjh@andrew.cmu.edu Wendy Huntoon huntoon@a.psc.edu Dan Jordt danj@cac.washington.edu Marilyn Martin martin@cdnnet.ca Matt Mathis mathis@pele.psc.edu Berlin Moore prepnet@andrew.cmu.edu Donald Morris morris@ucar.edu Dave O'leary oleary@noc.sura.net Lee Oattes oattes@utcs.utoronto.ca Mike Patton map@lcs.mit.edu Marc-Andre Pepin pepin@crim.ca Paul Pomes paul-pomes@uiuc.edu Karen Roubicek roubicek@nnsc.nsf.net Jim Sheridan jsherida@ibm.com Dana Sitzler dds@merit.edu Pat Smith psmith@merit.edu Mary Stahl stahl@nisc.sri.com Louis Steinberg louiss@ibm.com Allen Sturtevant sturtevant@ccc.nmfecc.gov Edward Vielmetti emv@math.lsa.umich.edu Carol Ward cward@spot.colorado.edu Aileen Yuan aileen@gateway.mitre.org 6