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

[Craig Partridge]

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.