[ih] A revolution in Internet point-of-view - Was Re: Internet analyses (Was Re: IPv8...)

Greg Skinner gregskinner0 at icloud.com
Thu Apr 30 16:34:58 PDT 2026


On Apr 30, 2026, at 4:50 AM, Craig Partridge via Internet-history <internet-history at elists.isoc.org> wrote:
> 
> On Wed, Apr 29, 2026 at 10:42 PM Dave Crocker via Internet-history <
> internet-history at elists.isoc.org> wrote:
> 
>> On 4/29/2026 5:04 PM, John Day via Internet-history wrote:
>> 
>>>  Choosing SNMP over HEMS.
>> 
>> I'm my usual version of fuzzy about the details, but it appears I was
>> the Network Management AD at the time, for whatever that might be
>> worth.  The only 'directed' choice I recall was to use ASN.1, much to
>> the IETF-constitueny's chagrine.  But that was due to the persistent and
>> vigorous politics coming from the OSI side.
>> 
>> My vague sense of the competition -- besides the solid
>> politicking-over-implementing that characterized the CMIP folk -- was
>> that HEMS was cleaner but lacked experience, whereas SNMP was an
>> increment over the deployed SGMP. Worse, Alas, HEMS also did not develop
>> enough traction to counter  advocacy by the other two communities.
>> 
>> There is quite a bit of history of choosing experience over elegance,
>> especially given the benefits (and in spite of the detriments) of
>> installed base.
>> 
>> By the time of this particular competition, participation in the IETF
>> was wide open and the participation in the IETF was extensive and
>> vigorous.  So the model of rough consensus even benefit from pretty good
>> market sampling.
>> 
> 
> Speaking as a co-author, with Glenn Trewitt, of HEMS, here's what I
> remember.
> 
> HEMS sought to be a richly featured network management solution. Drawing on
> prior network management projects at BBN and elsewhere, it supported
> proxies, MIB extensions, and configurable traps, and it had some notion—I'm
> sure not good enough—of authentication and encryption.  Queries were
> ("safe") little programs that walked the MIB and retrieved information
> based on the current state of the router (e.g. you could send a query to a
> router to find out why it couldn't reach prefix P, and the query could
> discover the link to P was down and return a report on link status).  At
> the network management summit meeting intended to find a direction forward,
> HEMS had a prototype implementation on BSD UNIX. Many vendors, who had
> never implemented a serious network management protocol, were worried about
> fitting HEMS on their platforms.  [Side note: almost no one at the time
> understood just how hard it was to instrument and monitor Internet devices
> in a large operational network.  No vendor and no ISP had been in business
> for more than a few years and there was a lot of wishful thinking about how
> simple network management protocols and tools could be.  Glenn Trewitt and
> I sought out operators and forward looking researchers and aimed HEMS at
> their guess of what would be needed 5 years or so in the future.  Their
> guesses were right, which is why, on paper, HEMS sounds like something the
> IETF should have picked.  But I suspect Glenn and I got the concept right
> but the details wrong in many places.]
> 
> SGMP was a stripped-down protocol that took core ideas from HEMS and CMIP
> and fit easily into existing router implementations. Within months it had
> been widely deployed and was in operational use at the time of the network
> management summit.
> 
> CMIP was part of an OSI network management standards process that by this
> time was importing ideas from HEMS and SGMP. It had, I think, one toy
> implementation of a fragmentary spec, but had a number of powerful vendor
> CEOs calling anyone they could think of (including me) to say "this is the
> future."
> 
> So when the IAB/IESG tried to figure out what to do, after a full day
> meeting, it was clear we were in a tough spot: CMIP had lost, but a number
> of people's ultimate boss (CEO) didn't want to hear that; SGMP was deployed
> and in use, but had serious gaps; and HEMS was perhaps the most complete
> solution but  a prototype that was months (well over a year?) from
> full-scale deployment.  Standards gridlock was a real possibility and the
> growing Internet needed a network management solution "right now".
> 
> To solve the problem, I offered to withdraw HEMS from consideration. That
> immediately made the path forward clear.  A slightly improved SGMP with a
> better MIB was the obvious choice for immediate standardization.  CMIP
> could be tagged as the full-service future, when ready (which it was pretty
> clear, it probably never would be).  Political note: the decision promptly
> created a headache for OSI advocates, as the CMIP proponents, realizing
> they'd lost by winning, then tried to impede progress on SNMP and MIBv1,
> and created the perception that the OSI community was opposed to the
> well-being of the Internet.
> 
> Thanks!
> 
> Craig
> 
> PS: Regarding ASN.1 and network management.  Blame me.  HEMS, to support
> MIB extensions, allowed MIB components (e.g. a routing table entry) to
> include self-documenting vendor extensions.   HEMS, by default, retrieved
> data structures (rather than individual MIB variables).  So you could ask
> for the routing entry for prefix P, and would get all the variables in the
> routing table for P -- including the vendor extensions.  ASN.1's encoding
> (BER) made that easy. All data in ASN.1 BER is self describing. ASN.1
> supports private types (so a vendor could add extensions without worrying
> about typespace collisions, etc. and a network management tool could
> automatically display extensions that it had never seen before).  So when I
> sought an existing external data format for HEMS, ASN.1 was the obvious
> choice (vs., say, Courier or XDR).  CMIP was already planning to use
> ASN.1.  So SGMP picked up the idea while discarding the self-describing
> aspects.
> 
> -- 
> *****
> Craig Partridge's email account for professional society activities and
> mailing lists.
> -- 
> Internet-history mailing list
> Internet-history at elists.isoc.org
> https://elists.isoc.org/mailman/listinfo/internet-history
> -
> Unsubscribe: https://app.smartsheet.com/b/form/9b6ef0621638436ab0a9b23cb0668b0b?The%20list%20to%20be%20unsubscribed%20from=Internet-history

I decided to look into this a bit.  Based on what I gathered from discussions on the tcp-ip list from 1987, and Glenn Trewitt’s PhD dissertation, there were decisions made that could be considered reasonable given the resources that were available at the time. [1] [2] Perhaps that’s being conservative.  I don’t blame them for the choices they made.

--gregbo

[1] https://github.com/matthewgream/www-securitydigest-org/tree/master/tcp-ip/archive/1987
[2] https://apps.dtic.mil/sti/pdfs/ADA377411.pdf



More information about the Internet-history mailing list