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

[Dirk Munk]

johnwallace4 at yahoo.co.uk wrote:
> On Sunday, 18 September 2016 11:32:44 UTC+1, Dirk Munk  wrote:
>> David Froble wrote:
>>> Dirk Munk wrote:
>>>> Paul Sture wrote:
>>>>> On 2016-09-17, David Froble <davef at tsoft-inc.com> wrote:
>>>>>> Stephen Hoffman wrote:
>>>>>>>
>>>>>>> I'd be seriously tempted to announce the deprecation and eventual
>>>>>>> removal of DECnet, for that matter.
>>>>>>
>>>>>> Booo!  Hisssss!
>>>>>>
>>>>>> Ok, we know it's not secure.  Run at your own risk.
>>>>>>
>>>>>> I'm guessing that DECnet users use it only in house, for FAL and
>>>>>> such, so if the
>>>>>> in house environment is secure, then security isn't an issue for
>>>>>> DECnet.
>>>>>>
>>>>>> If it's not going to take up time and effort, then why kill it off?
>>>>>>
>>>>>> I personally find it can be useful.
>>>>>>
>>>>>> It sure is handy when you need to shutdown and re-start TCP/IP on a
>>>>>> remote (but
>>>>>> in house) system.
>>>>>
>>>>> I'd certainly miss one or two things that DECnet does:
>>>>>
>>>>> o - the ability to do a SET HOST 0 /LOG= to get a log / audit trail
>>>>> of software
>>>>>     installations and configuration sessions.   Yes, many terminal
>>>>> emulators can
>>>>>     do logging, but those logs aren't on the target system.
>>>>>
>>>>> o - using DECnet as a means of placing BACKUP savesets on another
>>>>> node, and
>>>>>     restoring them from other nodes (where 'other' can be either
>>>>> local or
>>>>>     remote).
>>>>>
>>>>> o - DECnet tasks.  Useful but I haven't seen many customers use these.
>>>>>
>>>>> o - FAL
>>>>>
>>>>
>>>>
>>>> First of all, which DECnet do you mean?  DECnet Phase IV should have
>>>> been abandoned years ago, DECnet Phase V has been the successor for
>>>> years now, but many DECnet users are just to plain lazy to learn how
>>>> it works. They took a look at the UI, concluded that is was very
>>>> different from the NCP commands of Phase IV, and just gave up. Or are
>>>> they too stupid to understand it?
>>>
>>> I use IV, which suits my purposes.  Sorry you don't approve.  Actually,
>>> I don't give a damn what you think.  If you're going to take the
>>> attitude that it's your way or the highway, well, good luck, you''ll
>>> need it, but I don't think you'll have it.  People are allowed to have
>>> differing opinions.  Even stupid people like me.
>>>
>>>> Has no one ever noticed the analogy between Windows and VMS in this
>>>> respect? Windows uses Netbios over IP the same way VMS can use DECnet
>>>> Phase V over IP. Or have you ever heard of Microsoft abandoning
>>>> Netbios in favour of plane IP stuff like FTP etc. ?
>>>>
>>>> Besides DECnet we also have cluster traffic. It is also insecure. So
>>>> let's just abandon VMS clusters as well???
>>>>
>>>> DECnet and cluster traffic can both use IP for transport. How to make
>>>> that traffic very secure? It is so simple, use IPsec! But when I
>>>> proposed that in this forum, it was made very clear that I'm an idiot
>>>> to propose the only way to encrypt IP traffic that has an real
>>>> architectural idea behind it, instead of the many hobby solutions like
>>>> SSL, SSH etc.
>>>>
>>>> But again, you must make an afford to implement IPsec, and we don't
>>>> want to do that. Quick and dirty solutions that are prone to lots of
>>>> maintenance on the application level are much and much better.
>>>> Thinking in layers, whereby encryption is part of the network and has
>>>> nothing to do with applications, idiotic.
>>>>
>>>> So yes, you can use all the nice features DECnet has to offer, but no
>>>> one cares to deal with these days. And you can use it in a safe way as
>>>> well. Oh yeah, and remember, DECnet is deeply embedded in VMS, VMS was
>>>> build around the idea of networking with DECnet. You do remember how
>>>> full VMS file specifications looks?
>>>>
>>>> node::disk:{directory}file.extension.version
>>>
>>> Yes, my thoughts also ....
>>>
>>>> It start with node::
>>>>
>>>> Try that with plain IP.
>>>>
>>>> Some one recently wrote a article about the status of IPv6, and about
>>>> the status of RFC's . It was shocking to read what an enormous mess it
>>>> is. That is the problem with IP, it is one enormous out of hand hobby
>>>> project with lots of overlapping poorly defined 'standards' that are
>>>> really no standards at all (!!).  It is exactly what we should not
>>>> have in times that well structured security and dependable network
>>>> communication is of the utmost importance.
>>>
>>> In general I agree with what you've written.  I consider DECnet as a
>>> part of VMS, and if one really doesn't want VMS, then just go and use
>>> something else.
>>
>> Thanks David.
>>
>> My ideas about Phase IV are not just opinions. Phase IV is a dead end,
>> it won't be long before you can't buy routers for Phase IV. You can't
>> make Phase IV traffic secure, you can't use it in a IP-only network
>> environment, you can't use it over the internet. Those are facts, not
>> opinions.
>>
>> I will go further then that. By sticking to DECnet Phase IV, you will
>> affectively kill DECnet. If DECnet is nothing else then an IP port for
>> your network people, then who cares. If it is a completely different
>> network environment, it will be all the more reason to kick DECnet and
>> even VMS out.
>>
>> Does this make sense to you?
>>
>> I'm sure DECnet Phase IV suits your purpose, but the nice thing with
>> DECnet is nothing changes on the application level when you go from
>> Phase IV to Phase V. Now look at IP, go from IPv4 to IPv6. You have to
>> rebuild your application, put two networks stacks in for as long you're
>> using dual stack.
>>
>> So in your case:
>> - Go from DECnet Phase IV to DECnet Phase V: you don't have to change
>> anything in your application.
>> - Go from OSI transport to IPv4 transport: you don't have to change
>> anything in your application.
>> - Go from IPv4 transport to IPv6 transport: you don't have to change
>> anything in your application.
>> - Go from insecure to encrypted networking with IPsec: you don't have to
>> change anything in your application.
>
> I'm convinced, but then I learned DECnet IV (protocols and
> applications), OSI (protocols and applications), and IP4
> (protocols and applications) and IP6 (vision - the rest
> was still years away) all in the same few years in the
> late 1980s (and not just on VMS either).
>
> Afaict, the thing that did for DECnet/OSI (Phase V, etc)
> was the learning curve of its unified management interface.
> Its immediate OSI/VMS predecessor, VOTS/OSAK/etc, was
> understandable to near-normal human beings. DECnet/OSI
> suffered from "Swiss penknife syndrome".
>
> IPv6 is still barely more than a vision for most folk. It
> may be supplied and enabled with every modern Window box
> and many/most Linux boxes, but how many people actually
> know they've got it, let alone actually use it?

Everybody who has an IPv6 internet connection. You will use it without 
knowing it. Every Google request, every Netflix film, every Youtube film 
will be transported over IPv6. Far more people then you may think.

>
> Do I want DECnet to hang around? I don't think the question
> is properly formed: do we mean protocols on the wire,
> applications that people use, or what? Though I suspect
> the answer might still be "no" to both questions for many
> people.
>

DECnet as an API for applications, and as the always present 
functionality in VMS. Not as protocol on the wire, no need you can use IP.

> I see OMNI and OSAP are still on the latest VSI roadmap
> (a pair of related products which started life as ways
> to talk in a formally standardised vendor-independent
> way to shop floor machines and other stuff too). Built
> originally on OSI networking. I would be interested to
> know if they still require an underlying OSI network,
> or whether minnows like Siemens, GE, etc (and their
> customers) have accepted that IP-only networks are the
> future for manufacturing networks for everyone,
> everywhere.
>
Using IP as transport protocol is an OSI standard! It is not DECnet 
Phase V specific. So I don't see any reason that OMNI and OSAP could not 
be transported over IP. Now of course Siemens, GE etc. must also have 
implemented the IP transport stack in their OSI networking for this to work.