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

Greg Skinner via Internet-history <[email protected]>
Newsgroups gmane.culture.internet.history
Message-ID <[email protected]>
On Apr 30, 2026, at 4:50 AM, Craig Partridge via Internet-history <[email protected]> wrote:
> 
> On Wed, Apr 29, 2026 at 10:42 PM Dave Crocker via Internet-history <
> [email protected]> 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
> [email protected]
> 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

-- 
Internet-history mailing list
[email protected]
https://elists.isoc.org/mailman/listinfo/internet-history
-
Unsubscribe: https://app.smartsheet.com/b/form/9b6ef0621638436ab0a9b23cb0668b0b?The%20list%20to%20be%20unsubscribed%20from=Internet-history
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.