[ih] GOSIP & compliance

[Bob Purvy]

CMOT! There's a term you don't hear much anymore.

At 3Com, towards the late 80's or early 90's, I was on an "architecture
committee" led by Amatzia Ben-Artzi. We spent a lot of time debating CMOT
vs. SNMP.

I don't recall that anything much was accomplished.

On Sat, Mar 26, 2022 at 1:22 AM Karl Auerbach via Internet-history <
internet-history at elists.isoc.org> wrote:

>
> On 3/24/22 5:03 PM, Dave Crocker wrote:
> >> I think the IETF's hostile attitude towards ISO/OSI created an
> >> atmosphere of auto-rejection in which those ideas were too often
> >> ignored.
> >
> > This is silliness.
>
> Yes, the OSI people wrote impenetrable documents and did their best to
> hinder dissemination.  And they never explained the "why" only the
> "how".  It took real effort to read between the lines to understand.
> But some of us did.  And sometimes we found valuable nuggets.
>
> (By-the-way, the IETF has slid into a similar mode, expressing only the
> "how" of a specification without much, if any, note of alternative
> approaches that were examined and rejected, and why they were rejected.
> The patent attorney in me shakes my head in bewilderment at that
> seemingly intentional erasure of potential "prior art" and the
> opportunities that creates for patent trolls to cause expensive mischief.)
>
> Examples of useful concepts in ISO/OSI that we missed (or ignored) to
> our detriment.  (Some recent designs, such as QUIC, have rediscovered
> some of these things.)
>
>    - In IPv6 we had a choice to rethink the IP checksum, but we didn't.
> The Fletcher checksum used in OSI is significantly stronger than the IP
> checksum and not subject to the implementation complexity of thinking in
> ones-complement arithmetic that exists on no present computer
> architecture.  (If I remember correctly there are two or three RFCs
> dealing with issues with the existing IP checksum.)  The Fletcher
> checksum looks scary - a first glance makes one think it is full of
> expensive multiplications - but there are quite fast algorithms for
> doing full and incremental calculations.  (There may have been good
> arguments against such a change, such as the pseudo headers for TCP and
> UDP, but I do not remember these ever coming up.)
>
>    - The IETF never inquired why ISO/OSI had a session layer. Turns out
> that it is an important concept that we've had to re-invent in different
> forms, such as web cookies.
>
>     - Similarly in the development of IPv6 the IETF never really
> considered connection-time data.  This was a universal concept
> throughout ISO/OSI.  So we ended up kinda kludging it together for
> things like TLS/SNI for HTTPS. (QUIC improves this considerably.)
>
>     - ISO/OSI also had "application entity titles" which were names that
> could be used to rebind associations/sessions if the logical entity (we
> call these cloud base applications these days) disconnected (due to
> transport failure caused by noise, congestion, or network address
> change), moved, split, or merged. OSI didn't fully solve these problems,
> but it had an architectural hook to latch onto.  We're wrestling with
> these concepts in the TCP world.
>
> Yes, the ISO/OSI people never put on an engineering hat and trimmed and
> reshaped their stuff into something that could actually be built.  And
> their mode of expression was horrid (and just getting the documents was
> expensive).
>
> 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
>