[ih] inter-network communication history

John Day via Internet-history internet-history at elists.isoc.org
Fri Nov 8 09:20:36 PST 2019

You told me once the implementation was smaller. Also, I also know from Randy Presuhn that the CMIP implementation was smaller than SNMP as well.  It seemed that lexicographical order takes more code that object-oriented.  For me, HEMS would have been a better way forward.  A few years earlier IEEE 802 had tried a protocol like SNMP and found it inferior, which is why CMIP was done.  Also that HEMS used TCP for request/response and UDP for events was simply sane, rather than trying to do everything over UDP. In which case, GetNest is unnecessary. The inability to get a snapshot of anything large-ish was a real problem.

A further advantage would have been had by CMIP since it could use the Packed-Encoding Rules for ASN.1 rather than having to use the Basic Encoding Rules wired into SNMP.  PER was sufficiently efficient that often compressing a PER encoding was larger.

I always got a good laugh that SNMPv1 was insecure as argued by certain router vendors. It would be okay for monitoring but not for configuration. Of course, strictly speaking, it was insecure. (My rejoinder was, Isn’t ASN.1 an encryption algorithm?) ;-)  Their solution was a telnet connection with passwords in the clear. Almost no one had an ASN.1 compiler but every PC had a telnet program. Hilarious.

