[Info-vax] What would you miss if DECnet got the chop? Was: "bad select 38" (OpenSSL on VMS)

[Dirk Munk]

Stephen Hoffman wrote:
> On 2016-09-19 20:57:03 +0000, Dirk Munk said:
>
>> No, it is not...
>
> You can continue to explain this as often as you do and can continue to
> correctly point out the many aspects of DECnet and OSI that are
> technically superior to IP networking, and can certainly continue to
> presume we do not understand any of that, or that we might disagree with
> your statements around the various benefits of DECnet.   We very much
> understand all of which you are pointing to.   I certainly do.   You are
> entirely correct about the general superiority of the DECnet products, too.
>
> But that doesn't matter.   This due to having utterly missed the
> networking market and a large chunk of the then-increasing Unix market,
> and OSI in particular having turned into one of the more complex
> products to configure and manage on OpenVMS, and with one of the most
> utterly-missed-the-audience user interfaces ever shipped on OpenVMS.
> NCL (and DEC Enterprise Management Architecture) is one of the most
> exceptionally elegant and all-encompassing user interfaces around, and
> one that clearly did not meet the needs of its target market.   Each
> revision did get better and easier to manage, too.  (Integrating
> products with DEC EMA was a whole lot of work, though.  Which is part of
> why that never really happened.)
>
> DECnet Phase IV, IV+, V — and all of the parts of OSI that didn't end up
> getting reused and effectively migrated out of the old OSI model and
> over into IP networking — utterly missed the market, and these products
> are now utter dead ends, insecure, problematic and increasingly limited
> and system-dependent, and spending time on any of this stuff detracts
> from the work necessary to make OpenVMS (more) viable in the current and
> near-term future.
>
> DECnet Phase IV, IV+ and V is not now and never will be the path
> forward, nor will the networking stack arising from the old OSI model.
>
> DEC made the same mistakes that you are repeating here, too.   Thirty
> years ago.   DEC management and development had a firm belief in the
> value of technical superiority products.   Products which took far too
> long to get onto the market, were far too limited in availability, cost
> far too much in terms of system resources (back then), were too limited
> in platform support, and — in aggregate — completely and utterly missed
> the market when the resulting products became available.

Yes I know. The ICT world wants quick and dirty. One hype after the 
other. There are three times more computer languages then there are 
human languages.

One day something terrible will happen that will make us realise that 
ICT is not kindergarten stuff, but has to be taken seriously.

>
> Not to mention that DEC came up with a user interface and management
> design that needs more than a little user interface assistance.
>
> If VSI is to spend time and effort dragging any of the networking
> products forward, and better integrating and securing the networking,
> let it be IP and TLS and related support.   The current TCP/IP Services
> stack has problems similar to the DECnet OSI management, though with an
> even more scatter-shot and inexplicably complex configuration and
> management interface than DECnet OSI featured.

We all know that the present IP stack is junk, and we're waiting for the 
new one. I have no idea why you think the configuration is so difficult, 
I never had any problems. But there's always room for improvement.

>
> The inclusion of DECnet is not going to be a priority in new application
> development work and application overhauls, outside of a few specific
> environments.
>

DECnet is a mature product, except for using IPv6 as transport and 
including the new file system, there's nothing that needs updating or 
what ever.

> For all its ugliness, IPv6 is the path forward.   That IPv6 path might
> or should or will include adding Google's BBR congestion control work
> https://plus.google.com/+SamiLehtinen/posts/PCiCHhFRWTr as well as a
> complete user interface overhaul, integrating TLS and SFTP, and various
> other updates.   OpenVMS has to deal with IPv6.

Tell me something new, I've been saying that for over 10 years now.

> DECnet?   DECnet is
> useful for legacy code and legacy sites, when security, authentication
> and heterogeneous networking are not requirements.

DECnet is for VMS <> VMS communication, nothing else. I have always said 
that.

>
> Your approach and your preference here certainly mirrors DEC development
> and DEC marketing, from most of thirty years ago.   This approach did
> not end well for DEC and DECnet, either.   DEC spent more than a little
> time and effort on developing and marketing and providing and supporting
> OSI, and — when the implosion of OSI in the market became something that
> simply couldn't be ignored, and when the various governments walked back
> from their plans to require OSI support in favor of IP support — OpenVMS
> and IP networking never really recovered from this.
>
> VSI has a opportunity to change that IP and IPv6 integration.

Yes, and they have to build the best and most elaborate IP stacks possible.

> But
> nothing VSI can do will ever bring back DECnet Phase IV, IV+ or V.
>
> Keep DECnet around for legacy sites and legacy applications, and for
> folks that have no interest in encryption or authentication, and for the
> foreseeable future.  Beyond that?

I *WANT* encryption on DECnet, but not with bolted on products like TLS 
etc. Many years ago I was at a meeting in the Digital building in 
Utrecht, you will remember it. There was a meeting about new 
enhancements, it as the first time I heard about IPsec. My first thought 
was "finally a piece of real architecture in IP". Putting encryption and 
security on the network level where it belongs. And these days it can 
even be handled in the NIC, and that is the best place for it as you 
will well know.

Full speed on IPv6...

I agree, BUT:
- IPv6 isn't even an official internet standard yet !!!
- The routing standards are not properly defined and implemented, 
certainly with regard to packet fragmentation and reporting over ICMP.
- The fucking idiots at the IETF completely forgot how to properly 
define the functionality of CE routers (Global addresses, ULA addresses, 
DNS), and how and where to store the DNS entries of the global IPv6 
addresses of the device in the home LANs. Consumers will want to connect 
to devices on their home LAN from the internet, that is standard these 
days. I saw that problem years ago, and wondered how it would be solved. 
They have hardly started thinking about it, let alone defining the 
functionality of a CE router in this respect. Because of all the 
security aspects involved, it will be quite a job building a proper CE 
router instead of the insecure junk we can buy these days.
- I'm sure there are many other issues as well, and that after more then 
20 years of development. Wow .....

That is what I hate about IP. Thousands and thousands of RFC's, but only 
half baked solutions. No proper design, no proper concepts. One hobby 
project after the other, 20 half baked solutions for the same problem.

I have been using IPv6 for some 7 or 8 years now, and trying to push my 
ISP to get it up and running. They have been working on it for at least 
six years, and still they have problems. Not in the least with those 
stupid cable routers (incl. Cisco of course).