[Info-vax] DECnet Phase IV and VMS code comments

[David Froble]

Stephen Hoffman wrote:
> On 2016-11-29 13:25:01 +0000, Simon Clubley said:
> 
>> On 2016-11-28, Kerry Main <kemain.nospam at gmail.com> wrote:
>>>
>>> I don't think anyone here views 35+ year old DECnet as a strategic 
>>> network product.
>>
>> ...I only care about the fact that it's still available and enabled on 
>> VMS systems running today...
> 
> Which is why I'd prefer to see telnet, FTP, DECnet and other giblets 
> with explicit security warnings and requiring the system manager to 
> override those to enable the mechanisms.   Or entirely removed, and an 
> extra-cost add on.
> 
> In short, far less DECnet integration with OpenVMS.   Vastly better IP 
> integration.  TLS and certificate integration, too.   It's long past 
> time to update what was started with OpenVMS V6.2.
> 
> Keeping utterly broken designs and interfaces around and accessible "for 
> compatibility" is short-sighted and hazardous, at best.   But then I'm 
> being polite.   Customers will always want to avoid making changes, but 
> they can and do need to make at least some.    Customers — most of them 
> — aren't experts in this sort of stuff, and what is available is hard to 
> use, variously not used, and is poorly integrated.   Even within OpenVMS 
> itself.  Which is why we still see configurations where DECnet, telnet 
> and FTP are commonly used, if not the primary network transports...   
> Which means folks can get shellacked — and do, and have gotten 
> shellacked, and without attackers bothering to use ROP or needing to 
> bypass ASLR or otherwise...

I agree about doing better today.  However, I'm a bit aware that there are 
people using VMS for things that I've never imagined.  For example, John Wallace 
has mentioned factory controls that use the OSI stuff, (I seem to recall), and 
therefore doing away with DECnet V might push such people away from VMS.  I'll 
bet there are more such instances.

That written, today there just isn't much use for DECnet, and there is a use for 
IP, an IP that supports all (or most) of the DECnet utilities.  As you've 
suggested, tie the stuff tightly to the OS, and make it easy to use, and include 
security.

So, if any work is to be done in this direction, much better to allocate the 
resources to implementing the DECnet utilities that are useful using IP.