[ih] GOSIP & compliance

[Karl Auerbach]

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--