Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!utgpu!water!watmath!clyde!cbosgd!ucbvax!SRI-NIC.ARPA!tcp-ip-RELAY From: tcp-ip-RELAY@SRI-NIC.ARPA.UUCP Newsgroups: comp.protocols.tcp-ip Subject: (none) Message-ID: <8711251057.AA13866@umix.cc.umich.edu> Date: Tue, 24-Nov-87 22:11:18 EST Article-I.D.: umix.8711251057.AA13866 Posted: Tue Nov 24 22:11:18 1987 Date-Received: Sun, 29-Nov-87 04:31:18 EST Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 28 , hedrick@ARAMIS.RUTGERS.EDU, trewitt@Miasma.Stanford.EDU, tcp-ip@SRI-NIC.ARPA, netman@Amadeus.Stanford.EDUgwmon: Date: Tue, 24 Nov 87 19:11:18 PST To: userID=DUM1@SFU.MAILNET, hedrick@ARAMIS.RUTGERS.EDU, trewitt@MIASMA.STANFORD.EDU, tcp-ip@SRI-NIC.ARPA, netman@AM Subject: Re: Network Management Charles, Thank you for clearly stating your views. I agree that any path is going to take a lot of work. It would be best if we all could get on with the "work" to be done. The characterization of the vendors who are favoring the CMIS approach is best described as "end system vendors" as opposed to "gateway vendors". They see their customers as drowning in network "administration" details in addition to netowrk "management" details. A few years back you (and I) were running timesharing systems and we did that with a ton of software and human procedures that were tightly integrated (evefn if by dint of hard work and numerous kludges that remained invisible to our customers). The joy of networking has stripped managers of that tight integration of administrative tools. Dealing with routing protocol misbehaviour is only the tip of the iceberg (even if that tip will still sink the largest ship someday). So, end users need to have their entire "computing facilities" managed. I think that is what this group of vendors is wrestling with. I hope all parties can find a way to combine efforts for the benefit of all users. After all, satisfied users are the lifeblood of us all. Dan -------