[ih] GOSIP & compliance

[Vint Cerf]

IAB reviewed three proposals (SGMP, HEMS and CMOT). After a lot of
discussion, Craig withdrew HEMS, CMOT was seen as "the long term" (smile)
and SGMP became SNMP and was the target of immediate adoption effort.

https://datatracker.ietf.org/doc/html/rfc1052

v


On Mon, Mar 28, 2022 at 12:49 PM Craig Partridge via Internet-history <
internet-history at elists.isoc.org> wrote:

> Quick comments on Karl's comments (from this note and later).
>
> ASN.1 was in SNMP because it was in HEMS.  HEMS did it to allow us to
> return self-describing vendor specific data without requiring a
> supplemental MIB definition.  This was important because HEMS allowed one
> to ask for the full status of an aggregate object (such as an interface or
> even an entire subjection of the MIB) and we wanted folks to be able to add
> additional data they thought relevant to the aggregate.  ASN.1 was the only
> self-describing data format of the time.
>
> The UDP vs. TCP debate was pretty fierce and the experience of the time
> came down firmly on the UDP side. Recall this was the era of daily
> congestion collapse of the Internet between 1987 and 1990.
>
> Re: doing things in Python.  I'm not surprised.  The HEMS implementation
> proved reasonably small at the time.
>
> By the way, many of the features noted in CMIP were actually in HEMS and/or
> SNMP first.  We were pretty open about playing with ideas at the time and
> the CMIP folks, who had an empty spec when SNMP and HEMS started, chose to
> borrow liberally.  (Or, at least, that's my recollection).
>
> There was a network management project in the late 1980s, name now eludes
> me but led by Jil Wescott and DARPA funded, that sound similar in goals to
> what Jack H. describes doing at Oracle.  I leaned on wisdom from those
> folks (esp. the late Charlie Lynn) as Glenn Trewitt and I sought to figure
> out what HEMS should look like.
>
> As we do these assessments, it is worth remembering that the operational
> community of the time was struggling with the immediate challenge of
> managing networks that were flaky and ran on 68000 processors and where
> only a few 100K of memory was available for the management protocols.  The
> SNMP team found a way to shoe-horn the key features into that
> limited footprint and it promptly made a *huge* difference.
>
> Craig
>
> On Sat, Mar 26, 2022 at 2:22 AM Karl Auerbach via Internet-history <
> internet-history at elists.isoc.org> wrote:
>
> > ...
> > BTW, I thought the use of ASN.1/BER for SNMP was far from the best
> > choice (indeed, from an implementation quality and interoperability
> > point of view would be hard to find one that was worse.)  I preferred
> > the HEMS proposal as the most elegant, even if it did use XML.
> >
> > CMIP had some really good ideas (most particularly with regard to
> > selecting and filtering data at the server for highly efficient bulk
> > fetches.)  Marshall Rose's rehosting CMIP onto TCP (thus creating CMOT)
> > was very inventive and clever.  That kinda demonstrated the potential
> > viability, rather than the impossibility, of things like CMIP/T, even in
> > its bloated form.
> >
> > Diverting from the main points here:
> >
> > About a dozen years ago I decided to rework SNMP, throwing out ASN.1/BER
> > and using JSON, throwing out UDP and using TCP (optionally with TLS),
> > and adding in some of the filtering concepts from CMIP.  I preserved
> > most MIB names and instrumentation variable semantics (and thus
> > preserving a lot of existing instrumentation code in devices.)
> >
> > The resulting running code (in Python) is quite small - on par with the
> > 12kbytes (machine code) of the core of my Epilogue SNMP engine.  And it
> > runs several decimal orders of magnitude faster than SNMP (in terms of
> > compute cycles, network activity, and start-to-finish time.)  Plus I can
> > do things like "give me all data on all interfaces with a received
> > packet error rate greater than 0.1%".  I can even safely issue complex
> > control commands to devices, something that SNMP can't do very well.  I
> > considered doing commercial grade, perhaps open-source, version but it
> > could have ended up disturbing the then nascent Netconf effort.
> >
> >          --karl--
> >
> >
> > --
> > Internet-history mailing list
> > Internet-history at elists.isoc.org
> > 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
> https://elists.isoc.org/mailman/listinfo/internet-history
>


-- 
Please send any postal/overnight deliveries to:
Vint Cerf
1435 Woodhurst Blvd
McLean, VA 22102
703-448-0965

until further notice