[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