> On Nov 8, 2019, at 11:44, Craig Partridge <craig at tereschau.net> wrote:
> Hi John:
> Thanks for the nice words about HEMS!
> It is hard to make the assessment of which would have been more simpler and smaller now, some 30 years later, but since this list is about rethinking and understanding the past I'll take a swing at it.
> Both HEMS and SNMP had similar MIB structures -- a named tree with data formatted in ASN.1.  Both would have required similar amounts of software to locate, manage, and configure MIB variables.  Not surprising as SNMP was designed to be a stripped down HEMS.  So the issue is how much the features that SNMP stripped out of HEMS came back to bite the SNMP implementers.  Clearly proxies, which HEMS handled seamlessly, required more code in SNMP.  Also HEMS handled private MIBs seamlessly (you just added your private variables to the MIB -- HEMS leveraged ASN.1 to make those variables self-describing), while incorporating private MIB definitions is a continuing pain for SNMP management stations.  But HEMS had a (simple) language interpreter that SNMP did not and a much richer system for traps.  In the balance, I'd guess management station code for SNMP would be bigger and more complex and that SNMP on the managed device would be about equal except for the simplest of devices (where SNMP would win).  Your mileage may vary.
> Thanks!
> Craig
> On Fri, Nov 8, 2019 at 8:00 AM John Day <jeanjour at comcast.net <mailto:jeanjour at comcast.net>> wrote:
> And from what I understand, the HEMS implementation turned out to be simpler and smaller than the SNMP implementation.
> > On Nov 8, 2019, at 09:56, Craig Partridge via Internet-history <internet-history at elists.isoc.org <mailto:internet-history at elists.isoc.org>> wrote:
> > 
> > Hi Jack:
> > 
> > You're crossing network management streams.
> > 
> > SNMP had nothing to do with NMP except, perhaps, some influences on Marty
> > Schoffstall.  You are probably thinking of HMP (Host Management Protocol).
> > 
> > Around 1983, network management work at BBN started going down two paths.
> > One was the stuff that Hinden's team was doing for the NOC.  The other was
> > Jil Wescott's distributed network management system (I think called NOMS?)
> > with Charlie Lynn and I think Ross Callon and Karen Seo and, briefly me,
> > working on it.  Then DCA funded a large project (name I've forgotten)
> > trying to build a better suite of tools (but not protocols as I recall) for
> > the MILNET NOC. That work never made it out of BBN.
> > 
> > In 1987, NSF realized the cupboard for multi-vendor network management
> > protocols was bare.  Steve Wolff asked me to come up with a solution, which
> > become HEMS and was based on my experience with NOMS and discussions at
> > IETF and some great ideas from Glenn Trewitt (who had been dealing with
> > Stanford's substantial internet).  Jeff Case and Marty Schoffstall (and
> > others) felt HEMS was too complex to deploy ASAP (and ASAP was the need --
> > NSFNET was growing like topsy) and devised SGMP (Simple Gateway Management
> > Protocol) which the IETF then evolved into SNMP.
> > 
> > Thanks!
> > 
> > Craig
> > 
> > 
> > On Thu, Nov 7, 2019 at 4:33 PM Jack Haverty via Internet-history <
> > internet-history at elists.isoc.org <mailto:internet-history at elists.isoc.org>> wrote:
> > 
> >> On 11/7/19 1:35 PM, Vint Cerf wrote:
> >> 
> >>> Don't forget CMIP, HEMS AND SNMP
> >> 
> >> Hmmm.   Well, what I remember is:
> >> 
> >> SNMP was instantiated as a first step toward a comprehensive NMP
> >> (Network Management Protocol).   As I recall, NMP was more of a concept
> >> than a protocol.  It was an umbrella covering a lot of pieces.
> >> 
> >> As we were struggling to make the Internet 24x7, we did a lot of
> >> cogitating about what it meant to manage a network, which went well
> >> beyond basic real-time monitoring and control.   In addition to the
> >> Internet "core gateways", at BBN we were managing and/or operating a
> >> variety of networks, so we had a fairly broad view of the issues that
> >> crop as you operate and evolve networks over 5 or 10 years.
> >> 
> >> One dimension of that exploration was into life-cycle management.  That
> >> involved things like how to measure traffic statistics and patterns,
> >> identify and predict trends, plan for topology alterations to handle
> >> future traffic, plan for changes needed to add new users or
> >> applications, etc.
> >> 
> >> It also included operational disturbances.  How do you deploy a new
> >> major software release without disrupting users' activities?  How do you
> >> add a large number of new users with a new application without
> >> disrupting current activity?   How do you debug problems, without
> >> disrupting other users?
> >> 
> >> In the DDN context, a memorable one of those was the release of a major
> >> new IMP version.  To make that run smoothly, we had to create a lot of
> >> mechanisms and processes even beyond those needed within the IMPs
> >> themselves to smoothly convert to the new release.  E.G., we created a
> >> service product called "TestNet" which allowed systems integrators to
> >> test and debug their software in the new environment via a dial-up link
> >> and get it all running smoothly before going live in the users'
> >> environment.
> >> 
> >> I recall one motivation for that was some Army system -- the one that
> >> provided payroll services and issued the soldiers' checks.  If it didn't
> >> work the week after the software transition.... well, those guys have
> >> some serious capability to protest such disrespect.
> >> 
> >> At one point an ARPANET clone was involved in the systems that are used
> >> by the officers at points of entry into the US.  When something was
> >> wrong... well, it seemed like having a BBN identifier on your paperwork
> >> made you much more likely to be randomly selected for extra scrutiny at
> >> the airport.
> >> 
> >> Another dimension of network management was into management of resources
> >> - i.e., respecting the "boundaries" Dave mentioned.  This came up in the
> >> context of SATNET and the VAN Gateway (ARPANET connected to the public
> >> X.25 world).   Whoever owned something, and paid for its operation,
> >> wanted it used for their purposes only.   So ARPA research traffic could
> >> use SATNET, but other stuff should use the X.25 service (and getting the
> >> bill to go to the right place depended on quirky details like which side
> >> "dialed the phone" to establish the X.25 connection between gateways.)
> >> In the technical environment, this requirement appeared as "policy
> >> routing" and related technologies, protocols, etc.
> >> 
> >> Resource management extended into the security world as well, i.e.,
> >> making sure that only authorized "people" (humans, computers, software,
> >> whatever) were able to access only the appropriate resources.   It also
> >> impacted functionality like TOS - how do you make traffic go down the
> >> most appropriate path for the kind of service it required.
> >> 
> >> All of that kind of "management" was folded under "Network Management".
> >> It was, and is, a huge area.   It went far beyond the basic
> >> monitoring/control of SNMP.  But to get something quickly for the
> >> network we were trying to operate, SNMP was created.
> >> 
> >> SNMP was Simple Network Management Protocol.  I remember we had
> >> discussions about exactly which noun the adjective "Simple" was
> >> modifying.   My thought was that it really should have been Simple
> >> Protocol for Simple Management of Simple Networks - i.e., SPSMSN or
> >> something like that.
> >> 
> >> Anyway, SNMP was an "interim" solution while the larger issues were
> >> sorted out.  I recall that Bob Kahn and I circa 1983 initiated a new
> >> project area called "Automated Network Management" where we would
> >> explore the more esoteric resource management ideas aligned with ARPA's
> >> charter.  We also put together (got funded) projects from several of the
> >> various "operational" clients we had, who were pretty desperate for
> >> near-term pragmatic tools to help them manage their own stuff (those
> >> research guys never write the Users' Manual!).   All of that combined
> >> would make a foundation project for further NMP development.
> >> 
> >> Sometime in late 1983, I lost track of the "NMP" work.   BBN reorganized
> >> and those various projects and contracts ended up scattered around to
> >> different divisions after the upheavals settled.  I think that
> >> separation of the  "research" and "operational" worlds might have had a
> >> noticeable effect on the history of the Internet, by breaking the
> >> "pipeline" from research to operations that Vint started when he moved
> >> the gateways to become 24x7 services.
> >> 
> >> I don't know anything about HEMS.  It may be what later came out of the
> >> Automated Network Management project as a protocol part of NMP, but I'm
> >> not sure if it ever got deployed or transitioned and used in any of the
> >> operational network environments.
> >> 
> >> I know even less about CMIP.  I could never get my teeth into ISO
> >> technology.  There wasn't any code to play with, and every time I tried
> >> to read those stacks of documents I'd fall asleep.
> >> 
> >> Fun times though,
> >> 
> >> /Jack Haverty
> >> 
> >> 
> >> 
> >> --
> >> Internet-history mailing list
> >> Internet-history at elists.isoc.org <mailto:Internet-history at elists.isoc.org>
> >> https://elists.isoc.org/mailman/listinfo/internet-history <https://elists.isoc.org/mailman/listinfo/internet-history>
> >> 
> > 
> > 
> > -- 
> > *****
> > Craig Partridge's email account for professional society activities and
> > mailing lists.
> > -- 
> > Internet-history mailing list
> > Internet-history at elists.isoc.org <mailto:Internet-history at elists.isoc.org>
> > https://elists.isoc.org/mailman/listinfo/internet-history <https://elists.isoc.org/mailman/listinfo/internet-history>
> -- 
> *****
> Craig Partridge's email account for professional society activities and mailing lists.

Internet-history mailing list
Internet-history at elists.isoc.org

More information about the Internet-history mailing list