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

Jan-Erik Soderholm jan-erik.soderholm at telia.com
Sun Sep 18 10:10:09 EDT 2016


Den 2016-09-18 kl. 14:09, skrev 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...

Right. But it doesn't help that your Windows/Linux client comes
with an IPv6 stack built-in when your router and ISP has it
disabled anyway. And why should *I* care? Google, Youtube and
everything else works just fine.


  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.




More information about the Info-vax mailing list